Eight friends, a Saturday night, your own kitchen. You know who's vegetarian, who skips dessert and who'll show up with a second bottle of wine. There's one menu, cooked for one sitting, and every plate comes out the way you planned it. Somewhere around eleven, someone leans back from the table and says it: "You should open a restaurant."
It's the same cook and the same food. Almost nothing else is the same.
Agents have made the dinner party easy. For a small browser-based workflow, an afternoon's prototype can be a single HTML page with the logic, styling and sample data inside it. You email it to a colleague, they open it, and they can try the idea. A separate server, shared database and sign-in can wait while you find out whether the workflow is useful.
Then the colleague forwards it to their team, and someone says the software version of "You should open a restaurant."
That's when the questions change. The reservation book has to survive until next Friday. Two staff members need to work from the same bookings. Someone gets the call when the stove dies, and someone writes next season's menu. The application is becoming a place where people keep their work, and its design has to account for that.
Why the dinner party works
A dinner party succeeds because it's narrow. You cook for people you know, you plan around what they like, and when the evening ends, so does the job. Nobody needs a reservation system for eight friends.
A good prototype is narrow in the same way, on purpose. It tries one workflow with chosen data and a small group. Some prototypes already have databases and accounts; the useful constraint is how much of the problem they take on. That is the same reason the workbench comes before the factory in Your Laptop Might Be the Best Data Warehouse You Own.
With the emailed file, the limit becomes visible when two people enter real data into separate copies. Which copy holds the current record? Who can correct it? The dinner party has acquired regular customers, and they expect their reservations to be there tomorrow.
That change can happen with three people using an internal tool. They may only need it on weekday mornings, but losing yesterday's work or overwriting a colleague's changes would still matter. The architecture grows around those expectations: what the application stores, how its parts communicate and which rules protect the work.
You should open a restaurant
A restaurant has to organize the work around the cooking. The dining room needs to be ready, the reservation book needs to be current and the staff need ways to handle changes and mistakes. A shared application needs the same attention around the workflow its prototype demonstrated.
Open when promised: hosting and availability
A dinner party happens when you're ready. Once a restaurant posts its opening hours, customers plan around them. If service starts at five, someone needs to have the kitchen ready and cover the night the chef has a cold.
For this shared web application, hosting gives everyone one address to bookmark and a common application to use. It has to be available when the team needs it, including while you're asleep or away. Someone decides where it runs, what it costs and how people will work if it goes down. Putting the page online solves the common address; the records and behavior behind it still need their own design.
The responsibility follows the use. An app installed on a device may run locally. A weekly internal tool may tolerate downtime that an appointment system can't. Choose availability around the work people depend on.
The reservation book: shared records and a data model
A restaurant needs to remember commitments beyond tonight's meal. The person taking a booking on Tuesday may be home when the guests arrive on Friday. The host at the door needs to find the booking, see any changes and know which table is available.
Browser storage can keep data after the tab closes. The problem with separate local copies is coordinating them. For the shared workflow, a database provides a common place to save and retrieve records. The application and database together need rules for how those records can change. How browser storage persists
Consider reservation R104: two guests, Friday at 7:00, assigned to table 6. The guests call to move it to 7:30. It remains reservation R104, even if the host also assigns a different table. The reservation has an identity of its own; the time and table are things that can change about it. The host marks it seated when the guests arrive and completed when they leave.
If the guests ask to bring three friends, a table for two won't do. If they cancel, the booking should release its table, and the restaurant may need to preserve a history of the cancellation. These are data-model decisions: what the things are, how they relate, which states they can be in and which changes are valid. A screen that displays a booking has only demonstrated part of that behavior.
Shared use introduces another problem. One host opens R104 to change the time while another opens it to record a cancellation. If both save a whole copy of the booking, the later save could erase the earlier change. One approach is to give the record a version and accept an edit only if that version is still current. When it has changed, the application can ask the host to review the latest booking before saving. The database must enforce that condition as part of the write. Handling concurrent updates in DynamoDB
That protects one record from a stale edit. Preventing two different reservations from claiming the same table at the same time requires a rule for that shared capacity too. Choosing a database includes deciding how it will support these operations, alongside the application's expected workload. The reservations on the demonstration screen become commitments the system must keep consistent.
In the Range of Motion Tracker, the physical therapy platform I build with my co-founder, a patient has sessions, and sessions have captured measurements and images. Those relationships let a report show the right evidence for the right visit. The files need storage too, with references that keep each image connected to its session. The model tells the application what belongs together and where to look when someone opens a patient's history.
An early data-access layer found many records by scanning a table and filtering afterward, like reading every ticket on the rail to find one table's order. We changed those paths to indexed lookups, the equivalent of organizing tickets by table number. The database can find the relevant records without first reading the whole table. How DynamoDB scans work
These decisions shape the next parts of the application. Permissions apply to particular records, tests need to exercise their valid changes and updates have to preserve the relationships people already rely on.
Staff badges and the register key: sign-in and permissions
At a dinner party, you recognize everyone at the door. A restaurant also needs to know who works which station and who can close out the register. A staff badge identifies the person. The register key gives them permission to do something specific.
That is the distinction between sign-in and authorization. The first establishes who someone is; the second decides what they can do with a particular record. In Range of Motion, therapists, patients and administrators have different access. The server checks ownership and organization membership when records are requested. Hiding a button on a screen can't provide that boundary. Authorization checks on each request
We also restricted what the application can ask the database to do. Once the indexed paths were in place, we removed its permission to scan the tables holding patient and session records. An accidental broad scan now fails instead of reading the table. Ownership checks still matter for individual records. Each safeguard has a defined job, like a register lock alongside the rules for who gets its key.
A practice service: testing the whole workflow
At home, you taste as you cook and can keep the evening's plan in your head. Before opening a restaurant, a practice service lets the team try the whole sequence: take a booking, seat the guests, send the order to the kitchen and bring the right plates to the right table. A good dish is one part of a successful service.
A prototype may get its first checks from the person trying it. Once people rely on it, each change needs a repeatable way to check that existing work still behaves correctly. For a booking application, that includes moving R104 without creating a second reservation, rejecting an invalid table assignment and warning about a stale edit. The rules in the data model become behaviors to verify.
Range of Motion's pipeline runs automated checks and browser tests on pull requests and pushes to its main branch. Those tests use controlled data. Someone still needs to exercise the real workflow in its intended environment, which is the part I covered in How I Check That It Actually Works.
The practice service has limits too. During actual service, someone still checks the plates at the pass and watches for orders that have stopped moving. Software needs that attention after release as well.
When the stove dies on a Friday: support
The stove can fail while orders are waiting. Staff need to notice, find out which dishes are affected and decide what they can still serve. A restaurant also needs someone who can fix the equipment, and a way to reach them during service.
In an application, logs record events that help explain what happened. Monitoring calls attention to failures, and a person is responsible for responding. The response plan includes what users can keep doing, what they should stop doing and how work gets recovered.
Some failures leave an uncertain outcome. Imagine a waiter sends an order, the connection drops and the screen never confirms it. Sending it again could produce two dinners. The software version needs a way to check the result or recognize another attempt at the same request. Designing repeated attempts to avoid an extra effect is called idempotency. It matters for operations such as creating records or taking payments, where a retry can otherwise do the work twice. Making retries safe with idempotent APIs
The user needs a useful answer: saved, still pending, failed or safe to try again. Behind that answer, someone needs enough information to investigate. At seven on a Friday night, "the agent built it" doesn't tell anyone who's coming.
A new menu and a new booking form: safe updates
The menu changes. Seasons turn, a dish doesn't sell, a regular asks for something new. Staff need the current menu, and the kitchen needs to be ready to serve it. An application release similarly changes what users can do and what the system needs to support.
Changes to the records need particular care. Suppose the restaurant replaces its booking form and makes a contact number required for new reservations. R104 was taken on the old form, with no number recorded. The new system still needs to find that booking and seat its guests. Someone must decide how to represent the missing information and when staff should collect it.
Once people enter real records, an update has to carry their work forward. Changing fields, relationships or statuses can require a migration: translating existing records into the shape the new code expects. Other changes can be handled by code that accepts both the old and new forms. Either way, a missing phone number should remain unknown until someone supplies it.
Range of Motion's move to a different sign-in provider also meant changing how existing users were linked to their records. The migration runbook required a dry run, then a rehearsal against a restored copy, before applying the changes to production. That checks a different question from whether a new user can sign in: can an existing user still reach the work that belongs to them?
Backups and a recovery plan belong alongside that change. A backup is useful when it can be restored, and restoring an older copy can leave out bookings entered since it was taken. The plan has to account for that interval too. The restaurant needs a usable reservation book when the new service begins.
The health inspection
Opening to the public brings obligations beyond cooking a good meal. An inspection can reach into the kitchen's storage, cleaning routines and staff practices. Those parts of the operation matter even when the dining room looks finished.
The application equivalent starts with the information it holds and the people relying on it. Who should see it? How long should it be kept? What needs to be recorded when someone accesses or changes it? Those answers shape permissions, audit records, retention and recovery, and may bring legal or contractual requirements into the design.
For Range of Motion, preparing the platform for healthcare organizations included a security review. The resulting work includes access-audit records, a second sign-in step for staff, automatic idle logoff and tighter data-access permissions. The review made those controls explicit work to implement and verify, alongside the session and report people could already see.
How the architecture changes
For this shared web workflow, the interface now connects to shared records through server-side rules. These boxes are logical responsibilities: a small app can combine them in one backend or use a managed platform.
If the app has long-running work, a queue and worker can handle it outside the interactive request. Delivery, credentials, staging and failure response add further connections to manage; starred additions depend on the workload.
Where the agent fits
Agents can help build the parts around the workflow too. In Range of Motion, they carried much of the implementation: database lookups, sign-in, tests, logs and security-review changes. Each still needed requirements and evidence that it worked.
For the afternoon prototype, leaving those parts out kept the experiment small. As its responsibilities grow, the agent needs more specific direction.
For the booking application: keep a reservation's identity when its time changes, warn when another host has edited it, preserve older bookings when a new field becomes required and check those behaviors before release. Keep those decisions in the project's instructions, as I described in Give the Agent a Working Environment. The agent can implement and test against those requirements. Someone still has to decide what the restaurant promises its guests.
Ownership stays with a person. Someone answers the Friday-night call and decides what goes on next season's menu. That's the trade the SaaS post weighs: building has never been cheaper, and owning still takes someone who shows up.
Before opening night
When a prototype starts picking up regulars, I ask seven questions:
- When do people need it available? Choose where it runs, how much downtime the work can tolerate and who responds.
- What does it need to remember, and how can that change? Define the records, their relationships, valid changes and what happens when two people edit the same work. Choose storage and lookups around those needs.
- Who can do what to each record? Establish identity, permissions and checks on the operations that matter.
- Who checks changes before they ship? Set up repeatable tests and a check of the real workflow.
- What happens when an operation fails? Make the outcome visible, provide a recovery path and name who gets the call.
- How does existing work survive the next version? Plan the migration, backup and checks alongside the feature.
- What obligations come with the information it holds? Make access, retention, audit and recovery requirements part of the design.
If the idea is still an experiment for tonight, keep the dinner party small. When people start depending on its records and coming back tomorrow, build for that service. The cooking got them interested. Running the restaurant is what lets them return.