The real answer to "should I build a custom app?" is that it makes sense less often than founders assume, and more often than SaaS vendors admit.
This is the framework Sonder uses when a client arrives with a build-vs-buy question. We turn down work when the honest answer is "an existing product does this." We take it when it doesn't.
Buy first. Build when it earns its keep.
Off-the-shelf software can reduce development and operating work when it meets your needs. Compare the gaps, supplier dependence, data export, support and total cost before commissioning a custom build. A percentage of feature coverage is not a reliable decision rule.
Custom development earns its keep when:
- Your process is the competitive advantage. If fitting into SaaS logic means your team adapts to the software instead of the other way around, you are renting someone else's moat.
- The total-cost comparison supports a build. Include discovery, development, hosting, maintenance, security, support and future changes alongside the SaaS costs you can actually retire. Recheck the assumptions over the expected life of the product; savings are not indefinite or guaranteed.
- Required integrations are not adequately supported. Check existing connectors and their limits first. A custom integration may be justified by confirmed data, timing or reliability requirements.
- Ownership and access matter. Check licence terms, source access, portability and the actual procurement or compliance requirements. Ownership alone does not establish compliance.
Build vs buy: compare the full cost
discovery, development and migration
hosting, support, security and changes
licences, integration and exit costs
Use written quotes and current invoices over the same period. This is a decision worksheet, not a payback forecast.
Three types of custom app, and what to scope
Different app types need different scopes. This guide does not provide verified market price or delivery-time averages; request a written estimate for your actual requirements.
Shopify apps (custom or public)
Apps may extend Shopify with pricing logic, subscriptions, checkout extensions or integrations. Available APIs and extension targets depend on the app and store plan. Include authentication, permissions, hosting and ongoing support in the scope.
Web applications
Standalone SaaS products, internal tools, customer portals, booking systems, project management platforms. You own the stack, which means you also own auth, infrastructure, backups, and everything that goes wrong with them. Budget accordingly.
Integrations
Integration scope depends on the APIs, data mapping, failure handling, monitoring and ownership across systems. Confirm access and limits before promising real-time synchronisation.
Assess proposals by the named team, delivery examples, scope, security checks, handover and support. This guide has no evidence for numerical quality or cost comparisons between local and offshore suppliers.
Where projects lose money
Review these three common planning risks before comparing quotes.
Scope that grows in the brief
Changes introduced after scope approval can affect delivery and cost. Agree a change process and prioritise the smallest useful release.
The sign you are in trouble: your brief is longer than six pages, nothing is prioritised, and every stakeholder is listed as a decision-maker.
The fix: map user journeys, not feature lists. What does each user type need to do, in what order, to get their job done? That shapes scope. Feature lists are wishlists dressed up as requirements.
No senior engineer involved in architecture
Architecture decisions should match the data, access controls, integrations and expected use. Ask who reviews those decisions and how they test the assumptions.
If the person quoting your project cannot explain, in plain English, what database choices they are making and why, that is a flag worth acting on.
Infrastructure treated as an afterthought
Include deployment, monitoring, backups, restore testing, security and handover in the delivery plan. Quote these explicitly rather than treating them as work that appears after development.
How to scope correctly before you talk to any agency
Four questions that will save you money and time regardless of who you build with.
- What is the one thing this app must do? If you cannot answer in one sentence, you are not ready to scope a build. "Manage all our operations" is a vision statement, not a scope.
- Who is the primary user and what are they trying to accomplish? Not "admins and customers." One person, one job, described specifically. Everything else is secondary.
- What does success look like at three months? At 12 months? Numbers, not adjectives. "Reduce manual data entry by 80%" is measurable. "Make the team's life easier" is not.
- What exists today that this replaces, and what happens to the data? Migration is often as complex as the build itself. Know what you are moving from before you commit to what you are moving to.
Once you have clear answers to those four questions, a senior engineer can produce a realistic estimate. Without them, any quote you receive is a guess with a dollar sign on it.
Looking at a brief right now and not sure if a custom build is the right call? The contact form on this site goes directly to Tim. No sales team, no account manager. Send the problem and we will tell you straight.