I Thought I Was Building Martin a Website. We Ended Up Building Plate OS.

I thought I was building Martin a website.

Chef Martin Condon runs Plate the Umpqua out of Roseburg and the Umpqua Valley. Private dining. Estate dinners. Wine country evenings. The kind of hospitality that lives or dies in the room, not on a homepage.

The initial brief was familiar enough. Get the work online. Make it feel like the evenings actually feel. Give people a clean way to inquire. Build something that doesn’t look like every other restaurant template with a contact form glued on.

We did that. platetheumpqua.com is live. Dark editorial surface. Real photography and video. Pages for experiences, packages, concierge, the valley. It reads like hospitality.

But if you only look at the public site, you’re missing most of what we built.

Martin and I kept talking through how the business actually runs. Inquiries. Follow-up. Menus. Events. Invoices. Partner gifts for Realtors and other professionals. Print certificates. Payment. What happens after dinner. And the project kept growing because the business kept needing more than a brochure.

We ended up building Plate OS.

Martin understands private dining in a way I never will. What guests remember. What breaks when you treat hospitality like catering. What a closing gift needs to feel like when somebody is getting keys to a house. What happens in a kitchen when the night is actually on.

I understand design, development, architecture, and how to turn a business conversation into something software can enforce without making the whole thing feel like software.

That’s the working relationship. He brings the reality of the table. I figure out how to hold it.

I’m not going to invent quotes or reconstruct specific calls. What I can show you is what landed in the product. Because once you look at the code, you can see exactly where the business started shaping the system.

The public site is Next.js, React, TypeScript. Payload CMS on MongoDB. Resend for email. Square for payments. Deployed on Vercel.

Homepage memories aren’t hard-coded filler. Published testimonials come out of the system and render on the home page. Small thing, but it matters. The marketing surface and the operating data are connected.

A lot of the visual work is what you’d expect if you’ve seen hospitality done carefully: typography, pacing, imagery, motion that doesn’t get in the way. I’m not going to spend this article congratulating myself for fonts. The interesting part is what sits behind that surface.

Because once Martin started using the system, the website stopped being the whole project.

If somebody asks what Martin got, and you only say “a website,” you’re underselling it by a mile.

Plate OS is the operator side. Authenticated. Separate from the public marketing pages. It lives under /os, with Payload Admin still available for deeper CMS work.

When an operator signs in, they land on Today at Plate The Umpqua.

That board is designed to surface the stuff that actually needs attention:

It’s a morning board pattern. What’s waiting. What’s coming. What needs a decision.

Without something like that, a private dining business usually ends up duct-taped across inbox, texts, notes apps, spreadsheets, maybe a form tool, maybe a PDF menu floating around somewhere, maybe Square on its own island.

That’s fine until volume shows up. Then it gets messy fast.

This split is important.

Operators see clients, inquiries, events, invoices, recipes, menus, Square connection status, partner sales materials. They can write internal notes. They can see culinary detail that never needs to be public. They can classify a lead. They can build a menu, send it for review, follow payment status, keep relationship notes.

A guest sees the public site, or a temporary token page.

They’re not browsing the operating system. They get the slice they need, for as long as they need it.

Somebody submits an inquiry on the site.

That doesn’t just fire an email into the void.

The request hits validation first. Then we look up whether that email already belongs to a client. If it does, we attach the inquiry to the existing record. If it doesn’t, we create one and shape it based on what they submitted: private guest vs partner/realtor-style lead, VIP flags when the budget/source warrants it, preferred experience style, relationship notes.

Then the inquiry itself gets filed: source, guests, region, occasion mapping, priority, status.

Then Resend sends a branded notification with reply-to set to the guest.

So when Plate OS opens, the inquiry isn’t something you have to reconstruct from an email thread. It’s an actual record you can work.

Recipes live in the system with chef notes and public-facing language.

Menus get built from those recipes into sections and items. They can be revised, keep history, and move into a state ready to send.

