When Your Vendor's Roadmap Stops Serving Your Business

For: A COO or founder at a 50–300-person Indian business that has outgrown a commercial SaaS or packaged tool — the vendor's pricing has just jumped, a critical workflow is being forced into a workaround, or a compliance requirement the vendor won't build is now blocking a client deal

If your vendor's renewal quote just landed 20% higher, a compliance deadline you can't meet is blocking a client contract, or a workflow your team lives inside has been quietly outsourced to three analysts with spreadsheets — the case for replacing that software is stronger than your last internal comparison made it look. That comparison almost certainly treated the licence fee as the cost of staying, and the build quote as the cost of leaving. Both numbers are wrong. This post is the argument you can take into the CFO meeting.

The number your build-vs-buy spreadsheet is missing

Every mid-market build-vs-buy analysis we've seen makes the same mistake. It compares the annual licence fee against the build quote plus ongoing engineering. It leaves out the part of your payroll that exists only because the software doesn't fit.

Walk through your operations floor. Count the people whose job title is some variant of reconciliation, data entry, coordinator, ops executive — vendor onboarding, GST filing assistant, or MIS analyst. For each one, ask a single question: if the software did what we needed it to do, would this role exist?

The honest answer, in most Indian mid-market businesses running an off-the-shelf ERP, CRM, or accounting platform built for a US or European workflow, is that a meaningful share of these roles are workaround headcount. They exist because the vendor's roadmap does not prioritise your GST reconciliation quirks, your channel partner commission structure, your dealer credit workflow, or your ₹10 crore e-invoicing obligations.

Load those salaries — CTC plus benefits plus the manager time supervising them plus the error rate they introduce — and put that number next to the licence fee. That is the real cost of staying. In a 150-person business with even three or four such roles, the loaded cost typically clears ₹40–60 lakh a year before you count the licence itself.

The cost of doing nothing, in language a CFO recognises

A CFO does not respond to "the software is frustrating." She responds to line items she can defend to a board. Break the cost of the status quo into five categories she already tracks.

1. The escalating licence itself

SaaS pricing is not what it was three years ago. SaaS subscription costs from several large vendors have risen 10–20% in the past year, while IT budget growth is projected at just 2.8%. Microsoft alone is raising M365 frontline-worker licences by 25–33% and business tiers by 12–17% effective July 2026, while removing Enterprise Agreement volume discounts worth up to 12%. Gartner earlier predicted that as the top 20 vendors phase out perpetual licences, certain software ownership and support costs will rise as much as 35% by year-end 2025.

Model the next three renewals at 15% compounding, not flat. Your CFO will recognise this shape from other vendor categories.

2. Over-provisioning and per-seat waste

Gartner research finds organisations without centralised SaaS licence management overspend by at least 25% — at an average $8,700 per employee, that is $2,175 wasted per seat per year. Pull your last twelve months of licence utilisation from the admin console. Count seats provisioned versus seats with weekly activity. The gap is a line item.

3. Workaround headcount (the big one)

This is the number your last analysis missed. A single example: a study on GST compliance burden found micro enterprises spend around 28.6 hours per month on GST-related activities. If your software doesn't automate what India's GST 2.0 reform and the April 2025 mandatory e-invoicing rule for businesses ≥ ₹10 crore turnover require, that time is bought back through headcount. Multiply hours per month by loaded hourly cost by number of staff involved. It is rarely a small number.

4. Blocked revenue

List the last five deals you lost or delayed because the software couldn't do something a prospect asked for — a data residency guarantee, a specific integration, a compliance report, an approval workflow that matches how Indian enterprises actually buy. Assign a probability-weighted revenue value. This is the number the sales head can defend.

5. Audit and breach exposure

If the vendor has deprecated a module you depend on, if you are on a version that no longer receives security patches, or if you are handling data the vendor's regional deployment doesn't cover under DPDP, quantify the fine, the audit remediation cost, and the reputational tail. A CFO will accept a probability × impact number here where she won't accept a hand-wave.

Add those five categories. That is the annual cost of doing nothing. Now compare it to a build.

Why the build number is smaller than you think, and larger than the quote

Zylo's TCO work is blunt: both build and buy costs are underestimated by a factor of two to three, with the 'buy' TCO hiding in implementation, renewals, and per-seat consumption charges that compound well beyond the initial licence price. This cuts both ways. The build quote you got is probably light on the second year. The vendor renewal you are staring at is probably light on years three through five.

What actually drives the build cost, in order of impact:

