There is a version of the build-versus-buy question that gets asked a lot and answered badly. The asking is fine — "should we use a SaaS product or build our own?" — but the answer almost always comes from someone with an interest in the outcome. A SaaS vendor will tell you SaaS is enough. A development agency will tell you to build. Both are mostly right in the part of the stack they sell to, and both quietly miss the part that actually matters.
This is a field guide for thinking about it without that bias. Where SaaS is the right call, where it quietly stops working, what the hybrid pattern looks like in 2026, and the four signals that tell you it is time to think seriously about a custom layer.
What SaaS is actually good at
It is worth being honest about why SaaS won the last fifteen years. For a defined, well-understood workflow that thousands of other companies do roughly the same way, a packaged product is a better answer than custom software on every axis that matters — time, cost, reliability, security, and the simple fact that the vendor is shipping improvements without you having to think about it.
The categories where SaaS almost always wins on total cost, in our experience and confirmed by most independent build-vs-buy analyses, are:
- Email, calendar, video conferencing. Google Workspace, Microsoft 365, Zoom.
- Accounting and payroll. Tally for India SMBs, Zoho Books for slightly larger, QuickBooks for the rest. Razorpay or Stripe for payments.
- HR information systems. Keka, Darwinbox, Zoho People for India; BambooHR or Rippling for larger.
- Ticketing and support. Freshdesk, Zendesk, Intercom.
- Basic CRM. Pipedrive, HubSpot, Zoho CRM, Freshsales.
- Project management. Linear, Asana, ClickUp, Notion.
If your business runs any of these and the workflow is roughly the same as every other business, a custom build is almost certainly the wrong call. You are not going to out-engineer Atlassian on issue tracking, and the leverage is somewhere else in your business anyway.
The interesting question is what happens at the edges — where the workflow is yours, the data shape is yours, and the SaaS product is gently nudging you toward the version of the problem it knows how to solve.
The four signals that SaaS is starting to bend
Across a few dozen engagements, the same pattern shows up before someone decides to build something custom. It is usually not one dramatic break — it is four smaller signals showing up together.
Signal one: the parallel spreadsheet. The SaaS tool exists, the team uses it, and there is still a Google Sheet (or three) running alongside it that captures the "real" version of the data. The CRM has stages, but the actual pipeline lives in a sheet. The POS has inventory, but the actual indent runs from a sheet. When the spreadsheet is the source of truth and the SaaS is the source of reports, the SaaS has stopped doing its job.
Signal two: the middleware tax. You pay for Zapier or Make or a connector vendor to push data between three or four SaaS products that should talk to each other natively. Each connector is a small monthly fee, a small failure point, and a small piece of institutional knowledge that lives in one person's head. Once the middleware bill is comparable to a single SaaS seat, the integration cost is paying for the wrong thing.
Signal three: the workaround documentation. The onboarding doc for a new hire has a section called "how we actually use [Tool X]". The official tool workflow has been bent, three custom fields have been repurposed, and there is a Slack message pinned somewhere explaining the convention. The product is being held together by tribal knowledge. This is usually the latest signal — by the time it is written down, the gap has been there for a while.
Signal four: the bill that grows faster than headcount. Per-seat SaaS is a fair model when usage scales with people. It quietly stops being fair when the work scales with transactions, locations, or workflows — because then your bill grows on a different axis from your value. We see SaaS stacks at INR 8–15 lakh per year in 30-person Indian firms where two of the line items, by themselves, would pay for a custom replacement in three years.
Any one of these signals on its own is normal. All four together is the moment to think about hybrid.
The hybrid pattern
The mental model that has held up across law firms, CA firms, HVAC operators, clinics, real estate developers, and F&B groups — and it has held up across every one of them — is this:
Buy the packaged products for the commoditised 80%. Build a thin custom layer for the 20% that decides whether you make your number.
The 80% is everything that does not differentiate you. Accounting, payroll, calendar, video, the bulk of your CRM or POS or DMS, file storage, identity, payments. You will not win by reimplementing what Zoho or Tally or Freshdesk does. Buy seats, train the team, move on.
The 20% is everything that does. The matter cockpit a managing partner actually wants to look at. The central kitchen indent flow that decides whether the café group makes its food cost. The commission ledger that decides whether the broker firm pays sub-brokers correctly. The patient-experience layer that decides whether the clinic has a Tuesday morning queue or a Tuesday morning waiting room.
This 20% is the part that no SaaS product will get right, because each operator's version of it is slightly different. Build that. Wire it to the packaged products underneath. Treat the SaaS layer as a primitive — a database with a UI you didn't have to write.
There is a useful piece of independent corroboration here. Netguru's SaaS vs custom software guide arrives at the same conclusion from a European market lens — that the right answer in 2026 is rarely binary, and that "buy the commodity, build the differentiator" is the pattern winning teams use to keep total cost down while still getting the operational specificity they need.
When custom is the right call end-to-end
A small set of cases genuinely call for replacing a SaaS product rather than wrapping it. We see these less often than people expect, but they are real.
- The workflow is the product. If the software is what you sell — your own SaaS, your own marketplace, your own internal platform that customers pay for — then custom is the only answer. You are not buying off-the-shelf, you are building the thing.
- Regulatory or data-sovereignty constraints make SaaS unworkable. Some healthcare, financial services, and government workloads in India cannot legally use a SaaS product that stores data outside India or shares a multi-tenant database. In those cases the SaaS option is closed.
- The SaaS product's economics break at your scale. Per-seat models occasionally collapse at very large or very small ends — a 200-agent broker firm or a 3,000-location field operation will both find that the SaaS bill outruns the value, and a custom build with infrastructure costs that scale on a different axis becomes the cheaper answer.
- There is no packaged product for your shape of problem. Some Indian-specific workflows — multi-entity GST reconciliation across group companies, certain TDS edge cases, RERA disclosure flows for brokers, OPD-plus-pharmacy revenue cycle — genuinely have no good packaged answer at the SME tier. You either bend a global product or you build.
If your situation is none of these, the answer is probably hybrid.
A worked example: a 40-person Indian operations business
A Bengaluru company running B2B field services across three cities, 40 people, INR 12 crore annual revenue. Current stack: Zoho One (CRM, Books, Inventory, People), a packaged dispatch tool at INR 1,800 per technician per month, Razorpay for payments, WhatsApp Business for customer chat, and four Google Sheets that the operations head maintains. Total SaaS bill: about INR 14 lakh per year. The operations head spends two days a week in spreadsheets.
The honest analysis here is not "replace Zoho with custom software". Zoho is doing fine. The dispatch tool is doing fine. The breakage is in the four sheets — they hold the AMC renewal pipeline, the parts inventory across vans, the technician utilisation report the owner looks at on Sunday night, and the per-customer profitability view.
A thin custom layer that absorbs those four workflows — pulls from Zoho via API, pulls from the dispatch tool via webhook, writes back where it needs to, surfaces the four views as a single internal cockpit — is roughly INR 10–14 lakh over 8–10 weeks fixed price, plus an INR 45k per month retainer. The Zoho bill stays. The dispatch tool bill stays. The sheets go away. The owner gets a single weekly view of utilisation, AMC renewals, and per-customer margin that updates without anyone touching it.
Year-one delta on cash out: roughly INR 18 lakh on top of the existing INR 14 lakh SaaS stack. Year-one delta on operations head's time: two days a week. Year-two delta: zero new spend on the custom side besides the retainer, while the SaaS bill continues at its existing rate. That is the shape of the hybrid trade.
The decision frame
If you are sitting at this fork and want a single decision frame, this is the one we use with new buyers:
- Which parts of your stack are commodity? List them. SaaS wins. Don't build.
- Which parts decide whether you make your number? List them. If a packaged product gets them 90% right, buy and configure. If it gets them 60% right and you have to maintain spreadsheets to close the gap, custom layer.
- Is anything regulated, sovereign, or unbuildable as SaaS? If yes, custom is forced for that piece.
- What does the SaaS bill look like in three years at expected growth? Multiply current per-seat times projected headcount times 1.1 for annual price increases. If the answer is more than a custom build amortised over three years, the math is starting to tilt.
Most operators we work with come out of this frame with a small, focused custom layer on top of three or four packaged products. Not a rip-and-replace. Not a "we are going to build our own ERP". A thin layer in the exact place where the leverage in their business actually sits.
If you are at that decision point and want a second opinion that isn't selling you SaaS or a full rebuild, book a discovery call. Thirty minutes is usually enough to see where the leverage in your stack is, what is fine as it is, and what a sensible first phase of a custom layer would look like.