The right question isn't which one is better
It's which one fits this process, in this company, over this horizon. Buying a subscription and building custom are decisions with different risk profiles, and neither is inherently cheaper.
It's also worth discarding the false dilemma: in practice the most frequent answer is mixed. You buy the standard for what's standard —accounting, payroll, e-invoicing— and build only the piece that doesn't exist on the market, integrated with everything else.
When buying wins
When the process is standard and regulated, buying almost always wins. E-invoicing in Colombia changes with regulation, and keeping it up to date is permanent work that a specialized vendor does better and more cheaply than any internal team.
It also wins when you need something working this month and not next quarter, when the number of users is low —per-seat licenses are cheap up to a point— and when the process isn't a competitive differentiator. Nobody wins customers by having a different payroll.
- The process is standard: accounting, payroll, invoicing, e-signature
- Regulations change and someone else should be in charge of keeping up
- You need to be running in weeks, not months
- Few users: the cost per license doesn't weigh much yet
When building wins
When the process is precisely the company's advantage. If the way you schedule production, route shipments or settle with suppliers is part of why you do well, forcing it into a generic product means giving it up to save on a subscription.
Also when you've already evaluated three tools and none fits without heavy configuration work; when you pay per-user licenses for people who use two screens; and when you've spent years adapting the operation to the software instead of the other way around. That last sign is the most expensive and the least noticed, because the cost is paid in small daily inconveniences nobody invoices.
- The process is the business's differentiator and no product models it well
- Many occasional users paying for a full license
- The operation is being bent to fit the tool
- Integration with what already exists is half the problem
The number almost nobody calculates
The valid comparison isn't license price against development price. It's total cost over a three-to-five-year horizon, and that brings in things that don't appear on any quote.
On the subscription side: per-user licenses projected to the expected growth, modules charged separately, the cost of the initial implementation, integrations and —the forgotten line item— how much it would cost to leave in year four if the vendor raises its prices or shuts down.
On the custom side: initial development, monthly infrastructure, corrective maintenance and evolution. That last line item is the one that gets underestimated; in-house software without an evolution budget ages until it becomes the problem it came to solve.
- Licenses projected to the number of users you'll have in three years
- Implementation, integrations and data migration, in both cases
- Infrastructure and monthly maintenance of in-house software
- Exit cost: what happens if you have to change vendors in year four
Three situations where the obvious answer fails
The first: “buying is cheaper”. It usually is in the first year, and stops being so when the number of users grows or when the necessary customization ends up costing more than the development you wanted to avoid. It's worth checking how much of the implementation is heavy configuration.
The second: “we're unique”. Almost every company believes its process is special, and in most cases the special part is ten percent of the flow. The useful question is whether that ten percent is what makes you money. If it isn't, change it and buy.
The third: “we'll develop it in-house”. It's viable with a stable technical team that has spare capacity. It's risky when it ends up depending on a single person: the knowledge leaves with them, and recovering an undocumented system costs more than buying would have.
What to ask before signing, in either case
Most regrets don't come from choosing wrongly between buying and building, but from not asking four things in time. They apply equally to a subscription contract and to a development contract.
First, how do I get out. Ask to see a real export of your data, not the promise that it exists: format, scope and whether it includes attachments and history. Second, what happens to integrations when the other side changes: who handles the adjustment and with what response time.
Third, what is charged separately. Modules, additional users, test environments, support hours, scope changes: the list of what isn't included says more about the real cost than the headline price. And fourth, who inside your company ends up knowing how this works, by name and with time allocated.
- Full data export: format, history and attachments, demonstrated
- Who is responsible, and the response time, when an integration breaks
- An explicit list of what is charged outside the base price
- Who is trained internally, by name and with time allocated
How to decide in an afternoon
Write the process down in steps. Mark which ones are standard and which are specific to your business. If the specific part is marginal, buy and adjust the process. If the specific part is the heart of the matter, build that part and buy the rest.
Then run the numbers over three years, with both options at the same level of detail and including integration and exit. And finally, ask yourself who will operate and evolve whatever remains: if the answer is “someone will look into it”, the lowest-risk option is the one that depends least on that someone showing up.
A final warning about who is advising you. A vendor that resells licenses has an incentive to recommend buying, and a software house has an incentive to recommend building. It's worth asking point-blank how the person giving you the advice makes money.