Subscription or custom build, and how to work out which is cheaper

Short answer. Compare totals over the same period rather than prices. A subscription is billed monthly and grows with headcount. A build is paid once and then needs money for maintenance. Where those two lines cross is the answer, and working it out takes an evening. For most jobs the subscription wins. There are exactly four reasons to commission your own system, and saving money is not one of them.

Somebody offered to build you a system instead of selling you one. One quote is monthly, the other is a single number, and comparing them head to head does not work.

Why can the two prices not be compared directly?

Because one of those payments repeats every month and the other does not.

A subscription has two variables and the second one usually goes unnoticed. There is the price per seat, and there is the number of seats. The first rises when the vendor changes its pricing. The second rises when you hire. A company of twenty becomes a company of thirty in two years, and the bill grows by half on its own, without a single decision from you.

A build has a repeating part too, and it gets forgotten the same way. Your own system needs somewhere to run, somebody to fix it, and somebody to update its dependencies once a year. Count that part upfront, or the comparison ends up skewed in the other direction.

The sum is simple. Take a three-year horizon and compare two numbers. First: price per seat, multiplied by seats, multiplied by thirty-six months. Second: the build price plus thirty-six months of maintenance. Run it on the headcount you expect, not the one you have.

A horizon shorter than two years favours the subscription almost every time, and there is nothing to argue about there. A build does not pay for itself in that window even when everything goes well, and it adds risk from day one.

What do you actually get in each case?

Access in one case, code in the other. The difference shows up on the day you stop paying.

The process row is the one that matters. Data exports from almost everywhere by now, and in several jurisdictions that is a legal requirement rather than a courtesy. But the way the service handled your enquiries, calculated your discounts and moved deals along cannot be exported at all. It leaves with the subscription, and your workflow gets rebuilt from scratch on the next one.

The breakage row cuts both ways. You cannot fix somebody else's service, and you also do not pay to have it fixed. You can fix your own whenever you like, and you pay every time.

There is a longer version of this argument, which we wrote when Nvidia bought Hugging Face: what your system is built on, and what breaks if a supplier changes its terms. It is worth reading before you decide.

A custom system also runs on somebody else's hosting, somebody else's models and somebody else's libraries. It does not make you independent. It moves the boundary of your dependence somewhere else, and sometimes that is worth paying for.

When is the subscription the right answer?

Almost always. Particularly when your job is the same job everybody else has.

The test for a standard job is easy: if thousands of companies your size have the same problem, the software is already written and somebody else already paid for it. Email, bookkeeping, invoicing, file storage, phone systems, basic CRM. Your own version will cost more, arrive later and work worse, and no amount of care in the build changes that.

Behind a finished product sits a history of other people's mistakes. Somebody already lost data on it, hit the double-charge bug and found the permissions flaw, and all of it was fixed before you arrived. Your own system walks that road from the start, at your expense.

Time to launch is a separate line that almost nobody factors into the calculation. A subscription starts the day you pay. A build takes months, and through all of them the job sits there while people do it by hand. We put an hour of somebody's time at roughly thirty-four dollars in the piece on what a unit of content costs, which is our own figure from one specific calculation rather than a market rate, but the order of magnitude holds. Three months of waiting costs more than you might think.

We make our money on builds and we are saying this anyway. If the job is standard, buy the subscription.

When is a custom build worth commissioning?

There are four reasons, and none of them sounds like "it works out cheaper".

1. The process is what separates you from competitors. The test is simple: customers choose you because of it, and you hear that on calls. A process like that does not fit into somebody else's fields, because those fields were designed around an average user and you are not average.
2. The per-seat price grows faster than the company. When the vendor charges for every head and everybody needs an account, the bill outruns revenue. Run that sum on the headcount you expect in two years.
3. The integration does not exist and never will. A local bank, a government system, the equipment in your warehouse. The vendor will not build it for you, and working around it by hand takes hours every week.
4. A law or a client demands it. Where the data is stored, who can reach it, what happens during an audit. Sometimes the answer to that is flatly incompatible with somebody else's cloud.

If none of the four applies, you already have your answer. Buy the subscription and revisit this in a year, when you have numbers.

The industry is arguing about the same thing on a larger scale. TechCrunch Disrupt in October has a session titled "What Happens When OpenAI Ships Your Roadmap", about what a founder does when a large platform builds their feature in for free. The panel has not happened yet, so there are no conclusions from it. But the question is yours, and at your size it gets settled by a spreadsheet in one evening.

We do both: we connect finished services and we write custom systems. Which one fits when is set out on the custom development page. Start with the spreadsheet though: two columns, thirty-six months, and an honest headcount for two years out.