Your company has a process that everyone agrees is broken and nobody has ever fixed. It runs on a spreadsheet that one person maintains, it is reconciled by hand every period, and each time it is raised the answer is the same: it is too small to justify a project.
That answer was correct. It is not correct any more, and the reason has nothing to do with the process. The cost of producing a small, well-specified piece of software has fallen far enough that a whole class of work has crossed from uneconomic to obvious.
ML LABS has taken more than ten heavy-workload systems to production over fifteen-plus years, across healthcare, telecom, PropTech, and finance. What has changed in the last two years is not what those systems do. It is which problems are worth pointing them at.
Why The Bar Moved
The economics here are old, and they are well documented. William Stanley Jevons observed that improvements in steam engine efficiency did not reduce coal consumption in Britain — they increased it. Cheaper coal per unit of work made coal-powered work viable where the previous price had made it uneconomic, so total use rose rather than fell. A survey of rebound and backfire across energy efficiency studies (Energy Policy, 2009) finds backfire well documented in productive uses where underlying demand is highly elastic.
Software inside a company is a textbook case of elastic demand. Most workflows that would benefit from purpose-built tooling were never built because of cost: engineering time is expensive, scoping is slow, and most candidates fail the budget review before anyone writes a line. AI-assisted development changes the unit economics of that backlog. A study on generative AI at work (NBER, 2023) found that access to an AI assistant raised resolved issues per hour by fourteen percent on average and by thirty-four percent for less experienced workers. When a small system's production cost falls far enough, projects that sat below the bar cross it — and they cross it in bulk, because only the bar held them back.
This is why a small, fixed-scope build exists as a category at all. It is not a discount applied to a large project. It is the point at which a single contained workflow becomes worth building properly, which is a point that did not exist a few years ago.
What The Newly Viable Work Looks Like
The work this unblocks is not what the technology industry builds for itself. It is what non-technical organizations have deferred, with a recognizable shape.
- Reconciliation and close processes that still run on spreadsheets because no packaged system on the market matches how your company's books actually work.
- Intercompany and cross-entity steps that were too small for a platform project and too consequential to leave to one person chasing other people by email.
- Reporting that is rebuilt by hand every reporting period, because the system of record produces something adjacent to what is needed but not the thing itself.
- Regulated data preparation, where raw output from source systems has to become analysis-ready without waiting on a full vendor procurement cycle to finish.
None of these is large. Each is viable and needs an owner: something has to decide what each system does, prove it does so, and keep it correct once it is load-bearing.
What Gets Harder, Not Easier
Lower production cost does not lower every other cost, and the parts that remain expensive are the same parts that decide whether or not the result is usable.
Deciding what the system must do stays expensive. A workflow that has lived in a spreadsheet for years is not documented anywhere, and the rules that matter are the exceptions that the person maintaining it applies without thinking about them. Recovering those rules is the work itself, and no model can do that part for you.
Proving it correct stays expensive. A change a model accepts as correct is not thereby correct. Without a written target and a way to check it, a quietly wrong small system is worse than the spreadsheet it replaced, since someone read the spreadsheet.
The cost of writing the software fell. The cost of knowing what it should do, and proving that it does, did not.
Where This Stops Being True
An organization already digitized end to end has no deferred backlog for this to reach.
The second boundary is organizational. A company that cannot say which processes it wants fixed gains no capacity from cheaper building — it accumulates unowned half-built systems, which is the failure the build-versus-buy decision is supposed to catch.
First Steps
- List the processes that failed budget review. Walk finance and operations, and write down every internal tool scoped and shelved. That list is the addressable surface.
- Separate faster from newly possible. For each item, ask whether cheaper production makes an existing initiative quicker or makes a previously uneconomic one viable. The second is where the value concentrates, and nobody has a budget line for it.
- Name one accountable owner per system. Before anything is built, name the person who owns its target. Without that owner, cheaper to build becomes cheaper to fail.
What To Do With The List
The expanded surface is a sequencing problem, more tractable than it sounds. You are not deciding whether to invest in software. You are deciding which of several processes you already know are broken should become software first, and the order for the rest.
That decision is worth settling on its own. A fifteen-minute call turns one candidate into a recommendation — scope, delivery path, budget, and a clear go or no-go — before any budget moves. Sometimes the recommendation is that the cheapest possible build is still the wrong one, and that answer then returns the entire budget to you.
When the answer is to build, the shape is fixed before work starts: one workflow, built against targets agreed in writing beforehand. Running it afterwards is a separate decision you make later, at $10,000 a month, deliberately hands-off — monitoring, incident triage, a review of cost and drift, and no code written, so the second workflow is a new engagement.
For choosing the first candidate rather than ordering a queue of them, which broken workflow should become software first is the companion piece to read next.
References
- Sorrell, S. Jevons' Paradox revisited: The evidence for backfire from improved energy efficiency. Energy Policy, 2009.
- Brynjolfsson, E., Li, D., and Raymond, L. Generative AI at Work. NBER Working Paper Series, 2023.
