Designing the Back of House

The problem

A private chef's bookings lived in her inbox — dates, headcounts, allergies and deposits buried in month-long email threads, with no record outside Gmail.

The decision it turns on

Treat an inquiry as a conversation, not a checkout. The form starts it, the dashboard holds it as it moves, and the portal never claims anything it can't actually know.

What happened

Live since September 18, 2026. Three inquiries, four journal entries she posted herself, and not one message asking me to change anything.

The Challenge

Bookings that live in an inbox

A private chef's business runs on inquiries. Someone writes in about a birthday for eight, mentions a gluten-free guest halfway through a paragraph, doesn't know the date yet, and asks whether a rental kitchen is a problem. The chef answers from her phone between services. A month later the same thread holds the deposit, the menu, a headcount change and a nut allergy, and the only record of any of it is a search through Gmail.

Kinda French Kitchen needed a website, and the site took most of a five week build. But the site was never the hard part. The hard part was the working side: somewhere for those inquiries to land, move, and turn into dinners without anyone messaging a developer to change a price or block a weekend.

my take ✦

The code is AI-written, to my direction. The product decisions, the interface, the language, and the rules it has to hold to are mine.

The Overview screen of the chef dashboard, headed The pass, showing counts for new cards, in conversation, confirmed dinners and posts, a pipeline breakdown and the next confirmed dinner — **The pass.** The opening screen answers one question — what is waiting on me — before it offers anything else.

Why not an off-the-shelf booking tool: they assume a service that fits a slot — pick a time, pay, done. Private dining is not that. The date moves. The party grows. The price depends on a conversation. So the brief I set myself was to build the tool a chef would actually use, and to make every part of it honest about what it knows.

The Insight

It's a conversation, not a checkout

The booking page on the public site says it out loud: "No calendar widget. Just a conversation." Four steps a guest can read in ten seconds: you send the card, I write back within a business day, we settle the details and a deposit holds the date, you host.

Once you accept that framing, most of the product decisions fall out of it.

The inquiry form asks for a name and one way to reach you. That's the only thing that blocks a send.
Occasion, date, party size, venue and message are all optional — and the form doesn't nag before sending. It lists them back afterwards: "You left out the date, that's fine, I'll ask."
The time field is free text, because "early evening" is both a truthful answer and, for a private chef, a normal one.

A blocked submit is a lost lead. An incomplete one costs the chef one follow-up email.

my take ✦

The instinct in every form is to collect everything up front. For an inquiry that's backwards. The form's job is to start the conversation, not to finish it. The dashboard's job is to hold the conversation as it moves.

The Product

The card wall

Every inquiry arrives as a card, and the board has four columns that mirror the conversation: New cards, In conversation, Confirmed, Declined.

Inquiries board with four columns — new cards, in conversation, confirmed and declined — each card showing a guest name, the occasion, party size and date — **The card wall.** Four columns, and the count on each is the answer to “how much is waiting on me.”

There's deliberately no "Completed" stage. A past confirmed dinner is just a confirmed card with an old date; the portal works out "past" from the calendar rather than asking the chef to do bookkeeping after every party. "Declined" is a bucket for "it isn't happening," which includes the very common case of a guest going quiet, not just a no.

A Correction

What they wrote stays theirs

The first version of the card editor locked almost every field, on the principle that the portal should never quietly rewrite what somebody submitted. The instinct was right and the conclusion was wrong. The chef's words during review: "these are suggested ranges but final varies right?" Exactly. A guest asks for the 10th with ten people, and the dinner ends up on the 9th with twelve.

An opened inquiry card. The left column shows the guest's email, phone, occasion, venue and their message under a heading reading you can't edit this. The right column, headed The Plan, holds an editable date calendar — **Two halves, two rules.** Left is the record and it never changes. Right is the plan, and it moves with the conversation.

So a card is two things. The record — name, email, phone, occasion, venue, the message — is never editable. The plan — date, end date, time, party size — moves with the conversation, and the first time it's edited, what the guest originally asked for is kept underneath.

