SaaS vs. custom software: which one should you actually build?

The phrase "we’re building a SaaS" gets used to mean three completely different things, by founders who haven’t yet decided which they actually want. This guide is the conversation we have with founders before we quote a build — clarifying which type of software your problem actually needs.

Don’t build a product when an operation will do. Don’t build an operation when a spreadsheet will do.

1. The three things people mean by "SaaS"#

When a founder says "we want to build a SaaS," they usually mean one of these:

1. A real multi-tenant SaaS product. Many customers using the same code, paying recurring subscriptions, served from shared infrastructure.
2. A custom internal application. One organisation using software built specifically for them, often replacing a spreadsheet or off-the-shelf tool.
3. A productised service. A service business with software wrapped around it, sold by the engagement, not by the seat.

These are three different economic models, three different engineering shapes, and three different conversations to have with your bank account.

2. The deciding question#

The single useful filter:

Will more than three organisations want this exact workflow, with only minor configuration?

• Yes — multi-tenant SaaS is on the table.
• No — you’re building custom software, or you should stay on off-the-shelf.

If you can’t name two real organisations besides your own who’d use the exact workflow, you don’t have a SaaS — you have a project. That’s not bad. Projects are valuable. They’re just priced and built differently.

3. Real multi-tenant SaaS#

Economic shape#

• Recurring monthly or annual revenue.
• High gross margin (typically 70–85%).
• Concentrated growth costs (acquisition, infrastructure).
• Years to profitability if VC-funded; quarters if bootstrapped lean.

Engineering shape#

• Shared codebase, shared schema.
• Tenancy isolation via row-level security, schema-per-tenant, or pooled tables.
• A billing system that can model plans, trials, upgrades, dunning, taxes.
• Per-customer feature flags, support tooling, audit trails.
• The infrastructure assumes 1,000+ tenants from day one of architecture, even if you have 5.

When it’s right#

• You’ve interviewed 30+ potential customers and the workflow is consistent.
• The unit economics work at $50–$500/month per customer.
• You’re willing to spend 2–5 years compounding.
• You’ve found a niche where horizontal tools don’t fit.

When it’s wrong#

• Each "customer" wants meaningfully different workflows.
• Your buyers expect five-figure annual contracts — that’s an enterprise sale, not a self-serve SaaS.
• You haven’t validated demand beyond your immediate network.

4. Custom software (single-tenant)#

Economic shape#

• Project fee plus optional retainer, or build-operate-transfer.
• High upfront cost, modest ongoing.
• Pays back through operational savings, not subscriptions.

Engineering shape#

• One organisation’s rules, one organisation’s data.
• Usually simpler architecture than SaaS — no tenancy isolation, no plan management.
• Often integrates with existing org tools (Slack, Google Workspace, internal databases).
• Hand-off and documentation matter more than launch marketing.

When it’s right#

• The organisation has a clear, expensive operational problem.
• Off-the-shelf tools can solve 70% but the missing 30% costs real money or time.
• You’re willing to own the maintenance long-term or fund a partner to.

When it’s wrong#

• You haven’t measured the cost of the problem in dollars or hours.
• You’re trying to fix a process problem with software.
• A no-code tool would solve 80% in a weekend.

DharBaki started as a custom application for a single shop owner before we realised the pattern was shared and re-engineered it for multi-tenancy. The reverse path — building multi-tenant from day one when you only have one customer — almost always wastes 30% of the build.

5. Productised service#

Economic shape#

• Service business pricing (per project, per month, per outcome) with software-supported delivery.
• Margins below SaaS but above pure consulting.
• Predictable revenue with high customer concentration risk.

Engineering shape#

• Internal tooling that lets one operator serve many clients efficiently.
• Customer-facing pieces are often minimal — a portal, a status page, a deliverable viewer.
• The "product" is the operator’s workflow more than the customer’s experience.

When it’s right#

• You have a deep operational skill that’s undervalued by the market.
• The work has consistent structure but irregular execution.
• You can run it profitably from year one without VC.

When it’s wrong#

• You’re using "productised service" as a euphemism for "I haven’t built the product yet."
• The economics don’t support a fully-loaded headcount.

6. The decision matrix#

The bottom row is where most founders should land for at least four weeks before committing.

7. The validation steps no one wants to do#

Before you write a line of code, ideally:

1. 20 customer interviews. Not "would you use this?" — "tell me how you currently solve this." Listen for the pain.
2. 5 letters of intent. Real names, real organisations, willing to be quoted.
3. 3 paid pilots, even at a steep discount. Money flowing changes the conversation entirely.
4. A no-code prototype. Bubble, Softr, Glide, Retool. If users won’t adopt a no-code version, they won’t adopt the polished one.

Founders who skip this and go straight to a $60K build are buying a very expensive learning experience. Founders who do it find that their first build often looks different from what they imagined.

8. The build-vs-buy filter for each piece#

Even when you decide to build, you don’t need to build everything. Default to buying for:

• Authentication (Clerk, Auth0, Supabase Auth, NextAuth).
• Billing (Stripe, Paddle, LemonSqueezy).
• Email delivery (Resend, Postmark, SendGrid).
• Analytics (PostHog, Mixpanel, Plausible).
• Error tracking (Sentry).
• Customer support (Plain, Intercom).
• File storage (S3, Cloudflare R2).
• Search (Algolia, Typesense).

Default to building for:

• Your core workflow.
• The data model that defines your product.
• The integrations that are your competitive moat.
• The UI of the things customers actually do.

A common mistake is building auth from scratch and outsourcing the workflow logic. The wrong things, in the wrong order.

9. When custom turns into SaaS (and when it shouldn’t)#

The "we built it for one customer and now want to productise it" path is more common than founders admit.

It works when:

• You built three or four custom variants and noticed the common 70%.
• Two real organisations besides the original want it as a product.
• The original customer is willing to fund the productisation or share the IP.

It fails when:

• The original was so tailored that abstracting it costs as much as a new build.
• The team has never run a multi-tenant product and underestimates the work.
• You’re hoping the productisation pays for past projects, instead of standing on its own economics.

10. A final question to settle the matter#

If you can’t fluently answer this in one sentence, you’re not ready to build:

"In one year, what would the world look like that proves this was worth doing?"

If the answer is "100 customers paying $200/month," you’re building SaaS. If it’s "we saved 8 hours a week and recovered $X in lost revenue," you’re building custom software. If it’s "I’m a one-person business making $200K/year," you’re building a productised service. All three are honest. The wrong one bankrupts you.

If you’d like a 30-minute call to test your idea against this framework, tell us what you’re building. We’ll be honest about which path actually fits.

FAQ#

Is SaaS always better than custom software? No. SaaS pays back over years through recurring revenue. Custom software pays back faster through operational savings. The right model depends on the problem, not the trend.

How do I know if my idea is a real SaaS? You can name 5 real organisations besides your own who’d use the exact workflow, with only minor configuration, at the price you intend to charge.

Can I start as custom software and become SaaS later? Yes — this is the most underrated path. Build for one customer, observe the patterns, productise once they repeat. Riskier when you build for the imagined market first.

Should I use off-the-shelf SaaS instead? Almost always, as a starting point. The 30% gap that justifies a custom build only becomes clear after you’ve hit it daily for months.

How much does a custom application cost vs a SaaS build? Custom apps for a single org typically run $25,000–$120,000. Multi-tenant SaaS builds run higher because of tenancy and billing complexity. See the full breakdown.

Want to discuss your specific case? Send us the details and we’ll be honest about which model fits.