Skip to main content
DetGaao

Updated my sister's site over breakfast

I'm in Zurich visiting my sister, who runs a restaurant. I built her site a while back, and this trip turned into a morning of fixes from her kitchen table. None of them took longer than a coffee break.

June 4, 20264 min readMichael Fellner

I'm in Zurich this week, visiting my sister Barbara. She runs a small restaurant here. I built her website a while back. Building sites is something I do on the side, mostly because it's fun, and because the tools change fast enough that the only way to know what's actually possible is to keep doing it. Like any small business owner she has a real list of things she wants different about it. Most of them are tiny. None of them are urgent... and like all big brothers I make her wait.

This trip became a few minutes of "someday." Sat down with my laptop on her kitchen table, opened the project, made the changes, pushed them live. Coffee was still hot.

What her site actually does

When I first built this, I looked at the off-the-shelf restaurant templates. Probably worse. They're built fits-most-first, which usually means they're built for major urban markets the template-maker cares about. Rural Switzerland isn't on that map. The geo defaults are wrong, the integrations on offer are the wrong ones, and the assumption-set about how a restaurant runs doesn't match how hers does.

Barbara has a main menu and one that changes weekly. She didn't have a regular reservation flow, or a place where customers can order her handmade candles. Now she does. She wanted her own ordering and reservation logic, built around how she actually works. The build was end to end, from CMS to CRM to branded email accounts. The kind of thing that's easier when one person controls the whole stack and impossible when you're going through a five-week ticket queue at an agency. Granted, the 9,000 km between us made it easier to let things slide when other work got in the way.

So the site is custom. We built a process that takes the weekly menu file she already creates for social, parses it, and puts it on the site. The menu lives on the page itself, embedded into the design. A PDF download is there too, for anyone who still wants one. Reservations come in through a form and land in the systems she actually uses. Candle orders work the same way.

This week's list

Barbara had a small running list. Nothing dramatic. The kind of things that on a normal corporate stack would be "we'll get to that next quarter."

The reservation form had quietly disconnected from her CRM and the work email it should have been hitting. Reconnected. The time picker was offering slots she didn't actually have. Lying, basically. Fixed. The form was accepting blank required fields without telling anyone what was missing. Now it tells them. Small things. The kind that, individually, you don't get worked up about, but collectively make the difference between a site that works and a site that quietly leaks bookings.

The whole list took less time than her espresso machine takes to warm up.

Where the speed comes from

Every change runs through an audit before it ships. Even this week's, even the tiny ones. The audits are ones I built, code checks on the technical side and design checks on the visual side. They're reusable across any site I work on, and the build agent knows about them, so they trigger automatically before any push goes live. The bar doesn't drop just because the change is small.

The other piece is how features come in and go out. We describe what we want, the tool builds it. We describe what should go, it goes. There's no CMS to hunt through to see if a capability exists. No plugin marketplace to comparison-shop. No third-party module that almost does the thing. If the capability isn't there, we build it.

What's gone is the coordination overhead. The ticket queue, the handoff scheduling, the four people who'd be in the loop on a change this small. The audits stay in place. The build-on-demand stays in place. The coordination overhead goes. And this model scales. What works for one rural Swiss restaurant works for any small business anywhere.

Dev team of one

The pictures she had were... well, not great, let's say. So I built a process that optimizes them on the way in. Just quality and background cleanup, the kind that stops short of "over-AI-ing" her actual food. Custom to her needs. The kind of thing you don't get from a template, and you'd usually need a dev team for.

This is the part of the AI conversation I find more interesting than most of it. A small business with no budget for a developer and no patience for an agency can now have a real site, with real features that fit its real workflow, maintained by someone who actually cares about the business. Barbara's dev team is her brother. That's it. That's the whole org chart.

The question I keep coming back to is how many small businesses are about to get the software they always needed and couldn't afford. Probably all of them.

By the way, if you're in Zurich, go say hi. Her place is here. Order the special.

Oh and since you made it all the way to the end, one small ask while we're at it. The next thing on Barbara's list is connecting the site to her POS, which is Lightspeed K-Series. If anyone reading this can help us get a developer license, we owe you a round at her place. She does have a nice drink menu too.

Homepage of Babas Büezer Beiz, the Swiss restaurant site described in this post. A black-and-white photo of the Gasthaus Löwen building sits behind the wordmark 'Babas Büezer Beiz', with 'Büezer' set in italic pink, above a German tagline and a 'Wochenmenü ansehen' button.

Want help thinking through what this changes for your marketing operations?

Start a conversation