Off the shelf SaaS tools earn their place. They get a small business off paper in a weekend, they cost almost nothing on day one, and they remove the burden of maintenance. The problem starts later, when your team begins inventing workarounds, exporting CSVs between three subscriptions, and bending workflows around a tool that was designed for someone else's company. At that point, the cheap subscription is no longer cheap, and the custom build that felt like an overspend two years ago becomes the obvious answer. This article explains how to recognise the tipping point, how to do the maths honestly, and how to phase the move without a risky big bang rebuild.
Why Off-the-Shelf SaaS Is Almost Always the Right First Answer
It is worth saying clearly: starting with SaaS is rarely the wrong call. For a young team, the trade is excellent.
- Low upfront cost. You pay per seat per month rather than commissioning a build, so the first version of your stack costs less than a single developer week.
- Speed to value. Most modern SaaS tools are usable inside an hour and integrated inside a day.
- No maintenance burden. Updates, security patches, hosting, and uptime are the vendor's problem.
- Best practice baked in. Standard workflows like CRM pipelines, expense approvals, and helpdesk ticketing are already encoded by the vendor.
The trade only goes bad when the company outgrows the tool. The tool itself does not change. Your business does. That is when the questions in the next section start to matter.
Five Signs You Have Quietly Outgrown Your Tools
None of these on their own justifies a custom build. Two or three together usually do. If four or five apply, the question is no longer whether to build, it is when.
- Sign one. Subscription costs are climbing faster than headcount. Your CRM, project tool, helpdesk, and integrations together cost more than a mid level developer's annual salary. Most of that spend is locked in regardless of how much value you actually extract.
- Sign two. Your team's onboarding doc has a "workarounds" section. New joiners are taught how to fake a status, append codes to record names, or skip a built in step because it does not match how the company actually operates. The workarounds are the symptom. The mismatch underneath is the cause.
- Sign three. CSV exports move data between tools regularly. Someone exports leads from one system every Friday, cleans them in Excel, and uploads them to another. That manual loop is a feature missing from your stack, paid for in time rather than money.
- Sign four. Reports are not trustworthy without manual pivot work. The dashboards in the SaaS tool are close to right but always need a spreadsheet pass before they go to leadership. The numbers people make business decisions on live in someone's laptop, not in the system.
- Sign five. The vendor's roadmap will not solve it. You have asked for the missing capability, scanned the public roadmap, and read the response in a support thread. The honest answer is that the gap will still be there in two years.
The Workflow Bending Trap
This is the most expensive trap in the off the shelf world, and the hardest to spot from inside it.
A SaaS tool encodes a particular way of working. When your team adopts it, they slowly reshape how the company operates to fit the tool. Approvals get squeezed into the tool's two stage flow even though the real process has four. Customer types get flattened into the tool's three categories even though there are seven that actually matter. Reports get written against the data the tool happens to capture, and the data the tool does not capture quietly stops being measured.
Over time, the tool stops serving the business and the business starts serving the tool. The clearest sign is when the answer to "why do we do it that way" becomes "because the system needs it" rather than "because the customer or the regulator needs it." That sentence costs more, year over year, than any subscription line on the invoice.
"The day your operations manual is written to fit the software, instead of the software being chosen to fit the operations, is the day a custom build starts paying for itself."
The Honest Cost Math: SaaS Stack vs. Custom Build
Most teams overestimate the cost of a custom build and underestimate the lifetime cost of their SaaS stack. Here is the comparison for a typical 30 person Sri Lankan business running a moderate stack.
| Cost line | SaaS stack | Custom build |
|---|---|---|
| Year 1 outlay | LKR 1.2 to 2.4 million | LKR 3 to 6 million one off |
| Year 2 to 5 annual cost | LKR 1.5 to 3 million each year | LKR 300k to 600k support and hosting |
| Five year total | LKR 7 to 14 million | LKR 4 to 8 million |
| Per seat tax as you grow | Linear with headcount | Zero · cost is independent of seats |
| Workflow fit | Approximate | Exact |
| Data ownership | Vendor controlled | Yours · in your database |
| Lock in | High · migration is painful | None · you own the source |
The SaaS row is realistic for a stack of CRM, project management, helpdesk, document management, and a couple of integrations. The custom row is a realistic Dev Studio engagement for a focused internal platform that replaces the parts where the SaaS tools were dragging the team. The crossover point is typically between month 18 and month 30, which is also where most companies start feeling the bend in their workflows.
What Does a Custom Build Actually Deliver?
The honest answer is not "more features." A custom build is rarely about doing more. It is about doing the right things in the right shape, with the friction removed.
- Exact workflow fit. The system models how your business actually works, with the categories, statuses, approvals, and roles that exist in reality.
- Single source of truth. Customer, order, project, and financial data live in one schema instead of four loosely synced ones, so reports stop needing manual reconciliation.
- No per seat tax. The build cost is fixed. Adding the next ten or hundred users does not change the licence bill.
- Owned IP. The codebase, the database, and the design assets are yours. You can change vendor, migrate hosts, or take it in house at any time.
- Integration freedom. Custom builds can talk to anything with an API. Need to push data into your accounting tool, pull from your ERP, or sync with WhatsApp Business? It is a development task, not a vendor negotiation.
- Compliance and locality. Data residency, local language support, local payment gateways, and Sri Lanka specific regulatory requirements are built in rather than worked around.
When You Should Stay on Off-the-Shelf
The point of this article is not that custom is always right. It almost never is for commodity functions.
- Accounting, payroll, and tax filings. The compliance surface changes faster than any internal team can keep up with. A reputable accounting platform is the right answer.
- Email, calendar, and document collaboration. Google Workspace and Microsoft 365 are the right answer for almost everyone.
- Generic helpdesk for a small support team. If the workflow is "ticket comes in, agent replies, ticket closes," there is no edge to building it.
- Standard CRM for a small sales team. Until you outgrow the standard pipeline shape, a SaaS CRM is faster, cheaper, and good enough.
The rule of thumb is simple. If the function is generic across industries and the workflow inside your business looks like the workflow inside a thousand others, off the shelf wins. If the function is core to how your specific business creates value, and the workflow has shape that no off the shelf tool quite fits, custom usually wins.
The Hybrid Approach Most Mature Teams Choose
The mature answer for most growing Sri Lankan companies is not "all SaaS" or "all custom." It is custom for the parts that are core to the business, integrated with proven SaaS for the parts that are commodity. A custom internal platform handling approvals, custom workflows, and your specific operational data, talking through APIs to a standard accounting tool, a standard email platform, and a standard collaboration suite. The result is a system that fits your business exactly without the overhead of rebuilding email and tax compliance from scratch.
Worth noting
The biggest risk of a custom build is not technical. It is scope. Most failed custom projects in our experience tried to replace too much at once. The teams that succeed start with a focused phase one that replaces the single most painful workflow, ship it in eight to twelve weeks, and add adjacent workflows after the team is using and trusting the new system.
How a Sensible Custom Project Actually Phases
A well run Dev Studio engagement does not arrive as a single twelve month rebuild. It arrives as a sequence of small, defensible deliveries that compound.
- Discovery and brief. One to two weeks. We map the current stack, pain points, and workflows, then identify the single sharpest place to start.
- Phase one build. Eight to twelve weeks. The most painful workflow is rebuilt cleanly, integrated with whatever SaaS stays, and shipped to a small group inside the business.
- Adoption and observation. Two to four weeks. The team uses the new system on real work. Feedback shapes the next phase.
- Phase two and beyond. Subsequent workflows roll in one at a time, each shipped in a defined sprint, each justified by the value it removes from the legacy stack.
- Steady state. Once the custom platform covers the core of the business, the SaaS stack shrinks back to commodity tools, and the ongoing cost drops sharply.
The Verdict
- SaaS first. Almost always the right starting point. Cheap, fast, low maintenance.
- Tipping point. When subscription costs, workarounds, manual exports, and untrustworthy reports start stacking, the tool is no longer fit for purpose.
- Cost over five years. Custom is typically cheaper between months 18 and 30, and substantially cheaper by year five.
- Real win. Workflow fit and data ownership, not feature count. The system finally matches how the business actually operates.
- Right scope. Custom for the core, off the shelf for the commodity. Hybrid almost always beats either extreme.
- Right delivery shape. Phased sprints with real users on real work. Big bang rebuilds are the failure mode.
If your team is bending its workflows around the software instead of the other way around, your subscription stack has already become more expensive than it looks. The Dev Studio approach is to find the single sharpest place a custom build pays back fastest, ship it in weeks rather than quarters, and let the business decide where to go next based on what the first phase actually delivers.