When guest feedback is needed, the system generates a review token, stores a hash, sets an expiration, and can email a link. The guest opens a temporary review page. They see the presentation version. They don’t get the kitchen notebook.

That’s the kind of thing that sounds minor until you’ve watched a hospitality business try to do it over email attachments.

Invoices are Plate records first.

Line items. Totals in cents. Client billing info. Internal notes. Status.

When it’s time to collect, Plate can create a Square hosted payment invoice from that record. Square handles the hosted payment surface. Plate stays the source of truth for the business document. Webhooks synchronize payment evidence back into Plate.

The operator sees the operational invoice.

The customer sees the public invoice / pay experience.

Same money. Different sides of the glass.

This is where the project got really interesting.

Private dining for homeowners is one business. Professional gifting is another.

Realtors, doctors, attorneys, builders, sales teams. People whose work depends on relationships. People who are tired of dropping another basket on a counter and calling it gratitude.

For real estate, the occasion brand is Welcome Home — Welcome Home Private Dining as a prepaid closing-gift experience inside Partner Concierge.

The offer landed like this:

That didn’t start as a webpage. It started as a business conversation. What should be included? What feels complete as a gift? What should the professional prepay so the recipient never feels like they got a half-paid evening? What happens at closing? Who presents the certificate?

Once those answers got clear enough, they became rules. Then pricing. Then code. Then pages. Then checkout. Then print.

Here’s the actual chain:

For Realtors, the human flow is simple:

Buy the package. Present a Welcome Home certificate at closing. Homeowner redeems later. Martin coordinates the evening.

We could have kept going. QR redemption. Scheduling portal. Automated fulfillment. Certificate inventory tracking. The whole machine.

We didn’t.

Once somebody has that certificate in their hands, Martin taking over is better. The homeowner isn’t wrestling a booking widget during move-in week. Menu, timing, dietary notes, the actual evening: that’s hospitality. Automating the purchase made sense. Automating the human part of redemption just so we could say “fully automated” would’ve been dumb.

The certificate config even says it out loud. Print design system. Bulk inventory. Handwritten Presented To / Presented By. No QR generation. No redemption engine. No fulfillment logic.

Purchase is software. The dinner stays Martin’s.

Explore the live Partner Concierge surfaces: Partner Concierge and Welcome Home for real estate.

I’m going to say this plainly: a huge amount of this project is invisible.

Validation. Role checks. Revalidation after writes. Environment variables. Integer cents for invoice math. Webhook reconciliation so Plate and Square don’t drift. Robots rules so Google doesn’t index /os and /admin. Print CSS so a certificate survives contact with a real printer. Mobile fixes because Payload create screens were miserable on a phone, so day-to-day create flows got redirected into Plate OS instead.

None of that makes a pretty homepage screenshot.

All of it is why the homepage can stay calm.

If a site looks simple, that doesn’t mean the build was simple. Sometimes it means a lot of complexity got handled underneath so the guest never has to think about it.

This is the same pattern that shows up across hospitality work, luxury website experiences, and broader platforms thinking at KXD. More on that in related Journal pieces like when a business has outgrown its tools and what disconnected tools are costing you.

I keep coming back to the same thing.

Martin didn’t need a prettier layer on top of a messy operation. He needed the public experience and the operating system to grow up together.

That’s why Plate has a hospitality website people can feel, an inquiry pipeline that creates records, menus with guest review links, invoices connected to Square without giving Square the whole brand relationship, Partner Concierge with real pricing rules, Welcome Home certificates and sell sheets, analytics and schema wired to the actual offer, and deliberate blank space where automation would make the experience worse.

Some of this started as website work. Some of it became product work. A lot of it was just us following the business wherever it pointed next.

You can see the thinner portfolio summary on our Plate the Umpqua work page. This Journal piece is the deeper version — closer to what actually got built.

I thought I was building Martin a website.

We built Plate OS. And we’re still in a position to keep building on it, because the foundation isn’t a theme. It’s a system shaped around how Plate the Umpqua actually runs.