Forchetto - A Management Platform for Restaurants
A multi-tenant restaurant SaaS we built for the European market, bringing tables, menu, orders and kitchen flow into a single platform.
- Role
- Our own product · Product & Engineering
- Stack
- Next.js · TypeScript · AWS Lambda · Aurora PostgreSQL · Cognito · SST
An industry worn down by fragmented tools
Independent restaurants and small chains across Europe run their day on five or six different tools stitched together: POS from one brand, menu management from another SaaS, kitchen screens from a different device, reports in Excel. Each tool is bought separately, data doesn't flow between them, and pricing is layered per feature. The setup is already expensive for a single restaurant; by the time a brand runs two or three locations, it starts to break.
We started Forchetto to close that gap. From the floor plan to menu management, from the waiter taking an order to the flow on the kitchen screen, we're bringing the operational backbone of a restaurant day into a single platform. Our target market is Europe - we're planning to go live with pilot restaurants across multiple countries.
“Build multi-tenancy and security into the architecture from the first commit, not after.”
Our Approach
We designed Forchetto as a sellable SaaS from day one, not as a client-specific application. That changes the setup from the start: tenant isolation, infrastructure cost, multi-environment management and authentication couldn't be deferred past MVP - they were on the table with the first architectural decisions.
We built the product in two parallel layers: an AWS-native serverless backend (Lambda, Aurora PostgreSQL, Cognito, with the entire infrastructure defined as code via SST) and a Next.js frontend running on mock data. With the frontend MVP done, we started wiring the two layers together - we're currently in the integration phase.
Technical Decisions
Tenant isolation through Row-Level Security
The two common patterns for multi-tenant SaaS are a database per tenant or a schema per tenant. We went a third way: a single schema, a single set of tables, and PostgreSQL's Row-Level Security for isolation at the row level. Every table carries a tenant_id, and every query is automatically filtered against the tenant identity set on the Postgres session. That means "the wrong restaurant can't see the wrong data" doesn't rely on an if-else we might forget in the application layer - it's enforced by the database's own access control. Onboarding a new restaurant doesn't provision a schema or a database; a single row is enough.
AWS serverless stack: Lambda + Aurora Serverless v2 + RDS Proxy
The traffic of an early-stage SaaS is both unpredictable and prone to sharp growth jumps. An always-on backend server doesn't fit that profile. We picked Lambda as the API layer and Aurora Serverless v2 as the auto-scaling database - a profile that barely costs anything at low load and scales itself up at peak hours. We solved serverless Postgres' classic connection pooling problem with RDS Proxy: instead of Lambda opening a new connection on every invocation, we go through pooled connections managed by the Proxy. That lets Aurora handle thousands of concurrent Lambda calls without being exhausted.
Cognito + a centralized AuthGuard
We delegated authentication to Amazon Cognito; writing token management, password policies, MFA and forgot-password flows from scratch isn't a saving - it's risk and maintenance load. On the frontend, instead of scattering auth checks across pages, we consolidated them into a single AuthGuard layer: redirects for unauthenticated users, role checks and tenant verification all live in that one place. Adding a new page doesn't mean re-wiring auth; placing it under the AuthGuard tree is enough.
The entire infrastructure defined as code with SST
Lambda functions, VPC configuration, the Aurora cluster, RDS Proxy, the Cognito user pool, CloudFront distribution - all of it is defined in TypeScript via SST. Dev, staging and production environments each come up with a single command and stay identical to each other. Managing multiple environments through code reviewed in PRs rather than manual clicks in the AWS console, and being able to see with a diff why something that works in one environment doesn't work in another, turned out to be a more valuable discipline for an early-stage SaaS than we expected.
From the UI
Status & Outcome
Forchetto's frontend MVP is complete on mock data: from table management to the menu editor, from the waiter order flow to the kitchen screen and the QR menu display, every operational flow we targeted is already running as a UI. On the backend side, the Lambda endpoints covering the same flows, RLS policies and Cognito configuration are in place.
We're now wrapping up the integration between backend and frontend. The next step is testing the product against real field data at pilot restaurants across Europe. Having built the multi-tenant architecture, the serverless cost profile and the security layer into the first version rather than adding them later lets us run that transition as a launch process rather than a refactor project.
Have a product idea that should be structured as a SaaS?
If you're thinking about building a SaaS from scratch, moving an existing product onto a multi-tenant architecture, or setting up AWS serverless infrastructure, let's talk.
Get a Quote