What Used to Take Months: The Case for Building Your Own Tools

What Used to Take Months: Why Mid-Sized Companies Should Build Their Own Tools Now

At a mid-sized logistics company, one experienced dispatcher planned the routes and calculated the prices for years – in a tangle of spreadsheets nobody else fully understood. Several hours a day, prone to slips, and entirely dependent on a single person. When she was out, the process stopped.

The obvious fix was a tool built for exactly that job. It was never built. Not because no one saw the problem, but because the math used to argue against it. Bespoke software meant a requirements document, a tender, months of external development, and a six-figure bill before long. A large standard system for freight forwarders was too expensive, too heavy, and still didn't match the company's actual workflow. So nothing changed – the spreadsheet, the overtime, the risk all stayed.

That math is now inverting. This isn't a marketing claim; it's a sober consequence of what building small, sharply scoped software costs today. This article turns one anonymized case into an argument: for the few processes that make a mid-sized company distinctive, building your own tool has gone from a luxury to the rational default.

The old math – and why it held for so long

For two decades, the software decision in the mid-market followed a simple three-step rule. Buy standard software where it exists. Where it doesn't, live with the spreadsheet. And only in exceptional cases – when the problem was big enough and the budget full enough – have something built.

That reflex was correct. Custom development was expensive, slow, and risky. The largest cost was never the code itself, but everything around it: clarifying requirements, running a tender, finding a vendor, rounds of revisions, change requests. A tool that was, at its core, a spreadsheet with logic could easily balloon into a project spanning two or three quarters. On thin margins, that rarely justified itself.

The trouble sat in the bottom row. The process that genuinely separates a company from its competitors is, by definition, not standardizable – otherwise it wouldn't be a difference. That is exactly where off-the-shelf software helped least and where building cost most. So mid-sized firms got stranded precisely on the thing that mattered most, and made do with the spreadsheet. The build-versus-buy literature has long agreed on the principle: build when the software defines how you operate and serve customers; the hidden cost of a poorly fitting standard tool is the daily manual workaround it forces on the team.

What changed

Three developments have collapsed the most expensive part of custom development – the effort that isn't the actual code.

First, modern building blocks. Authentication, database, hosting, integrations: what used to be weeks of groundwork is now finished, affordable standard. A small team no longer starts at zero; it starts at eighty percent.

Second, AI-assisted development. Assistants now write, explain, and review code alongside the developer. In a controlled study by GitHub, developers completed a well-scoped programming task roughly 55% faster with assistance than without. McKinsey reports comparable orders of magnitude in its own experiments – with one important caveat we'll get to shortly.

Third, a different cut. Instead of a system meant to do everything, you build a tool that does one thing well. A smaller cut means fewer requirements, less coordination, less risk – and so weeks instead of months.

Note what this chart does not claim. It does not say every piece of software now ships in five weeks. It says: for a clearly bounded tool, the order of magnitude has dropped from months to weeks. And that small-tool range – sharp, narrow, owned – is precisely where the mid-market's bottleneck lives. It's where the leverage is greatest.

Why it matters now: two pains

The drop in cost would be a footnote if it didn't meet two pressures almost every mid-sized company knows.

The skills shortage. In Germany alone, industry body Bitkom counts roughly 109,000 unfilled IT roles; 85% of companies report a shortage, and nearly four in five expect it to worsen. Worldwide, analysts have projected the developer gap in the millions. For a mid-sized firm the consequence isn't that it can't staff a large IT department – it never wanted one. It's that every hour of the people it already has is scarce. Software that removes manual routine isn't a comfort here; it's the only way to get more done with the same crew.

Price pressure. Where margins are thin, efficiency decides the profit. And efficiency rarely comes from the standard process everyone runs equally well – it comes from your own, the one you run better than the competition. In logistics in particular, competition is fierce and margins are slim, which is exactly why a sharper internal process pays.

That KfW figure is the real trigger for this article. Only about a third of mid-sized firms recently ran any digitalization project at all; the cited barriers are missing know-how, infrastructure, and financing. Translated: most are leaving value on the table – not out of reluctance, but because the old math still rules in their heads. It no longer holds.

The honest caveat

Showing only the upside would be selling hype. So here's the counter-evidence, openly on the table. AI-assisted development does not make everything faster. In a randomized study by the research group METR, experienced open-source developers working on their own large, familiar codebases were actually 19% slower with AI tools – while believing they had been faster. McKinsey likewise reports that time savings shrink into the single digits on complex, unfamiliar tasks.

This doesn't contradict the thesis – it sharpens it. The gain is large on small, clearly bounded tasks and evaporates as the system grows larger and less familiar. For an enterprise IT team working a million-line codebase, the AI euphoria is premature. For a mid-sized tool that maps a single process, it lands squarely. The niche where the leverage is greatest is exactly the mid-market's niche.

The practical lesson is a discipline, not a technology: cut it small. A tool that does one thing well beats a system that does everything a little – not despite its limits, but because of them.

The case, finished

Back to the logistics company. In the end the decision wasn't about technology but about scope. Instead of a freight system for everything, the company got a tool for exactly one workflow: plan the routes, calculate the prices, document the result cleanly.

Three effects are telling, because they address both pains directly. The time saved answers the skills shortage – the same crew gets more done. The sharper pricing answers price pressure – at the exact point where the margin is made. And the fact that the procedure no longer sits in a single head removes a risk that appears on no balance sheet but keeps every owner up at night.

What this does not mean

So the argument doesn't curdle into ideology, three clear limits.

It does not mean building everything yourself. Accounting, payroll, email, the standard CRM – buy them. Anyone who writes their own accounting system has confused activity with value. Building only pays where standard software doesn't fit and the process contributes to the difference.

It does not mean software runs itself. A tool no one uses is more expensive than the spreadsheet everyone uses. The hardest part is rarely the code; it's adoption – habit, trust, the quiet pull of the old way. Ignore that and you've built a monument, not a tool.

And it does not mean trading one dependency for another. An in-house tool is only an advantage if you own it – with data export, open formats, and a stack someone else could maintain. Otherwise you've swapped a spreadsheet bottleneck for a vendor bottleneck.

Our position

At balane we build software for mid-sized companies – we advise, develop, and automate, and we look at every project through three lenses at once: business, psychological, and technical. The logistics case shows why those three belong together. The business lens asks the build-versus-buy question honestly and sometimes answers: buy, don't build. The technical lens keeps the build lean and portable, with no lock-in. And the psychological lens decides whether the tool actually gets used – or whether the old spreadsheet quietly keeps running in the background.

Our stance on building your own is therefore unexcited: it is rarely too expensive anymore and often too obvious to leave on the table – but only with disciplined scope and clear ownership of code and data. The paradigm shift isn't that suddenly everything is possible. It's that the one tool that used to fail the math now passes it.