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 is cheaper to run, faster to get live, and someone else handles the hosting, security patches, and 3am incidents. If a SaaS product gets you to 80% of your goal, the remaining 20% is almost never worth the cost of a custom build.
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.
- Licensing costs exceed build cost within 24 to 36 months. Run the numbers. A $40k build against $2,200 per month in SaaS breaks even at 18 months, then saves money indefinitely.
- Integration depth is impossible off-the-shelf. Real-time bidirectional sync between an ERP, a custom field set, and a workflow engine that doesn't exist yet: no Zapier chain holds that together long-term.
- You need to own the code. Compliance, enterprise procurement, acquisition due diligence, or regulated industries sometimes require it. There is no rental option in those conversations.
Three types of custom app, and what each costs (Australia, 2026)
Custom app development is not one thing. Costs run from $20k to $500k+ and the range is almost entirely determined by which of these you are actually building.
Shopify apps (private or public)
Apps that extend Shopify or Shopify Plus: B2B pricing rules, subscription engines, checkout extensions, POS integrations, multi-location inventory logic. These are often the most cost-efficient custom build because Shopify provides auth, payments, and a lot of the infrastructure underneath.
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
ERP, 3PL, POS, Klaviyo, Xero, NetSuite. The code is often simpler than a full application, but integration projects are never simple, because you are depending on two or more external systems to behave consistently. They rarely do.
These figures are for senior engineering work: proper architecture, tests, security review, and handover documentation. Offshore quotes arrive 3x to 5x cheaper and typically produce 10x more problems. That is not a stereotype. It is a pattern we see every time a client turns up with an offshore codebase they need us to rescue.
Where projects lose money
The same three failure modes appear in almost every blown-budget project.
Scope that grows in the brief
Every feature added before development starts costs a fraction of what it costs to add mid-build. A change in week one might cost an hour. The same change in week ten might cost two weeks.
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
Junior developers execute well. They are not positioned to make the architecture decisions that determine what you can build in month 12. A data model chosen for speed in week two can cost six weeks of rebuild at the worst possible moment.
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
The application logic might take ten weeks. Production-grade infrastructure, deployment pipelines, monitoring, security hardening, backups, and disaster recovery: that is another three to five weeks that most project briefs forget entirely. Then clients wonder why the launch date moved.
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.