What a two-person team should build and what it should rent

Six weeks for £40 a month

A two-person team I sat with in Vinohrady had built their own billing. Stripe primitives underneath, but their own subscription state machine, proration logic, dunning emails and invoice PDFs. It had taken about six weeks of one founder's time, and the ongoing tax was a bug every fortnight — a failed webhook, a proration edge case, a VAT rate that changed. The commercial alternative would have cost them roughly £40 a month at their volume.

When I put it that way it sounds obvious. It was not obvious to them, and it would not have been obvious to me at the time either, because the decision never presents itself as 'six weeks versus £40'. It presents itself as 'this vendor does not quite do the thing we need and the API for the thing we need is right there'.

That gap — between the honest cost of building and the cost as it appears at the moment of deciding — is what this piece is about. There is a usable line, and it is not 'build the core, buy the rest', which is true but too vague to act on.

The arithmetic that actually decides it

Run four numbers before you write anything.

1. Build cost. Your first estimate, doubled. Not because you are bad at estimating, but because your estimate covers the happy path and the cost is in the other paths.
2. Annual maintenance. The realistic figure is 30 to 50% of the build cost, every year, forever. Six weeks to build means two to three weeks a year of upkeep, permanently, from a team of two. That is 3% of your total engineering capacity gone to one internal tool.
3. Vendor cost at 10x your current volume. Not today's bill. Per-seat and per-event pricing looks free at 200 users and is a real line item at 20,000. Look up the pricing at the tier you expect in two years.
4. Switching cost if you are wrong. How many days to move off, in each direction. This is the number people skip, and it is the one that should dominate.

If build cost plus three years of maintenance is less than three years of vendor cost at 10x, building is at least arguable. Usually it is not close, in either direction, and the arithmetic decides it in ten minutes. The cases where it is close are the ones worth thinking hard about.

The expensive mistake is almost never buying the wrong tool. It is building the right tool for a problem you did not have yet.

Buy, without arguing about it

Some categories are settled. Building these is a straightforward error at two people, regardless of how simple the first version looks.

Authentication. Not because it is hard to log a user in, which it is not, but because the surface keeps growing: SSO, SCIM, MFA, session revocation, passkeys, breach response. Every enterprise deal adds a requirement. Rent it.

Payments and subscription state. As above. The state machine is deceptively deep, and tax compliance across jurisdictions is a full time job you do not have.

Transactional email delivery. Reputation management, bounce handling, feedback loops. See also every deliverability problem you do not want to own.

Error tracking, logs and uptime monitoring. These have to work when your system does not, which is an argument against running them on your system.

Data warehouse. Managed, always. Nobody at your size should be operating a database whose purpose is to be queried once a week.

The common thread: the requirements are set by outside parties — auditors, tax authorities, mailbox providers, enterprise buyers — and therefore change without your permission. Anything where an external body dictates the roadmap should be rented, because you are renting their compliance team as much as their software.

Build, without hesitating

The other side is smaller than people expect but it is not empty.

The glue between vendors. Every real system needs code that watches a webhook, enriches a record, decides something and writes it somewhere. Integration platforms sell this and it looks like a bargain until the logic has three conditions and a retry policy. A small typed worker in your own repo, in the language you already use, with your own tests and your own logs, is cheaper to own than a flow diagram nobody can diff. Build the glue. Always.

Anything that touches your differentiating data. If the thing you are selling depends on a scoring model, a matching rule or a ranking, that logic lives in your codebase where you can version it, test it and change it on a Tuesday. Vendors are fine at the substrate and bad at your specific opinion.

Internal read-only tools. A page that shows your team the ten things they need to see costs a day and saves an hour a week for years. Do not buy an admin panel product. Do not build a general admin framework either. Build the ten specific pages.

The event schema and the identity layer. You can rent the analytics product, and should, but the definitions of your events and the logic that stitches a person's sessions together belong to you, in your repo, so you can port them when you change vendor. Assume you will change vendor.

The middle, where judgement is required

CRM, marketing automation, feature flags, internal search, job scheduling. These are genuinely contested, and the deciding question is not cost. It is: how often does this change, and who changes it?

If a non-engineer needs to change the thing weekly, buy it. A marketer editing an email sequence in a UI is worth a lot of money; the same marketer filing tickets against your custom sequencer is a bottleneck that shows up as slow growth, not as an engineering cost, which makes it invisible until it is expensive.

If only engineers touch it and it changes with your code, build it. Feature flags are the clean example: a table, a cached lookup and a typed helper is a day of work and has almost no maintenance, and the vendors charge per seat for a UI your two engineers will use through the API anyway. Job scheduling is similar — a jobs table, a status column, and a worker polling with SELECT ... FOR UPDATE SKIP LOCKED handles far more load than people expect and costs nothing.

And a rule that has saved me more time than any other: do not build the second instance, build the third. The first time you need something, do it by hand. The second time, copy and paste it. Only when the third case arrives do you know the actual shape of the abstraction. Most bad internal frameworks are the second instance, generalised from one example plus an imagined one.

Two things that make being wrong cheap

Because you will be wrong, the useful skill is making reversal cheap rather than making the initial call perfect.

First, put every vendor behind your own thin interface. Not a heavyweight abstraction layer — a single module, your own function signatures, the vendor SDK imported in exactly one file. When you swap providers you change one file. This costs about two hours per vendor and is the highest return refactor available to a small team.

Second, keep the data. Whatever the vendor holds, write your own copy of the underlying events into your warehouse in a schema you defined. Vendors get acquired, change pricing, and delete history beyond a retention window. Your copy is what makes leaving possible.

What to do this week

List every system you have built in-house that is not the product. For each one, write down the four numbers: doubled build cost, annual maintenance at 40%, vendor cost at 10x volume, days to switch. Do it in a text file, in an hour.

You will find one thing you are maintaining that should be rented, and probably one you are renting that should be five hundred lines in your repo. Fix the first one this quarter, because it is bleeding time every week. Leave the second until it annoys you a third time.