Build it once,
own it forever.
Renting software is the default now, and for a lot of things that is fine. But somewhere between your fifth tool and your third renewal the maths turns, and it is worth knowing where that line sits before you cross it.
Nobody sits down and decides to rent the systems their company depends on. It arrives one signup at a time. A project tool because the spreadsheet cracked. An automation platform because two of those tools do not talk. A client portal because the automation platform cannot do client-facing. Each one is a reasonable Tuesday decision, and each one is small.
Then you hire six people, and the bill is not small. And when you ask whether one screen can work differently, because your process is not quite like everyone else's, the answer is a feature request with no date on it.
What you are actually paying for
A subscription bundles three things into one line item: software, hosting, and optionality. The software is the part you think you are buying. The hosting is real and cheap. The optionality, the right to cancel, is what makes renting feel safe, and it is the part that quietly gets expensive, because you keep paying for it long after you stopped considering leaving.
Renting stays correct while you are still discovering what you need; Basecamp's Shape Up makes the same argument about fixed appetite versus open scope. It stops being correct once your process is settled, your volume is predictable, and what you need is specific.
Four costs never appear on the invoice:
- The growth penalty. Per-seat pricing scales your software bill with headcount, not with value. Hiring becomes a line item twice.
- The glue tax. Every pair of tools that do not talk gets an integration platform between them, billed per run. Your architecture is now a subscription too.
- The workaround. The hours spent exporting, re-keying and reconciling because the tool almost fits. The biggest number, and nobody measures it.
- The roadmap you do not control. Your feature sits behind ten thousand strangers, and so does the one you depend on, which could be deprecated next quarter.
What owning it actually means
Less romantic than it sounds, and better than it sounds. Four concrete things.
The code is in your repository, under your account. Not ours. If you never speak to us again everything keeps running, and any competent engineer can pick it up, which is why we write it to be read, and why we stick to boring, documented platform APIs like Stripe's rather than clever abstractions over them.
The data is in your database. Query it, export it, join it to anything. No rate limit between you and your own history, and when regulation applies, the right to data portability is something you can actually satisfy.
The roadmap is yours. When the process changes, the software changes. A two-day job, not a feature request.
The recurring bill is hosting. Real, an order of magnitude smaller than a stack of per-seat licences, and it does not grow just because you did.
Four tools, four bills
Per-seat growth penalty
Their roadmap, their pace
Annual renewal, +18%
One codebase, one bill
Add users for free
Your roadmap, your pace
Hosting, and that is it
When we tell people not to build
We say no to this more often than you would expect, because building the wrong thing is worse than renting the wrong thing.
Do not build a solved commodity with regulatory weight behind it: payroll, accounting, payments infrastructure, email delivery, identity. The market versions are excellent, cheap relative to their complexity, and someone else carries the compliance burden, including the parts of the OWASP Top Ten you would otherwise own forever.
Do not build while the process is still moving. If how you work will look different in six months, rent something flexible and let it settle. Software is a bad way to discover your own workflow.
And do not build to save money on a tool that fits. Owning a worse version of a good product is not a win.
“The thing you do better than your competitors is the thing no tool supports, so a person does it by hand. That is not an operations problem. That is your product, un-built.”
The four signals
They tend to show up together. When three or more are true, the build usually pays for itself faster than the forecast says.
- 01Your differentiator lives in the workaround.
- 02The stack has become an integration project.
- 03The bill scales with headcount, not with value.
- 04You asked a vendor for something important and were refused.
How we ship it
One senior team and four practices, web, mobile, integrations, and the SEO that ships with the build instead of being retrofitted after launch. That ordering is the difference between a product people can find and one you have to buy traffic for; Google's own SEO starter guide and the Core Web Vitals thresholds are what we hold the front end to, and we do not ship a page that fails them.
The work moves through five gates: discovery, strategy, development, QA and launch, then growth. Discovery is where we try hardest to talk you out of scope you do not need, and where most of the cost gets saved. A first release runs three to six months. Anything shorter and we are probably the wrong fit.
When there is an existing system to replace, we rarely rewrite it in one go. Martin Fowler's strangler fig describes the approach better than we could, and it is how we keep a business running while its software changes underneath it. Infrastructure follows twelve-factor conventions so your team can host it anywhere, including away from us.
At handover you get the repository, the infrastructure in your own accounts, documentation written for whoever joins you next year, and a walkthrough with the people who built it. Then you decide whether you want us around for what comes next — see recent builds or the studio.