• Scope discipline. Are you rebuilding the whole product or the two workflows that create the pain? The latter is a fraction of the former and is almost always the right first move.
• Integrations. Each external system your build must talk to — Tally, Zoho, SAP, a payment gateway, a KYC provider, a courier API — adds real weeks. Count them honestly at the start.
• Data migration. How much history must move, in what shape, and how clean is it today? Dirty legacy data is the single most common reason build timelines slip.
• Compliance surface. DPDP, GST e-invoicing, sector-specific rules (RBI for lending, CDSCO for pharma). These are not optional and they are not fast.
• Change management. The team using the new system needs to be trained, and the old system needs to be run in parallel long enough to catch what you missed.

The build cost is a range because these five variables are yours to set. A CFO will accept a range if you name the drivers.

Sequencing: strangler-fig vs big-bang

You have two realistic paths. Pick the wrong one and the project fails regardless of engineering quality.

The strangler-fig approach

Identify the single workflow costing the most in workaround headcount or blocked revenue. Build a replacement for just that workflow. Run it alongside the vendor system. Once it is stable, migrate the next workflow. Repeat until the vendor system is doing so little you can cancel the licence at the next renewal.

Good at: preserving cash flow, learning what you actually need before committing to it, giving the CFO a first increment that pays for the next, keeping the option to stop if the first phase underdelivers.

Bad at: speed. You will run two systems in parallel for twelve to twenty-four months, which means integration glue between them, some duplicate data entry during transitions, and a team that has to context-switch. If your vendor renewal is in ninety days and you need out, this path won't rescue you in time.

The big-bang rebuild

Rebuild the whole system, cut over on a weekend, deprecate the vendor at the next renewal.

Good at: ending the vendor relationship cleanly, avoiding the tax of running two systems, forcing the organisation to commit.

Bad at: almost everything else. It concentrates risk into a single cutover date, requires you to specify the whole system upfront when you don't yet know what you need, and if the first version is wrong the fallback is often the vendor you were trying to leave — at renewal terms they now know you're desperate for.

For most 50–300-person Indian businesses, the strangler-fig is the correct answer. The big-bang makes sense only when the current system is genuinely about to fail (unsupported ERP, vendor exiting the market, security posture that will not pass the next audit) or when the workflows are so entangled that a partial replacement is architecturally impossible.

Phasing the spend so phase one pays for phase two

The CFO's real objection is rarely the total number. It is the cash outflow shape. Structure the programme so each phase produces measurable savings before the next phase is committed.

1. Phase 0 — Diagnostic (weeks, not months). Audit workaround headcount, licence utilisation, blocked-revenue deals, compliance gaps. Produce the CFO document above. Cost is small; output is the mandate for phase 1.
2. Phase 1 — Highest-pain workflow. Pick the single workflow with the largest loaded-cost saving. Build it. Retire the corresponding workaround headcount or reassign them. The saving funds phase 2.
3. Phase 2 — Next workflow, plus integration spine. By now the shape of the platform is visible. Build the second workflow and the shared services (auth, audit log, reporting, data model) both will use.
4. Phase 3 — Migration of remaining users, vendor exit. Time this to the vendor renewal date. Do not renew.

Each phase is separately approvable. Each has its own success metric. If phase 1 doesn't deliver the projected saving, phase 2 doesn't get approved. This is how a sceptical CFO learns to say yes.

What the business has to supply

A build only works if the business shows up. Before you commission anything, commit to the following internally:

• A single accountable owner on the business side who can make scope decisions without a committee. Without this the build slips and blame diffuses.
• Access to the two or three people who actually do the work today. Not their managers. The engineering team needs to sit with the person doing the reconciliation to see what the vendor tool actually forces them to do.
• Cleaned-up data, or a budget line for cleaning it up. Migration cost scales with data quality, not data volume.
• A parallel-run period the operations team agrees to. Cutover risk is what kills these projects. Bake in a month minimum.
• A decision on IP and hosting. If you're leaving vendor lock-in, don't walk into a new one. Own the code, own the data, host where you choose.

The India-specific angle your global vendor will not solve

India's enterprise software market is growing fast — valued at $20.17 billion in 2024 and projected to reach $57.66 billion by 2035 at a 10% CAGR — and a large share of that growth is domestic buyers realising the global SaaS roadmap will never prioritise their local workflows. GST 2.0, e-invoicing thresholds that keep moving, DPDP, state-level compliance quirks, dealer network economics, cash-on-delivery logistics, UPI reconciliation — none of these are on the roadmap of a vendor whose largest market is North America. This is not a criticism of the vendor. It is a rational allocation of their engineering. It just doesn't help you.

The custom-build path exists precisely because the buy path leaves this gap. The question is not whether the gap is real — it is whether the loaded cost of leaving it unfilled exceeds the cost of filling it.

