Before another subscription: should you build, buy, or integrate?

01Compare the job, not the feature lists

Before buying another subscription, write down the task you need to complete, who uses it, and what is wrong with the current workaround. Compare options against that same task. A quick custom demo and a mature service are not equivalent just because their screens look alike.

Buy standard capabilities when a suitable service solves the problem at an acceptable cost. Build when the workflow or product difference justifies ownership and ongoing work. Integrate existing services when a small connection closes the gap. The right answer can include all three.

02Account for the work after the first build

For buying, include the actual seat or usage tier, setup, migration, integration, administration, and the cost of leaving later. For building, include design, implementation, review, test work, AI tools, hosting, APIs, maintenance, support, and migration. Someone's time is still a cost when it does not produce a vendor invoice.

AI can reduce parts of implementation effort. It does not remove the need to understand the result, patch dependencies, handle incidents, or adapt when an external API changes. Compare a useful 12-month and 24-month horizon with the same service expectations.

03An illustrative cost comparison

These are fictional planning assumptions in US dollars, not FST prices, a quote, or observed client savings. Imagine a ten-person team choosing a simple internal reporting tool with the same required workflow in both options. No AI runs inside the finished app, and usage and scope stay constant.

The buy option assumes $500 for setup and migration, $50 per person per month, and $200 per month of internal administration and integration upkeep. The custom option assumes $8,000 for scoped design, implementation, review, and testing, $200 of initial AI-tool usage, $500 for migration and training, $75 per month of hosting and services, and $200 per month of maintenance and support effort.

04Change the assumptions before trusting the answer

Each total is the one-time cost plus the number of months multiplied by both monthly costs. Buying is cheaper at 12 months in this example; the custom option is cheaper at 24. That result depends on the assumptions. If custom maintenance were $400 rather than $200 per month, its 24-month total would become $20,100 and buying would stay cheaper.

This simplified comparison excludes taxes, financing, growth, new features, major incidents, and the cost of waiting for the build. Add them when relevant. If your app uses an AI API at runtime, include its usage separately from the AI tools used to develop it. Estimate a conservative case as well as the expected case, and write down who will own the ongoing work.

05Check fit and ownership alongside cost

Can the service export the data you need? Does the required integration exist on the plan you are comparing? Who can access the records, and what happens when a team member leaves? Can another engineer deploy and maintain the custom app? These questions can change the decision even when the totals are close.

Before replacing a working service, try the highest-risk workflow with representative data. Confirm migration and recovery, keep an appropriate transition path, and decide what evidence would justify the switch. You can build a narrow feature around an existing service without replacing the whole system.

06Bring the workflow and the current bill

List the task, the tools involved, current costs, workarounds, and what a successful change would look like. We can use that context to decide whether the next step is configuration, an integration, a focused build, or leaving a suitable service in place.

• Discuss a focused app build
• Work through technical decisions
• How we agree on AI tools and costs