From the build log.
A specialist medical practice came to us with a small, clear job. They were running a conference. People needed to reserve a seat, the reservation had to be saved somewhere safe, and a confirmation email had to go out. That was the whole request: a form, and something behind it to catch what people typed in.
We could have built exactly that, and nothing more. It would have worked, and it would have been an honest day's work. But partway through, a decision was sitting in the middle of the build that had nothing to do with the conference. How we handled that decision is the real story here.
Building the kitchen, not just the meal
Think of it like being asked to cook one dinner for a guest. You can buy exactly the ingredients for that one meal and borrow a pan. Or you notice that to do the job properly you basically need a working kitchen anyway — a place to keep food, a way to organise it, a way to clean up after. And if you happen to know you'll be cooking for years to come, the sensible move is to build the kitchen now, while someone else is paying for tonight's dinner.
That was the shape of it. When you set out to take registrations properly, you quietly end up needing most of a small customer system regardless: a reliable place to keep everyone's details, a way to group people so the right message reaches the right ones, a way to send, a way to honour someone asking to be left alone, and a backup taken every night so nothing is ever lost. Build all of that for one event and then bin it, and you've thrown away a kitchen after one meal.
We already knew our own flagship ministry client, HOFMI, needed exactly this kind of system and had said so plainly. So the question in the middle of the conference job was not a technical one. It was simply: are we cooking one dinner, or are we building a kitchen?
We chose the kitchen. The conference became the first guest to use it rather than a one-off meal. Everything underneath was built to be used again, by a second organisation, with almost no extra cost the second time round — because the hard, expensive part was already done and paid for.
A client project that needs something built behind it is rarely just a client project. It's usually a piece of equipment your own business needed anyway, arriving with someone else funding the first build.
The discipline is the timing
This is not permission to gild everything. There are two ways to get it wrong, and both are easy.
If we had finished the simple conference form first and only then decided to turn it into a reusable system, we'd have been remodelling — knocking down a thing we'd just built and bending it into a shape it was never meant to hold. That is slower and more fragile than building it right from the start.
And if we had built the bigger thing with no real second user actually waiting for it, that's just spending a client's money on something we fancied. Dressed-up guesswork.
The decision only worked because it was made before the plan was locked, and because the second user — HOFMI — was real and already asking. Spotting that moment early is the whole skill. Once the first version is live and in use, the window has closed, and turning it into something reusable gets a great deal more expensive.
The honest test
Two questions, asked while the plan is still soft. First: would doing this job properly produce something we genuinely need ourselves — or just something nearby that we're tempted to want? Second: is there a real second user, or am I inventing one to justify the bigger build?
If both answers are yes, build the kitchen and let the first guest pay for it. If either is no, cook the one dinner, serve it, and go home. A conference form pretending to be a product helps nobody. A product that turned up disguised as a conference form is the best kind of work there is.
For the technical reader
The narrow build we declined would have been two endpoints, a table, and a transactional email — finishable in a session. Instead we scoped the conference as tenant one on a three-layer, multi-tenant architecture:
- A records layer as the system of record for contacts — the authoritative store of who registered.
- A self-hosted Mautic 5 instance as the marketing and nurture engine — segments, the confirmation send, unsubscribe handling.
- A Supabase layer for the live application data the front end talks to.
Each layer is independently reusable, and the conference exercises all three end to end. HOFMI — already on record as needing a full CRM — lands on the same infrastructure as the second tenant at near-zero marginal cost, because the foundation was built once. Nightly backups cover the data layer.
The cost asymmetry is the reason timing matters: generalising a single-tenant schema after it is in production and the first tenant is live is a retrofit, not a design choice — far more expensive and more fragile than scoping for two tenants before the schema locks. The skill is recognising the inflection point while the scope is still soft, and only taking it when the second tenant is real rather than imagined.