An illustrative worked example

Illustrative only. Every number below is a placeholder assumption stated in the same breath.

Take a 180-person distribution business on a global ERP. Assume: annual licence ₹35 lakh, escalating 15% per year. Four ops executives (loaded CTC ₹6 lakh each) exist to reconcile GST mismatches and process channel partner commissions the ERP cannot model — ₹24 lakh a year. Two enterprise deals worth ₹1.2 crore combined lost last year because the ERP could not produce a data residency attestation the customer's audit required — probability-weighted at 40% = ₹48 lakh in blocked revenue. Licence over-provisioning at 20 unused seats × ~₹40k each = ₹8 lakh.

Annual cost of staying, year one: roughly ₹1.15 crore. Compounding on the licence and the blocked-revenue tail, three-year cost is meaningfully higher.

A strangler-fig build addressing the two workflows (GST reconciliation, channel commissions) plus a data residency-compliant deployment would be scoped as a phased engagement. The point of the example is not the specific rupee figure — it is that the workaround headcount and blocked revenue alone, in this shape of business, already exceed the licence fee. Your numbers will differ. Run the calculation with your own.

What would turn this illustrative range into a real quote for your business: the count and complexity of workflows in scope, the number of external integrations, and the state of your existing data. Those three variables move the number more than anything else. A scoping conversation with CodeNicely is the fastest way to get from a range to a plan.

How CodeNicely can help

We've done this exact replacement work in fintech, where the vendor gap is sharpest. GimBooks is a YC-backed accounting and compliance platform built specifically for Indian MSMEs — the kind of GST, e-invoicing, and small-business workflow depth that no global SaaS treats as a priority. The engagement is directly relevant to any mid-market business whose current vendor treats Indian compliance as a plug-in rather than a first-class workflow.

For businesses in regulated sectors weighing the same decision, Cashpo shows what building lending-grade KYC, credit scoring, and audit trails from scratch looks like when the off-the-shelf option cannot meet RBI's expectations. And Vahak is a logistics marketplace where the operational workflows — dealer onboarding, route economics, cash reconciliation — simply do not exist in any imported platform.

The pattern across these engagements: strangler-fig sequencing, full IP ownership by the client, no vendor lock-in on our side either, and phase-one scope tight enough that the saving from phase one funds phase two. That is the shape we bring to Indian mid-market modernization work.

The argument, in one paragraph

The licence fee is not the cost of staying. The real cost is the licence plus the loaded salaries of the workaround headcount plus the revenue blocked by features the vendor won't build plus the audit exposure of features they've deprecated. Compare that number — not the licence alone — to a phased custom build sequenced so the first increment pays for the next. In most Indian mid-market businesses, the arithmetic favours the build sooner than the last internal analysis suggested, because the last analysis didn't count the people the vendor is quietly forcing you to hire.

Frequently Asked Questions

How do we know if our vendor's roadmap has actually stopped serving us, versus just being frustrating?

Three signals together are decisive: a compliance requirement your customers or regulators demand that the vendor has publicly deprioritised, workaround headcount you can name by role, and at least one deal lost in the last twelve months tied directly to a missing capability. Any one of these is a complaint. All three is a business case.

How long does replacing an entrenched vendor system actually take?

The timeline model has three drivers: how many workflows are in scope, how many external integrations must survive the transition, and how clean the migration data is. A strangler-fig approach starts producing value in months per workflow, with full vendor exit typically timed to a future renewal date twelve to twenty-four months out. A big-bang rebuild compresses that but concentrates risk. Turning this range into a real timeline requires scoping the workflows and auditing the data — that is a conversation, not a spreadsheet exercise.

What's the cheapest way to get started without committing to a full build?

A short diagnostic phase — audit licence utilisation, quantify workaround headcount, list blocked-revenue deals, map compliance gaps. It produces the CFO document that either justifies phase one or tells you honestly that staying is cheaper. It is the smallest useful spend in this whole process.

What happens to our data and IP if we build custom instead of buying?

Structured correctly, you own the source code, the data model, the deployment, and the right to change vendors or bring the work in-house at any point. This should be explicit in the engagement contract. Have your lawyer review the IP assignment, escrow, and exit clauses — this post is not legal advice, and the specifics matter.

Isn't there always a risk the custom build ends up being its own legacy system in five years?

Yes, and it's a real risk worth naming. The mitigations are architectural (modular services rather than a monolith, documented APIs, standard frameworks rather than exotic ones), operational (a maintenance budget line from day one, not an afterthought), and contractual (IP ownership so you can change who maintains it). A build that ignores these becomes legacy faster than the vendor product it replaced. A build that respects them stays modifiable for a decade or more.