The Floodplain Trap

Why “Just Build It Yourself” May Be the Most Expensive Sentence in Business

There is a version of this argument that visits almost every ambitious founder sooner or later. It usually arrives late at night, just after another software invoice has landed in the inbox. Why am I paying this company every month for a tool that reconciles invoices and calculates GST? I could hire an engineer, build the same thing once, and own it. Their margin would stay on my balance sheet instead of theirs. The thought is seductive because it is not foolish. In fact, half of it is perfectly sensible. The trouble is that the sensible half sits exactly where entrepreneurial confidence lives: in the belief that a difficult expense can be turned into an asset through ingenuity and effort.

It resembles the old argument about buying a home instead of renting one. Rent disappears; a mortgage builds equity. Yet intelligent people remain divided over which is wiser, not because the arithmetic is beyond them, but because the arithmetic depends on a question no spreadsheet can settle: how certain are you about the future you are buying into? The debate over building GST software is the same question in office clothes.

The case for building

The build-it-yourself argument deserves to be taken seriously. The basic work is not mysterious. A system must match purchase invoices with GSTR-2B, flag discrepancies, track input tax credit, prepare data for GSTR-1 and GSTR-3B, and make sure deadlines do not slip past unnoticed. Give a capable developer a clear specification and enough access to the people who actually handle the books, and a useful first version can be built surprisingly quickly.

That is truer now than it was even a few years ago. Low-code platforms, reusable components and AI-assisted development have reduced the amount of labour required to create internal software. A project that once needed a formal product team may now begin with one good engineer and an operations lead who understands the process. Custom software is no longer reserved for large companies with extravagant technology budgets. The appeal is obvious: pay to build it, stop paying rent, and shape the tool around the business rather than forcing the business into somebody else's workflow.

There are genuine examples of this approach succeeding. Jetkool Exports, a Mumbai business, created a GST compliance and process-tracking application on a low-code platform. The company gained a single view of activity across several operational touchpoints that its earlier manual processes could not provide. In that setting, ownership brought a practical advantage: the system reflected the way the company already worked. But the example proves something narrower than advocates often suggest. Building can work when the problem is well defined, the scope is controlled, and the underlying platform carries much of the technical burden. It does not prove that custom software is automatically cheaper. The first version was never the expensive part of the story.

The cost that arrives later

Here is the question that tends to go missing from the midnight calculation. If a company has enough confidence in its five-year future to fund a custom system, does that confidence also extend to funding the people who will keep the system correct for those five years? GST software is not a desk that can be bought once and used until it wears out. It is a living compliance layer built on top of rules, filing systems and portal behaviour that continue to change. Tax rates change. Forms are revised. Validation rules are tightened. New workflows appear. A process that worked last quarter can become incomplete without anyone changing a line of the company's own code.

Recent changes make the point. The GST system has introduced the Invoice Management System, revised parts of the rate structure, expanded portal-based controls and begun enforcing a three-year limit on filing several categories of old returns. The details matter, but the larger lesson is simpler: compliance software is attached to a moving object. That changes the meaning of “pay once.” What the company buys is version 1.0. A system that reflects the rules and workflows understood on the day it is released. Ownership does not freeze the world around it. A mortgage usually buys a structure that remains where it was built. Buying compliance software is closer to buying a house on a floodplain. The house may be sound. The survey may be accurate. The price may even be excellent. But when the river changes course, ownership means the repair bill belongs to you.

The subscription is not evidence of weak ambition. Pretending maintenance will somehow take care of itself is.

Run the numbers honestly

A proper build-versus-buy calculation should not compare a vendor's five-year subscription fee with the salary cost of producing a first release. That comparison is flattering, simple and almost useless. The cost of ownership includes discovery, design, development, testing, integrations, hosting, security, backups, monitoring, documentation and support. It includes the hours finance staff spend explaining edge cases to engineers. It includes the cost of responding when an API changes, a portal rejects previously valid data, or a regulatory update lands during another important project. It also includes staff turnover: the person who understands why a particular reconciliation rule exists may not be there two years later.

Maintenance budgets are often estimated as a percentage of the initial build cost. That can be a useful starting point, but it hides the real problem. Maintenance does not arrive in a smooth annual stream. Some months require almost nothing. Then a rule changes, a filing deadline approaches, and the system needs urgent work from someone who already has a full queue. This is where many internal tools fail. Not in the first year, when the project has an executive sponsor, and the original developer remembers every decision, but in the third. By then the tool is ordinary infrastructure. The developer has moved on. Documentation is thinner than everyone remembers. A portal change is classified as important but not quite urgent—until a filing fails. In tax compliance, delay can carry an unusually sharp cost. A missed reconciliation is not merely an irritating bug. It can mean interest, penalties, delayed filing, or lost access to credit that should have been available. The company may not discover the problem when the software fails; it may discover it weeks later, when the accounts no longer tie out.

This is where the house analogy earns its keep. A renter can walk away when the agreement ends. An owner cannot. Ownership brings the benefit of building an asset, but it also brings every repair bill and every unwelcome surprise. Custom software works in much the same way: the savings belong to you, but so do the risks. That does not mean building your own system can never be cheaper. At the right scale, it often is. The calculation works, however, only when maintenance, compliance and staffing are treated as permanent costs rather than footnotes in the original budget. Those costs still have to be funded long after the excitement of launching the first version has worn off.

What the vendor is really selling

A specialist GST vendor is not mainly selling arithmetic. Matching two sets of invoice data is not the scarce capability. What the vendor sells is continuous attention. Its team watches the law, the portal and the filing process because failing to do so would damage every customer at once. The cost of interpreting a change, updating the product, testing it and supporting users is spread across a large client base. A regulatory shock that would land entirely on one in-house team is divided among hundreds or thousands of subscribers. That shared burden is the economic core of software as a service. Customers are not merely renting code. They are pooling the cost of vigilance.

Of course, vendors have their own risks. A product may be inflexible. Support may be slow. Prices can rise. A company may find its data trapped in an awkward export format or discover that a crucial workflow sits behind a more expensive plan. Buying software is not the same as buying certainty, and no sensible decision should be based on a sales demonstration alone. It is also worth noticing who usually tells each side of this story. Custom development firms publish articles explaining why bespoke software wins. Software vendors publish articles explaining why subscriptions are always cheaper. Neither group needs to fabricate the argument. Each can reach its preferred answer simply by placing inconvenient costs outside the frame.

The buyer's job is to put those costs back in.

Where the argument lands

In-house compliance software is not a mistake by definition. For a large organisation with many GSTINs, unusual workflows, mature data infrastructure and a permanent engineering function, ownership may be entirely rational. If the system creates a genuine operating advantage, not just a smaller software invoice, building it can be the right decision. The important distinction is whether the software is part of the company's edge or merely part of its plumbing.

If a custom system shortens fulfilment time, connects processes no standard product can handle, or produces insight that competitors cannot easily copy, ownership may deserve serious investment. If it simply reproduces a common compliance workflow, the company should ask why scarce engineering attention belongs there rather than on the product, service or customer experience that actually earns revenue. For most small and medium-sized businesses, that question tilts the answer towards buying. The subscription pays for more than access to a tool. It pays for a standing team whose livelihood depends on noticing the next change before the customer has to.

Real ambition is not the urge to own everything. It is the discipline to decide what deserves to be owned. The vendor is not charging only for code. It is charging so that, when the river moves again, somebody else is already watching the water.

4,000 words