For 20 years, the buy-vs-build decision in business software was a one-axis question: does an off-the-shelf SaaS exist for this, and is it cheaper than hiring engineers? The honest answer was almost always "yes, buy it" — building software from scratch was so expensive that off-the-shelf won almost everything that wasn't core differentiation.
2026 changed this. AI builders make "build it" cheap enough that the decision is no longer one-axis. The right question is now: do we buy a generic SaaS, generate a custom app that fits exactly, or hand-build with engineers? And the right answer depends on eight criteria, not one.
Why this question is not the old buy-vs-build
The old buy-vs-build assumed engineering was scarce and expensive. The new question assumes your specific business shape is scarce — generic SaaS rarely fits exactly, and the cost of forcing your business to fit the SaaS is now usually higher than the cost of generating a fitted alternative.
Concretely: a "CRM for small accounting firms" that costs €30/user/month is generic. It assumes you do CRM the way the SaaS thinks accountants do. If your firm has any quirk — a particular client-onboarding flow, a non-standard report format, a regional regulation that requires a specific document trail — you're either ignoring it (and the tool starts feeling broken in week three), customising the SaaS (which costs more in admin time than building a custom version), or supplementing with a Google Sheet (which means the SaaS is half-doing the job).
An AI builder closes the gap. You generate the CRM that fits exactly, the way your firm actually works, in two days, for €29/month. The decision becomes: is the off-the-shelf version close enough to your shape that the customisation cost is worth it, or is custom-fit cheap enough now that close-enough isn't?
The eight criteria
Score each as 1–5 (1 = strongly leans buy SaaS, 5 = strongly leans generate). Total score 24–32 means generate; 8–16 means buy; 16–24 means careful — pilot both for a quarter.
1. Workflow uniqueness
Does your business do this thing in a way that's noticeably different from how a typical generic-SaaS company assumes? If yes, score high. If your workflow is "what every SaaS company does" with a slight cosmetic difference, score low.
Honest test: ask three competitors how they do this exact workflow. If the answer is the same across them, your workflow is generic. Buy. If the answers diverge significantly, your workflow is unique. Generate.
2. Data sensitivity and sovereignty
Does the data this tool will hold include personal customer data, financial information, regulated content, or anything that would trigger an audit if it leaked or moved regions?
SaaS providers vary wildly in their answer to that question. Some are SOC 2 + GDPR-grade out of the box; some are not. If your data is sensitive and you can't trust the SaaS, generate. (This is increasingly common in 2026 — EU data sovereignty rules push generation as the default.)
3. Volume of records
How many records will the tool hold in two years? If the answer is over 100,000, performance and cost both matter. Generic SaaS tends to have step-function pricing at certain volumes; generated apps don't.
Score high (generate) if the answer is "more than 100K and growing fast". Score low if it's "under 1,000".
4. Number of users
How many people in your team will use the tool? Generic SaaS billing is typically per-seat — €15–€50/user/month. At 5 users that's tolerable; at 50 users that's €15K–€30K/year, and the seat-tax math starts to favour a generated app billed per-project.
Score high (generate) at >20 users. Score low at <5 users. The cross-over is around 10–15 users.
5. Integration depth
Does this tool need to talk to other systems you own — your billing, your data warehouse, your auth, your event pipeline? If yes, generic SaaS often integrates poorly or via expensive third-party connectors.
An AI-generated app talks to your other systems the way you describe them, not the way the SaaS thought you would. Score high if integrations are critical. Score low if it's a stand-alone tool with no upstream/downstream dependencies.
6. UI tolerance
How much do the people using this tool every day care about the UI fitting their workflow exactly? For ops and back-office tools, the answer is "a lot" — 8 hours a day in a tool that's 80%-fit is exhausting. For occasional tools — quarterly compliance reports — the answer is "barely matters".
Score high if it's a daily-use tool that needs to feel native. Score low if it's a once-a-month thing where any reasonable UI works.
7. Customisation cost in the SaaS
If you decide to buy the SaaS, what's the realistic admin cost of customising it to fit your business? Most SaaS sells "customisation" as a feature; in practice it means "spend two weeks of your ops manager's time configuring fields and writing automations". That cost is real and recurring.
Score high (generate) if customisation cost is high. Score low if the SaaS just works as-is for your case.
8. Lifecycle of the workflow
Will this workflow exist in five years? If yes, the right tool needs longevity, vendor stability, and ideally an exit path that doesn't lock you in.
Generic SaaS sometimes wins here — established vendors with 10+ year histories and mature export tools beat any 2-year-old startup, including AI-builder-generated apps.
An AI-generated app's exit path is the static + Git export — you walk out with code you can host anywhere. Score the AI app high here only if you've verified the export actually works for your specific use case.
Worked example: CRM for a 30-person accounting firm
Workflow uniqueness: 4 (firm has specific client-onboarding ritual). Data sensitivity: 5 (financial data, EU residency required). Volume: 2 (under 5,000 clients). Users: 3 (12 people use it). Integration depth: 4 (must connect to accounting software). UI tolerance: 5 (daily use, 8 hours/day). Customisation cost: 4 (HubSpot custom fields take two days/quarter to maintain). Lifecycle: 2 (workflow stable for 5+ years, but the firm's specific shape may evolve).
Total: 29. Generate. Build a Marcus app, host it in EU, point your accounting software's API at it, run the firm on it for €29/month instead of €5,400/year on HubSpot at €15/user × 12 users × 12 months × 2.5x with custom fields and automations.
Worked example: project-tracking tool for a 5-person agency
Workflow uniqueness: 2 (agencies are similar). Data sensitivity: 2 (no regulated data). Volume: 1 (a few hundred projects). Users: 1 (5 users). Integration depth: 2 (light Google Calendar integration). UI tolerance: 3 (daily, but tolerant). Customisation: 2 (Linear works for everyone). Lifecycle: 4 (5+ years, won't change).
Total: 17. Buy Linear. Don't generate. The cost of maintaining a custom version exceeds the seat-tax for a 5-person team that's tolerant of UI conventions.
Worked example: a sales-demo environment for a 50-person B2B SaaS
Workflow uniqueness: 5 (every prospect demo is bespoke). Data sensitivity: 3 (fake data, but branded). Volume: 2 (one environment per active deal). Users: 5 (every AE uses it). Integration: 1 (none). UI tolerance: 5 (must look like the prospect's company). Customisation: 5 (off-the-shelf demo tools force generic UI). Lifecycle: 4 (ongoing).
Total: 30. Generate. This is the highest-leverage AI-builder use case — every active deal gets a Marcus environment branded to the prospect, in the time it takes the AE to write the discovery summary.
The trap most teams fall into
The classic mistake is to anchor on the SaaS price tag (€20/user/month sounds cheap!) and ignore the indirect costs:
- The admin overhead of configuring and maintaining the SaaS.
- The opportunity cost of every workflow that's 70%-fit instead of 100%-fit.
- The seat-tax compounding as the team grows.
- The integration costs when the SaaS doesn't talk to your other systems cleanly.
- The vendor risk if the SaaS company gets acquired and shifts focus.
When you sum those, the seemingly-cheap €20/user/month often costs more in 12 months than a generated app that fits exactly. The math has flipped, and most ops leaders haven't updated their default heuristic from the 2018 version.
The reverse trap
The opposite mistake — generating everything — is wrong too. Generating is right when the workflow is yours, the data is sensitive, or the seat-tax math doesn't work. Generating is wrong when the workflow is genuinely generic, you need 10+ year vendor stability, or the SaaS has network effects (e.g. CRMs with marketplace integrations, ATS systems, dev tools with ecosystem plugins) that you'd lose by going custom.
The honest decision is per-workflow, scored against the eight criteria above, with the math run for your team's actual size and growth trajectory. Most companies will end up with a stack that's 60% generic SaaS for genuinely-commodity workflows and 40% generated apps for everything that's distinctively theirs. That ratio is roughly the inverse of what most companies have today.