Most founders I talk to end up stuck in one of two ways. Some have bought every SaaS tool their industry recommends and now spend half their week exporting CSVs, reconciling duplicates, and training new hires on the workarounds. Others have commissioned a custom build that’s six months in, €80k deep, and still two quarters away from anything usable.
Both situations are avoidable. What neither founder had, at the point they had to decide, was a way to actually reason about the choice. I’m not talking about a spreadsheet of features, or a pros and cons list from some LinkedIn post. Just a small, memorable framework sharp enough to apply to their own situation.
This is that framework. It’s the conversation I have on most first calls.
Start with the default: SaaS usually wins
SaaS is cheap upfront, fast to deploy, and (this is the part that’s often underrated) reversible. If you pick the wrong CRM you can export your contacts and try a different one next quarter. If you commission the wrong custom app you’re going to be arguing with a rewrite for the next year.
For most of what a business runs on, that’s plenty. Accounting, payroll, email, helpdesk, a general-purpose CRM for standard sales motions: these are solved categories. Dozens of vendors compete on price and features, and honestly the differences matter less than founders think. Pick a reasonable one and spend your energy where your business is actually hard to replicate.
I say this as someone who builds custom software for a living. I’ve turned down work when the right answer was “buy this €40/month tool instead.” If a framework always lands on custom, it’s just a pitch with extra steps.
The hidden ceiling
SaaS stops being the cheap option in a few specific places. Four to watch for.
The 1% user problem. Vendors ship what their median customer wants. If your workflow is specialized, because your industry is niche, because your process is better than the industry’s, or because you handle a case the vendor’s biggest customers don’t have, then you aren’t the median, and the features you need don’t make the roadmap. Waiting for them to arrive is a bet you’ll probably lose.
The workaround tax. Every scheduled export, every shared doc that shadows the official tool, every spreadsheet somebody rebuilds from scratch each quarter. All of that is labor the tool failed to save. Once it adds up you’re paying full price for SaaS and paying salaries to make up for what it doesn’t do.
Pricing cliffs. Per seat pricing assumes seats are roughly uniform in value, and they aren’t. A part time ops person who checks the tool twice a week costs the same as a power user who lives in it. At 10× the headcount, the bill looks very different from the demo.
Data lock-in. “You can export everything” is usually true on paper. In practice the exports come in vendor specific schemas, and years of workflow context don’t survive the conversion. Switching is a project on its own, not the press of a button.
Cost over time, not at t=0. SaaS looks cheaper on day one. The honest comparison is at year three: SaaS’s sticker price plus the workaround tax plus per seat growth plus switching cost, set against custom’s upfront build plus ongoing maintenance. Sometimes SaaS is still cheaper. Sometimes custom crosses over before year two. Either way, the day one price rarely tells you which one it’ll be.
The framework: a 2×2
Two axes. Both are questions about the specific workflow you’re deciding about, not about the whole business.
Core vs. plumbing. Is this workflow part of what makes you different, or is it plumbing that every business has? Payroll is plumbing. Your pricing engine, if pricing is how you compete, is core.
Stable vs. shifting. Does the process change often? Accounting has been roughly the same for a century, so it’s stable. Your ops workflow when you’re growing 3× a year is not.
Drop the workflow into one of four quadrants:
- Plumbing + stable → Buy SaaS. Payroll, accounting, email, helpdesk. Don’t touch it. The market has solved this, and competing on it isn’t worth your time.
- Plumbing + shifting → SaaS + light glue. Ops workflows that keep evolving. Buy the tool and integrate around the edges. The glue is the 20% you own. The SaaS is the 80% you rent.
- Core + stable → Build. Your pricing engine, your scheduling logic, the operational rules competitors can’t copy because they’re specific to how you work.
- Core + shifting → Build and iterate. Your actual product, the core loop customers come back for. You don’t outsource this to a vendor’s roadmap.
Most businesses sit in all four at once. The point of the matrix isn’t to label your whole company, only to keep you from mixing up quadrants when you’re shopping for one specific thing.
Placing yourself on it: four questions
Walk through these in order. Each one narrows where you are.
1. Does a SaaS exist that fits your workflow today, without workarounds?
Be honest about what counts as a workaround. Scheduled CSV exports are one. Duplicate data entry is one. A shared doc that everyone uses instead of the “official” tool is one. If you’re training new hires on workflows around the tool, those workflows are doing real work, and nobody’s formally responsible for keeping them running.
- A clean yes puts you in a SaaS quadrant.
- “Yes, mostly, but for this one part” makes you a candidate for SaaS + glue.
- “No, and nothing on the market is close” probably means you’re in a build quadrant.
2. Will it still fit in 2-3 years?
Project forward. Run the math on per seat pricing at 3× your current headcount. Check the vendor’s public roadmap: if the feature you already know you’ll need isn’t on it, assume it’s not coming. If it’s been “on the roadmap” for two years, assume it’s not coming either.
3. Is the data lock in acceptable?
Can you export everything in a usable format? If you switched tomorrow, how many weeks of pain is that? For plumbing like payroll, lock in is fine. You’d export and move on. For customer relationships or operational history though, the data that is your business, lock in is a strategic risk dressed up as convenience.
4. Is this your edge, or plumbing?
Plumbing is what every business in your industry does roughly the same way, and customers don’t notice whether you do it well. The edge is the part a customer would notice if a competitor did it better. If it’s the edge, a generic vendor product will always cap how good it can get, because the vendor is optimising for a median customer who isn’t you.
Diagnostic signals you’re in the wrong quadrant
None of these are automatic disqualifiers. They’re signals to look closer.
- Every team member has their own spreadsheet. It’s not that they’re disorganized. The tool doesn’t hold the shape of the work, so each person invents their own container for it.
- Your onboarding doc has a “workarounds” section. If new hires have to learn the workflows around the tool, those workflows are load bearing and nobody owns them. That’s a liability.
- You export CSVs on a schedule. A weekly export into a second system is either an integration that somebody should have built, or a sign the first tool is the wrong one.
- Per seat pricing is growing faster than headcount. You’re adding seats for people who barely use the tool, because its unit of value doesn’t match your business’s.
- The feature you need has been “on the roadmap” for two years. Vendors ship what their median customer wants. If you’re not the median, waiting is a strategy that fails silently.
- You’ve hired someone whose job is partly to operate the tool. A dedicated admin is sometimes legitimate, and sometimes it’s a salary paying for a mismatch.
Example 1: when SaaS + glue was the fit
A B2C health brand came to me wanting to sell their products online. Their first instinct was Amazon FBA and the other big marketplaces.
It’s an attractive pitch: cheap to start, fast, and somebody else handles the fulfillment. For a lot of brands it’s the right call. For this one it wasn’t. Their product was niche and had to compete against higher ranked generic listings from much larger brands, with no real control over how any of it was positioned. Margin squeeze plus invisibility. Marketplace visibility would be capping their growth hard.
The founder’s second instinct was to build a custom ecommerce platform from scratch. Also wrong, because there’s nothing differentiated about how customers add things to a cart. Rebuilding cart, checkout, inventory and tax from scratch is pure cost with no return on it. Every retailer has the same plumbing, and none of that plumbing was their edge.
The right fit was a headless commerce platform, a category of SaaS that handles all the commerce infrastructure (cart, inventory, payments, taxes) while letting you build whatever storefront you want on top. SaaS handled the plumbing. A custom storefront handled the positioning, the niche UX, and the brand, which were the parts that actually were their edge.
Map it back to the matrix: the plumbing quadrant went SaaS, the differentiation quadrant went custom, and the integration between them was the 20% glue.
The mistake wasn’t choosing SaaS or custom. It was thinking they were mutually exclusive when the right answer was both.
Example 2: when custom end to end was the fit
Every therapist in the practice had their own spreadsheet. Not one looked like another.
This was a large medical practice with multiple locations. Their licensed physiotherapists were applying a specialized treatment (patches) and needed feedback against what every other therapist in the network was doing with similar patients. The spreadsheets were the workaround. Each therapist had built their own container for a workflow the market hadn’t served.
On paper this looked like “patient management software,” which is a solved category. Dozens of SaaS vendors compete on it. That framing was the trap.
The patient management part was actually a thin wrapper over something no vendor had built: peer reviewed, session level treatment tracking with feedback. The “easy” half (record a patient, schedule an appointment) existed everywhere. The “hard” half (track each patch application, route it into a shared review process, surface comparisons across the network) didn’t exist anywhere.
The temptation was to buy a generic patient management SaaS and glue a custom review module on top of it. That would have been worse than either pure option, because integrations are for filling gaps between existing tools, not for standing in for a core feature no vendor has built. Stitching the two together would have split the data across two systems, doubled the login surface, and made the hard part harder to reason about.
And the spreadsheets were the tell. When every practitioner has built their own private workaround, the market hasn’t served this workflow. A patient management tool wouldn’t have fixed that, it would just have swapped a bunch of flexible but fragmented spreadsheets for a single product that was rigid in different ways.
So we built one custom system covering both halves, because the “easy” half was really a view into the hard half.
When the easy half is really just a thin layer over the hard half, splitting them is worse than building the whole thing.
The takeaway
Most real businesses run a stack. SaaS for the plumbing, custom for the edge, glue in between. The question is which 20% deserves to be custom, and how cleanly the rest integrates around it.
If you’re stuck placing your workflow on this matrix, or you’re not sure whether a category that feels solved is actually solved for you, that’s exactly the conversation I have with clients on a first call.