The help note says it in the chef's terms: "The plan is yours to change. What they first asked for is kept."

One Rule

Confirming closes the night

The public booking form and the chef's calendar read the same list of closed days. Move a card to Confirmed and that night greys out on the booking page immediately, so nobody can book her twice. Block a four-day trip on the calendar and the booking form stops offering those days.

The date field on the public booking form, showing November 2026 with six consecutive days struck through and the note that greyed-out days aren't available — **Two ways in, one derived list, one thing the guest is told.** The arrows only run one way — nothing a guest does can close a day. On the right, the same rule arriving on the live booking form: six days struck out from a trip she blocked in the diary, and the guest is told they aren't available and nothing else.

The calendar with a day selected. A side panel headed What is it offers Away, Fully booked, Holding, and Something else with a free text field — **Four kinds of closed, and an open one.** Away, Fully booked, Holding — or anything she types, because a dentist appointment shouldn't need a developer.

A day can be Away, Fully booked, Holding (someone's deciding), or anything she types, because she may want to block a dentist appointment and an enum would need a developer.

Guests are told exactly one thing about any closed day: "Not available." "Fully booked" was cut from the public side on purpose; it announced which nights she has work.

my take ✦

The two-way calendar is the feature clients notice. The part I'm prouder of is that it's one rule: a confirmed dinner is a closed day. I specified it as a repair rather than a setting — every save re-derives the relationship instead of trusting it was set correctly once. It broke once during the build. It hasn't since.

Editing

Draft, then publish

Services, prices, the about page, FAQs, SEO titles and contact details are all editable in the portal. None of them go live when saved. Edits sit as a draft, the site keeps showing the old words, and the button says so.

The Pages editor after an edit. The sidebar shows Save draft, Publish to the site and Discard draft, with a line reading saved as a draft, the site still shows the old words until you publish. A dot marks the edited service — **Saved is not live.** The dot marks what's changed; the line under the buttons says what that does and doesn't mean.

This isn't editing-with-an-undo. It's the difference between the chef rewriting a paragraph over three sittings and a guest reading sentence one of it. Things a stranger never sees mid-thought — moving a card, blocking a day, a private note — skip the draft step and save straight through.

Copy the chef hasn't signed off yet is marked in red on the live site until she clears it, so "still placeholder" is visible on the page instead of buried in a spreadsheet.

The Rule That Shaped The Most Code

Which kind of nothing

An empty screen must never hide a failure.

An inquiry board with no cards can mean a quiet week, or a database that stopped answering. Early on, both looked identical, and the reasonable assumption for a chef with no bookings showing is the first one. So the board now distinguishes them and says the useful thing: "Couldn't load your inquiries. This is a problem reading them, not an empty board. Nothing has been lost."

The Journal screen. A drafts panel reads no drafts, the desk is clear. Above it a notice explains that starting a new post needs a database, which the demo does not have — **Two different nothings, two different sentences.** An empty desk says so plainly; a thing the demo genuinely can't do says that instead of failing quietly.

The same rule caught a real bug. During review, fifteen journal photos were uploaded; three appeared, twelve failed with no message at all. A hosting limit was rejecting the files before the upload code could explain anything. The fix was twofold: shrink photos in the browser before sending, and treat "silent" as a bug class in its own right, with a catalogue of every place the portal could claim something it had no way to know.

That's also why "Write back" is a prefilled email rather than in-app messaging. The chef's reply belongs in her own sent folder, and the portal can see that a compose window opened and nothing more. Any column claiming "sent" would be a guess stored as a fact.

Access

Doors without passwords

Signing in is an emailed code, so there are no passwords to remember between services. Being able to receive email proves only that a mailbox exists, so access is a deliberately short staff list: the chef as owner, me as read-only builder.

I specified three checks on every save — hidden controls, a readable refusal, and the database's own rules — and only the third one is security. The first two are interface design; the third is the one that matters, because a dashboard that trusts login alone hands the guest list to anyone with an email address.

Language

Written like a kitchen

Each tab is named for a room, not a database table: The pass (overview), The card wall, The diary, The words, The ledger, The office. The nav runs in the order of a working day.

The calendar screen headed The diary, with an explanation that confirmed dinners land here on their own and blocking a day stops the booking form offering it, beside a panel headed Pick a day — **The diary, not the calendar table.** Every screen explains itself in what it does to her week, not in what it does to the database.

Every screen has a small "?" that opens a one-time explainer written in operational terms — "Confirming closes that night on your booking form, so nobody can book you twice" — because the chef asked for "a little instruction manual so it's not taking up too much real estate."

The SEO note even warns that after publishing "your website will look exactly the same, and that isn't a mistake," pre-empting the one support message every SEO field generates.

By the numbers

What it adds up to

Two weeks for the dashboard, August 24 to September 7, inside a five week site build. What that bought, counted after launch rather than before it:

inquiries through the card wall since launch

journal entries she posted without asking me how

messages asking me to change something

12 of 15

photos that failed silently in review, and became a design rule

Since launch

In her hands

The site and the portal went live on September 18, 2026. In the twelve days since: three inquiries through the card wall, four journal entries posted, and a calendar filling with her own unavailability and appointments. No messages to me asking for a change. Nothing has broken.

Twelve days and three inquiries is not proof of anything. It is the first evidence, and each piece of it happens to test a decision that was made on an argument rather than on data:

She posted four journal entries without asking me how. That is draft-then-publish surviving a first encounter. It was the part I was least sure about — saving something that deliberately doesn't go live is unusual enough to need explaining, and the explaining had to happen without me in the room. That's what the one-time explainers were for, and this is the first sign they worked.
She blocked her own dates, and the booking form stopped offering them. The one rule holding in her hands rather than in review.
Three inquiries arrived and none of them needed me. The form's job was to start the conversation, not finish it; the dashboard's was to hold it as it moved. Nothing in that chain routed through a developer.

Coming from someone who had no idea how to do anything — you gave me a little home portal and explained everything so clearly. The fact that I was able to move stuff around on my own before even chatting with you… I feel so capable.
Kaylee, Kinda French Kitchen

Moving cards before asking me how is the sentence the room names and the one-time explainers were written to earn. It is also the only measure of them I trust more than my own opinion.

What I don't know yet is the part that matters most. Whether the card wall still reads at thirty cards instead of three, and whether "Declined" stays honest when a guest simply goes quiet for a month, both need a season rather than a fortnight. Those are the first two things I'd instrument.

Scope

What it doesn't do yet

Card deposits and invoicing stay outside the product for now — a deposit holds the date and comes off the final bill, handled the way she already handles it.
There's no self-serve booking, by design.
Guest replies still arrive in her inbox rather than on the card.
The SEO tab shows what's published, not what's working. That needs Search Console and weeks of data, and it's a later phase.

Each of these is written down in the portal's own help notes as "not yet," because a tool that implies a feature it doesn't have is the same bug as an empty board that hides an error.

Try it

The whole thing runs as a public demo

Sample data, no signup. Move cards between columns, edit a plan, block a weekend, save a price as a draft. Nothing you change is saved, and a refresh starts you over.

Open the demo dashboard

Sample data only — the real portal holds a client's inquiries and is not public.

my take ✦

Most of what I'm proud of here is invisible: the portal never says something it can't know. Every decision above came from one question — what would the chef reasonably assume if this screen were wrong?

Designing the Back of House

Bookings that live in an inbox

It's a conversation, not a checkout

The card wall

What they wrote stays theirs

Confirming closes the night

Draft, then publish

Which kind of nothing

Doors without passwords

Written like a kitchen

What it adds up to

In her hands

What it doesn't do yet

The whole thing runs as a public demo

I design products and ship them