A software studio telling you to build custom software is not exactly a surprising position, so let us start with the opposite. For most businesses, most of the time, a subscription is correct. It is cheaper up front, somebody else maintains it, and it works on the day you pay for it.
But there is a threshold where that stops being true, and it is arithmetic rather than opinion.
The shape of the trade
A subscription is a recurring cost that scales with usage, usually seats. A build is a large one-off cost plus a small recurring one for hosting and maintenance. The crossover is wherever the cumulative subscription passes the build plus its running costs.
The mistake people make is comparing the build cost to one year of subscription. The comparison that matters is against the life of the capability. If you will still be doing this in four years, compare four years.
Three things that move the threshold
- Seat count. Per-seat pricing is designed to be painless for one user and painful for thirty. If your usage grows with headcount, your cost grows with headcount whether or not the value does.
- Usage intensity. Tools priced per seat but limited per usage effectively charge you twice for being a heavy user, which is the profile of anyone for whom the tool actually matters.
- Duration. A capability core to how you operate is not a one-year commitment, and should not be costed as one.
A real example
An agency approached us already paying a heavy recurring per-seat fee for a well-known clipping tool. They were not unhappy with the tool. They were unhappy that the cost scaled with their team while the capability did not change, and that their client footage was passing through infrastructure they did not control.
We built them the capability to own outright: transcription, segment scoring, cutting and captioning, running on infrastructure they control. That product became OmniClip. The build paid for itself against licences they were already paying, which is the only version of this argument that is actually persuasive.
The costs people forget on the build side
For the comparison to be honest, the build column has to include the parts that are easy to omit:
- Hosting and inference costs at real volume, which for AI systems is rarely trivial.
- Maintenance. Upstream APIs change, dependencies need updating, models get deprecated.
- The owner. Somebody internal has to be responsible for it, and that is real time.
- The features the SaaS ships that you will not, because a vendor amortises development across thousands of customers and you do not.
That last one is the strongest argument for subscribing and it is worth taking seriously. A vendor will out-feature you indefinitely. The question is whether you need those features or whether you need one thing done reliably, cheaply, and under your control.
A short test
Build when the capability is core to how you make money, your cost scales with something other than the value you get, the requirement is stable, and you will be doing this for years. Subscribe when it is peripheral, your usage is modest, the requirement is still moving, or the vendor's roadmap is genuinely doing work for you.
If you are clipping occasionally, keep the subscription. We will tell you that on the call, and it costs us the project. It also means that when we do say build, the recommendation is worth something.