Build vs Buy Software When Your SaaS Workflow Stops Fitting

When a SaaS workflow stops fitting, compare replacing it, extending it and building only the missing capability. First eliminate options that fail mandatory requirements. Then compare delivery time, operating responsibility and total cost under the same assumptions. A custom build needs evidence that its benefits justify the work it displaces.

The decision in brief:

• A mandatory requirement is a gate, not a score that cheaper pricing can offset.
• Buying still leaves customer-side configuration, access and data responsibilities.
• Building requires funded ownership after launch, not just a delivery budget.
• Hybrid adds integration work; it is an option to test, not the default winner.

What exactly are we deciding to build or buy?

Decide on a bounded capability, not the whole company stack.

“Replace our software” is too broad. “Support approval exceptions without re-entering customer records” is a testable problem. Write down who uses that workflow, where it fails and what a successful outcome would look like.

Compare buying or configuring another product, extending the current one and building the missing capability. Include doing nothing if the current inconvenience may cost less than a change. A differentiated product can still depend on standard services; an ordinary workflow can have unusual constraints.

Which requirements should rule an option out?

Reject an option that cannot meet a genuine must-have before assigning preference scores.

Turn each must-have into an acceptance test and name the person who can approve the evidence. Examples include:

• Completing the hardest workflow without an unacceptable manual workaround.
• Meeting the required security, accessibility, residency and recovery conditions.
• Exporting the records and relationships needed for a usable migration.
• Operating within the team’s available support capacity.

An untested requirement is unresolved, not a pass. For a build, an architecture promise is not equivalent to a demonstrated capability: use a focused prototype and identify what remains unproven.

The UK Government Digital Service recommends testing a small but difficult problem and integration with current products before buying. Its purchasing-strategy guidance concerns public procurement; those testing principles are useful here without treating government purchasing rules as universal requirements.

When should we buy, build or use a hybrid?

Choose the option whose fit and operating demands match the business, rather than assuming ownership or speed settles the decision.

Buying does not eliminate responsibility. Microsoft’s shared-responsibility model retains customer responsibilities for data, settings, identities and access even with SaaS. Check the actual service agreement and controls rather than assuming the supplier owns everything operationally.

Building moves more responsibility onto your team: deployment, patches, backups, recovery, support and change. Confirm source access, modification rights, third-party licences and transition arrangements in the engagement; custom software is not automatically portable just because you possess its source code.

How can we score the options without manufacturing certainty?

Use weighted scores to expose judgments, then test whether the conclusion survives plausible changes.

Agree weights before scoring. For each criterion, define what poor, acceptable and strong performance mean in your context. Use 1 for poor, 3 for acceptable and 5 for strong performance, with 2 and 4 between those anchors; higher is always better. Record the evidence and confidence beside every score.

Illustrative scoring example, not a benchmark or Mobilions project result. All options below are assumed to have passed the mandatory gates; that assumption must be verified in a real decision.

Multiply each score by its percentage weight, add the products and divide by 5. These are proposed decision weights, not research-derived thresholds. Avoid counting the same benefit twice under fit and adaptability.

Hybrid leads this invented example, but lowering its workflow-fit score from 4 to 3 reduces its total to 69. That is a reason to test the disputed workflow, not declare a winner from the original spreadsheet. A close result does not automatically justify hybrid.

How should we compare the cost over time?

Compare equivalent requirements and operating periods, including the work each option leaves with your team. For the build side, see what custom software costs.

Account for evaluation, implementation, migration, training, subscriptions or usage, internal administration, infrastructure, maintenance, changes and eventual exit. Use the supplier’s actual pricing units and terms rather than assuming every product charges per seat. Custom operating costs can also rise with demand.

Hypothetical arithmetic example, not a vendor quote, Mobilions estimate or industry benchmark. All amounts are USD. Assume equivalent scope and service levels, setup before 36 months of operation, and average paid seats of 100, 150 and 200 in successive years. The invented SaaS price is $50 per seat per month, and internal labour is fully loaded allocated cost, not necessarily extra hiring.

The build’s assumed hosting costs are $18,000, $24,000 and $30,000 by year; maintenance and planned changes are $40,000, $45,000 and $50,000. The bought option includes $15,000 a year for customer administration, support and integration upkeep. Build-side managed-service subscriptions are included under hosting; no additional application licences are assumed, rather than claiming custom software never has licence costs.

Buying is $42,000 lower here. Changing only the subscription assumption to $60 per seat per month makes buying $414,000, which is $12,000 above the unchanged build estimate. Neither result predicts what a real supplier or build will cost.

This example excludes tax, inflation and discounting. It assumes an exit after year 3; without that event the totals are $345,000 and $387,000. Assess delivery delay and business benefits separately, and do not count the same staff time again as an opportunity-cost charge.

A real hybrid needs its own estimate for both subscriptions and custom work. Do not price it as the average of the other two options.

What does Baba show about the component boundary?

Baba illustrates a component-level choice, not replacement of an ill-fitting SaaS product.

The Baba case study describes native clients and a custom model router integrated with Supabase authentication and real-time sync. It explicitly describes using Supabase real-time subscriptions rather than building a custom sync server.

The clarified comparison was with self-managed PostgreSQL, not another managed service. These scopes must stay separate:

Supabase’s architecture documentation identifies Postgres, authentication and API services as separate components. A database alone is not an equivalent replacement for the whole backend. No project savings are asserted here.

From our projects

My comparison was with self-managed PostgreSQL, not another managed service. At that level, I was focusing on how much infrastructure control we keep and how much database-operation work we take on. The main limitation I would knowingly accept is less infrastructure control in exchange for faster development and less maintenance.

A complete custom backend is a broader comparison. It also includes the authentication, APIs and service patterns that Supabase provides. I would need to account for those capabilities rather than compare a database alone with the whole platform.

Accepting the built-in patterns is part of the trade-off to reduce development and maintenance work. That is the reasoning behind the comparison, not a measured claim about saved hours or lower project cost.

When should we avoid committing to this approach?

Do not turn a useful comparison into a commitment while its deciding assumptions remain untested.

• Avoid a build with no accountable post-launch owner or maintenance budget.
• Avoid buying a product when its workarounds undermine the essential workflow.
• Avoid hybrid when API restrictions or unclear failure ownership make the boundary unreliable.
• Avoid treating a high score as permission to ignore a failed mandatory requirement.

What should we record before committing?

Keep a short decision record with the selected option, rejected alternatives, evidence, owner and review triggers.

Record the operating assumptions and the event that would reopen the decision, such as a renewal, a failed integration test or a material change in demand. Test export and recovery rather than accepting “no lock-in” as a promise. The Government Digital Service’s cloud lock-in guidance explains why both contractual and technical dependencies matter, including when managed services justify some dependence.

If building wins, move the accepted requirements into discovery and delivery planning. Our custom software development process explains what happens after that decision, from discovery through ongoing support. If you need an outside team for that work, use our questions to ask before hiring a software development company before selecting one.

Frequently asked questions

If your team has outgrown a SaaS workflow but cannot afford to sacrifice the product roadmap, bring the failing workflow, must-haves and shortlisted tools to a custom software development discussion with Mobilions. Start with the capability that needs to change, not a commitment to rebuild everything.