Every growing business runs on SaaS at some point. Sign up, pay per seat, ship this week. The tradeoff shows up around year three, when your workflow no longer matches the roadmap of a vendor serving 40,000 other companies.
Here is the checklist we run with clients before anyone writes code.
Five signals SaaS stopped fitting
You pay per seat for read-only users. Half your licenses belong to people who open one dashboard a week.
A spreadsheet holds your stack together. Three tools, one export, one manual reconciliation every Friday. The spreadsheet became your real system of record.
The integration you need sits behind an enterprise tier. The jump from $200 to $2,000 a month buys one webhook.
Your data exports as CSV and nothing else. No API, no schema, no history.
You changed your process to match the software, instead of the other way around.
One signal is noise. Three or more is a build case.
Five signals SaaS still wins
The process is standard. Payroll, accounting, email, calendars. Do not build these.
Compliance sits with the vendor. PCI, HIPAA, SOC 2. Buying the burden costs less than owning it.
You run under 10 users on a common workflow.
You need it live next week.
Nobody on staff owns software decisions long term.
The math most teams get wrong
SaaS looks cheap monthly and expensive over five years. Custom looks expensive upfront and cheap to hold. Run both numbers before the argument starts.
Take 25 seats at $40 per seat per month. SaaS costs nothing on day one and $12,000 a year after, closer to $66,000 across five years once annual increases land. A custom build at $30,000 plus $5,000 a year in hosting and maintenance totals around $55,000 over the same five years.
Break-even lands near year three at this size. At 8 seats it never arrives, and SaaS wins. At 100 seats it arrives in year one. Plug in your own seat count before believing anyone, including us.
Budget 15 to 20 percent of build cost per year for maintenance. Teams who skip this line item end up with software nobody patches.
The hybrid most teams should pick
The answer is rarely all or nothing. Keep SaaS for commodity functions. Build the one workflow no vendor models correctly. Connect the two with webhooks and a thin service layer of your own.
In practice the custom layer receives the vendor webhook, normalizes the payload into your schema, writes it to your database, and runs your business rules. Everything else stays with the vendor.
Your custom layer stays small. Your commodity tools stay replaceable. Swapping a payment processor becomes a two-week job instead of a rewrite.
Line these up before development starts
Write one page describing the workflow. Steps, roles, exceptions. If it does not fit on one page, the scope is not ready.
Name one owner with authority to decide.
Settle the data model first. Entities, relationships, and the history you keep. Schema mistakes cost more than UI mistakes.
Pick boring technology. Laravel, Django, or Rails on the back end. React or Vue on the front. Postgres underneath. Hiring for these in year four stays easy.
Write the exit plan into the contract before kickoff. Your repo, your cloud account, your domain, your database.
The honest version
Most teams who ask us for a custom platform need two custom screens and better integration between tools they already pay for. We say so, and the project gets smaller. The ones with a real build case share one trait: their competitive edge lives inside the workflow itself, and no vendor sells it.
We do this work at eDeskCloud: custom web development, cloud infrastructure, and managed IT for growing businesses.
What tipped your team one way or the other? Comments are open.
Top comments (0)