Subscribe or buy your automation? Run the numbers over three years

Two quotes for the same process. One is a subscription: a modest monthly fee, live in two weeks, the vendor runs the software for you. The other is a purchase: a single fixed price that looks considerably steeper on first reading, and four to six weeks before anything runs. Put those two numbers side by side and you have compared the wrong thing. Over three years both sides move.

Subscription or buy: why three years is the right window

One year favours the subscription unfairly, because the entire build sits in the first twelve months and nothing comparable follows. Five years is guesswork, because the connected systems and the process itself change too much in that time.

Three years is roughly how long a built workflow runs without a major rebuild, provided the connected systems stay put. If four years fits your situation better, use four. The method below does not change.

What the monthly fee is actually tied to

A subscription buys you the software, the hosting, the updates and usually a support channel. That is a reasonable package, as long as you know which lever moves the price.

Four are common: the number of users, the number of transactions processed, the number of connected systems, and feature tiers that put the one capability you need behind the next plan up. A subscription that looks cheap today gets expensive at the exact moment the process does what you automated it to do, which is handle more volume.

Two more items rarely appear at the top of a price list. Contracts generally permit an annual price adjustment, often indexed. And vendors reshuffle their tiers, which moves individual features upward. Put both in your calculation even if neither happens in year one.

What a one-off build still costs every month

A fixed price with no subscription does not mean nothing costs anything afterwards. Any vendor promising that has either miscalculated or left something out.

What remains: the licence or server for the platform the automation runs on, a per-transaction cost wherever a language model is involved, and adjustments whenever a connected system changes. The difference lies in the amount, and in what the money buys. You are paying for operation and for change. Access to what has already been built does not depend on a recurring payment.

The method: seven lines, two columns

Take a sheet of paper, draw two columns, and enter the same seven lines in both, each totalled across 36 months.

• Onboarding: for the subscription, setup, connecting your systems and training. For the purchase, the fixed price covering analysis and build.
• Recurring software cost: the subscription fee on one side, platform licence or server on the other.
• Usage-based cost: per transaction, per user, per model call. Use the volume you expect in year three, not today's.
• Changes: what does it cost when a form, a tax rate or an interface changes. Often included in a subscription, a day rate on the build side. Budget two or three such changes a year.
• Internal effort: who looks after the workflow at your end, how many hours a month, and what those hours cost.
• Price increases: assume an annual rise on the subscription side even if year one is fixed.
• Exit: what does switching in year three cost. Do you get your data out in a usable format, and can the workflow be rebuilt elsewhere without starting from scratch.

You end up with two totals that can be compared. That is a different exercise from putting two entry prices side by side.

The line item that has no price

Both routes produce the same knowledge: which exceptions your process has, and which decision is correct in each of them. That knowledge is the real output of the project, and the work to get there happens either way.

Buy the build and it stays with you, as documentation and as readable logic. Subscribe and it lives in the configuration of somebody else's system, with parts of it reachable only through the vendor. None of that argues against subscribing. It is a cost that falls due when you switch, and it belongs on the exit line.

When the subscription is the better call

Subscribe when the process is a standard one that many companies run identically, such as appointment booking, newsletter delivery or a straightforward form flow. Subscribe when you are not yet sure the process will still exist in two years, when nobody internally has time to operate and monitor it, or when you want the vendor carrying the operational risk, including being reachable when something jams at three in the morning.

Build when the process sits close to your core business, when it carries exceptions no off-the-shelf product knows about, when it needs to run for years, and when you want the option of changing vendors without reinventing the process.

Say a wholesaler wants to automate order intake, and pricing follows framework agreements that exist in that shape nowhere else. A standard product either cannot represent that at all, or represents it through workarounds that make every later change expensive. That is a typical case where the build wins over three years.

What ownership has to mean in writing

"You own the result" is easy to say. It becomes verifiable at four points, and they belong in the contract rather than the pitch deck.

• You are handed the source code or the exported workflows, not merely access to an interface.
• Credentials for every connected service sit in accounts registered to your company.
• Documentation exists that lets a different provider carry on without asking the original developer.
• The thing runs on infrastructure you can reach.

Miss one of those and what you bought is a subscription with a deposit attached.

The recommendation

Put the same seven questions to both vendors and get the answers in writing. A vendor unwilling to answer what year three costs has answered it. Then calculate, then decide. In most comparisons the subscription wins year one and the build wins year three. Which of those two years matters more to you depends on how confident you are that the process will still be there.

Sophera Consulting builds this kind of workflow for a fixed price, with no ongoing subscription for the solution itself, and hands over code, credentials and documentation. Whatever running costs remain are stated in the quote beforehand, so that the three-year calculation is possible at all. The starting point is free: the automation check.