How a Google Sheet Saved a Restaurant: SATORI Sushi
In the heart of Constanza, Dominican Republic - a city known for its agricultural heritage and Japanese influence - two sisters were revolutionizing the local food scene. Sarel and María Teresa Rivas Báez had turned their home kitchen into SATORI, a ghost kitchen serving Dominican-Japanese fusion sushi that quickly became the talk of the town. This is technical rundown of what I did to help them reach their full potential.
The Problems#
It all started with a late-night conversation with Sarel about their growing pains. Despite only being open on Saturdays, SATORI's popularity had created some interesting challenges. Their success was becoming their biggest hurdle, and they were struggling to keep up.
Orders were flooding in through every possible channel - WhatsApp messages, Instagram DMs, and phone calls. Imagine preparing delicate sushi rolls, then simultaneously juggling three different chat apps, trying to note down orders without mixing up delivery addresses or special requests. Not exactly what I would call optimal.
Evenings were particularly intense. Between 6-9 PM, they'd receive a surge of orders that would at times demoralize and paralyze the team. Early attempts to prevent being over-run with evening orders resulted in over-preparation and wasted food on the slower days.
The most frustrating part? They couldn't effectively communicate with customers about order status or delays. When you're elbow-deep in sushi rice, stopping to send WhatsApp updates isn't exactly practical. Similarly, if you are a hungry customer, you are less likely to empathize with restaurant staff about your order taking longer than expected.
I hadn't even visited Constanza at this point, but I could feel their frustration through our conversations. As a software engineer, I saw an opportunity to help transform their operation with technology - without breaking the bank or compromising the authentic experience they'd created.
Solution Requirements#
After reviewing SATORI's operations, it became clear that we needed a solution that would work in the real world, not just in theory. The challenge? Building something robust enough to handle a busy restaurant while being simple enough for everyone to use.
Business Needs
- A single place to manage all orders
- An intuitive interface for non-technical staff
- A cost-effective solution
Technical Constraints
- Spotty internet connectivity
- High availability during high demand
The key was finding the sweet spot between functionality and simplicity. We needed something that could handle spotty internet, work on any device, and most importantly, make life easier for the SATORI team - not more complicated.
I've learned that sometimes the best solutions aren't the most technically impressive ones, but rather the ones that actually get used. This project would put that theory to the test.
Technical Implementation#
The beauty of this solution lay in its simplicity. We needed to build something robust yet maintainable, with zero hosting costs. Here's how we pieced it together.
Core Stack
-
Next.js became our foundation, delivering snappy load times and high availability. Critical for those slow internet connections.
-
Google Sheets transformed into our database and CMS. Unconventional? Yes. Effective? Absolutely. Staff could manage their business operations in a familiar interface, while our application consumed and published the data through the Sheets API.
- SQL best practices are still followed even in this context with normalized tables. We have several different sheets inside a single spreadsheet. Think of the spreadsheet as the database and the sheets as database tables. We have
Orders,Items,Configsheets amoung others. - This solution is plenty fast and robust for the use case, though the downsides are that because it's easy to edit the sheets, any fat-fingering of keys could "corrupt" the table and cause downtime. Luckily, we have been able to lock down tables that are not needed by the staff and utilized Google Sheets Query functions to make read-only views into the data.
- SQL best practices are still followed even in this context with normalized tables. We have several different sheets inside a single spreadsheet. Think of the spreadsheet as the database and the sheets as database tables. We have
-
Google Maps integration to simplify the delivery process.
-
Axiom integration for analytics, error logs, monitoring, and notifications, providing real-time insights into system performance and user behavior.
Key Features
-
A real-time dashboard became the command center, tracking active orders for the day and providing business insights. Staff could now see the most critical information live and at a glance.
-
Dynamic store and menu management allowed instantly published updates to the site. Out of salmon? Toggle it off in configuration sheet, and the website automatically reflects the change.
-
Automatically adjusted limited defined 30 minute time slots for order placements for managing demand. At least 45 minute notice to place order during high demand.
-
Defined delivery zone notified the users when they were too far away or if it would cost extra. The system would calculate distance from the users current location to the restaurant.
-
Customer accounts tracked order history and preferences, while a points system rewarded loyal customers. Each purchase earned points, driving repeat business.
The entire system ran with minimal maintenance needs. By leveraging NextJS serverless architecture and Google's services, we achieved a scalable and reliable solution without managing servers. The progressive web app approach meant customers could "install" the app on their phones, providing a native-like experience without the overhead of app store deployments.
Impact & Results#
After six months of implementation, the change was clear.
The system dramatically improved order accuracy, eliminating costly mistakes and customer disappointments. This meant fewer refunds, less food waste, and happier customers.
Staff productivity showed remarkable improvement, noting considerable stress relief from the workers and the new found luxury for one of the sisters to take the day off while the other handled operations. They are now able to alternate days off every Saturday. This wasn't about working harder - it was about working smarter. The team could now focus on food preparation instead of juggling communication channels.
SATORI now had proper forcasting and insights into their business revenue, customer preferences, menu item performance, etc. This removed the need for any guess work when purchasing ingredients during normal and holiday operations.
What started as a technical solution to operational problems ended up transforming the entire business. SATORI could now handle more orders with less stress, while maintaining their high quality standards and personal touch that made them popular in the first place.
Lessons Learned#
Building SATORI's ordering system taught me valuable lessons about the intersection of technology and real-world business needs. The experience challenged my preconceptions about "proper" software development and showed me the true meaning of pragmatic solutions.
The biggest technical revelation? Sometimes the "hacky" solution is exactly what's needed. Using Google Sheets as a database might raise eyebrows in a tech interview, but it proved perfect for this context. It handled the load, cost nothing, and most importantly - the staff could use it without training. This experience fundamentally shifted my perspective on what makes a solution "good." The best architecture isn't the most elegant or technically impressive - it's the one that solves real problems for real people.
Working closely with a small business showed me how technology decisions directly impact operations. When your system goes down, it's not just a technical issue - it's missed orders, frustrated customers, and lost revenue. This reality check has permanently changed how I approach error handling and system reliability. Every technical decision has a business consequence, and understanding this relationship is crucial for building effective solutions.
The project's success ultimately came down to people, not technology. By involving staff in the development process and keeping interfaces familiar, we achieved quick adoption and real results. I learned that user experience isn't just about clean interfaces - it's about understanding how people work and building systems that enhance rather than disrupt their existing workflows.
What started as a simple solution to help a small sushi restaurant has evolved into a blueprint for approaching similar challenges. The system continues to evolve with SATORI's growth, and each new feature teaches me more about balancing technical capabilities with business needs. Building something that makes a real difference in people's daily operations - that's what software engineering is all about.