The short answer
Buy off-the-shelf software when it supports the workflow you need and its full licence, configuration, integration and operating costs are acceptable. Consider a custom build when a specific, valuable workflow cannot be supported reliably and you can fund delivery, maintenance and ownership. There is no dependable seat-count threshold or universal five-year crossover. Compare both options over the same period with your own vendor terms, observed staff work, integration requirements and exit plan before committing.
What are you actually deciding to buy or build?
Write down the result the system must produce, the people who use it, the decisions they make and the systems it must read or change. Then test a real example against the products on your shortlist. A feature list can say that approvals are supported while leaving out the exception, permission or audit step that matters to your team.
- Buy if the required workflow works with configuration you can maintain and the vendor's current terms are acceptable.
- Build if a valuable workflow remains unsupported and the business is willing to own a product after release.
- Combine the two when a bought system handles routine work but a specific differentiating step needs custom software or an integration.
These are decision paths, not claims that one option is always cheaper. A custom build still depends on third-party services, and a bought product can still require engineering.
Which costs belong in the same comparison?
Use the same evaluation period and the same expected workload for each option. Ask vendors for the applicable licence and renewal terms rather than assuming a standard per-seat price or uplift. Microsoft, for example, documents different Power Automate licence arrangements and limits; the relevant arrangement depends on the proposed use, not on a generic headline price.
| Cost line | Bought product | Custom build |
|---|---|---|
| Starting work | Licences, configuration, migration and staff training | Discovery, design, implementation, testing and migration |
| Integrations | Connector or API access, mapping and failure handling | Interfaces, mapping, tests and ongoing compatibility |
| Ongoing operation | Renewals, usage charges, administration and remaining manual work | Hosting, support, security updates and change requests |
| Leaving or changing | Export rights, data format, transition work and notice terms | Code and account ownership, handover and replacement work |
Keep one-off and recurring amounts separate. A low initial quote is not a complete cost of ownership, and an annual subscription is not the whole cost of a bought workflow.
How do you measure a workflow gap without guessing?
Observe the current process and record how often the gap occurs, who resolves it and how much time it takes. Include correction and review work, not just the happy path. AWS Prescriptive Guidance recommends establishing a baseline of current human-process costs before estimating the value of a replacement; its guidance is written for AI investments, but the baseline principle is useful for this comparison too.
observedAnnualGapCost = occurrencesPerYear
x measuredTimePerOccurrence
x financeApprovedHourlyCost
comparisonTotal = startingWork + recurringCosts
+ integrationAndSupport + observedWorkflowGap + exitWorkTreat the calculation as an estimate, not a promised saving. Mark any unknown input as unknown. If you have not observed the workaround, measure a representative sample before converting a frustration into a precise business case.
What should you test in a vendor demonstration?
- Run an ordinary case from input to completed output using your own sample data.
- Run a missing, duplicate or disputed record and inspect who can correct it.
- Check the roles and permissions needed by the people who actually operate the process.
- Ask how data, attachments and configuration can be exported and what the contract says about access after cancellation.
- Confirm the proposed licence tier, integration access, usage limits, renewal terms and support boundary in writing.
Use the same acceptance cases for a custom proposal. The point is to compare delivered behaviour and responsibility, not a polished demonstration against a speculative build estimate.
When does a hybrid approach make sense?
A hybrid design can leave routine records in a bought system and implement only the workflow it cannot handle. Define which system owns each record, how changes move between systems, and what happens when the connection fails. Otherwise the integration becomes another manual reconciliation task.
If you are weighing that split, send ApexStack the same workflow and acceptance cases you would send a software vendor. A bounded Product Blueprint can test whether the gap needs configuration, an integration or custom delivery before a larger build is quoted.
What should the decision brief contain?
- The workflow boundary, users, expected volume and success condition.
- The bought options tested and the exact step each cannot support.
- Current staff effort and error work observed, with assumptions clearly labelled.
- Required systems, data access, security constraints and exceptions.
- Vendor terms, operating owner, exit plan and acceptance tests for both options.
Ask each supplier to respond to this same brief. It makes a bought configuration, a focused integration and a custom build comparable without assuming that any seat count, market price or maintenance percentage settles the decision for your business.
Sources
- Assessing human-process costs — AWS Prescriptive Guidance
- Power Automate licensing FAQ — Microsoft Learn
Frequently asked questions
- Is custom software cheaper than SaaS in the long run?
- There is no universal crossover. Compare a vendor's actual licence and renewal terms, configuration, integrations, staff workarounds and exit costs with a custom build's delivery, hosting, support and change costs over the same period. The result depends on your workflow and terms.
- How do you calculate total cost of ownership for software?
- Choose one evaluation period and expected workload. For a bought product include licences, setup, integration, administration, observed workaround effort and exit work. For a custom build include discovery, delivery, testing, infrastructure, support, future changes and handover. Keep unknown inputs visible instead of assigning generic market percentages.
- When should you build custom software instead of buying?
- Consider building when a specific valuable workflow is not supported by available products and your team can own the system after launch. Test the gap with real acceptance cases first. If configuration or a focused integration solves it, a full replacement may be unnecessary.
- Can you mix off-the-shelf and custom software?
- Yes. A bought product can hold routine records while custom software handles a distinct workflow. Define the source of truth, permissions, failure recovery and owner of the integration before comparing that hybrid option with a complete replacement.
How can ApexStack help you make the buy-or-build decision?
Send ApexStack the workflow, the products you have evaluated, the steps they cannot support, and any licence or integration terms you already have. We can use a Product Blueprint, starting from US$1,000, to map the options, ownership, risks and acceptance checks. It is bounded planning and de-risking, not a production-ready custom system. If a tightly scoped core workflow is ready to implement, a Launch Sprint starts from US$2,500 and includes planning, UX direction, implementation, testing and deployment. Multiple integrations, data migration, advanced AI, compliance and extensive administration can increase the quote. Review the custom software service and pricing routes, then send the same brief you would use to compare other suppliers.