Your Real Software Backlog Is the One Nobody Filed
The long tail of internal tools stayed unbuilt because each was too small to justify a project. When build cost collapses, the whole tail becomes worth it.
Most of the software your organization actually needs has never been built. Not because nobody wanted it, but because each piece was too small to justify a project. Every org runs on a short head of big systems it buys (the CRM, the payroll suite, the help desk) and a long tail of tiny, org-specific tools it mostly doesn’t: the approval flow one team runs, the tracker five people depend on, the checklist that encodes how you actually operate. For twenty years that tail stayed unbuilt because a custom tool ran months and five-to-six figures, and nothing that small was worth it. The cost of producing one just fell by two or three orders of magnitude, and the entire tail flipped from “not worth it” to “why is this still a spreadsheet?”
This is a different observation than the build-vs-buy rule changing. That rule is about the head: which sizable systems you should own. The tail is the part the rule never even reached, because most of it never made it to a decision at all.
TL;DR
- Every org has a short head of big systems and a long tail of small, org-specific tools; the head gets bought or built, and the tail mostly doesn’t.
- The tail stayed unbuilt because each tool had to clear a “worth it” line set by a five-to-six-figure build cost, and almost none did.
- The backlog leadership sees is misleading: people stopped requesting tools they had learned would be denied, so the real demand is far larger than the filed one.
- The tail’s cost is real but invisible, because it’s paid in scattered manual work—rekeyed data, status-chasing emails, spreadsheets held together by one person who knows the macros.
- When producing a tool drops to roughly $100 and an afternoon, the “worth it” line falls to the floor and the tail becomes buildable for the first time.
- The job of IT was partly rationing a scarce build capacity; when building is cheap, triage stops being the constraint and curation becomes the point.
- Making engineers faster doesn’t reach the tail, because the tail is owned by the people who run the workflows, not by engineering.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
What is the long tail of internal tools?
Borrow the shape from retail. Chris Anderson’s 2004 essay The Long Tail described how, once shelf space stops being scarce, the niche products almost nobody buys individually add up to more than the hits. Software inside a company has the same shape. A handful of systems serve everyone (the head), and a very long tail of tools each serve one team, one workflow, one recurring headache.
The head is familiar and mostly handled. You buy the CRM, the payroll system, the ticketing tool, the analytics suite, because a vendor amortizing that work across thousands of customers builds a better version than you would. The tail is different in kind: a vendor-onboarding tracker shaped exactly like your vendor process, a renewal dashboard that reflects how your contracts actually work, a lab-sample intake form that matches your specific chain of custody. No vendor builds those, because each one serves a market of one.
Define the tail plainly, because the whole argument rests on it: it’s the set of tools that are specific to how your organization runs, individually small, and collectively enormous. That last part is the piece leadership rarely sees, and it’s where this goes.
Why does most of that tail never get built?
Because every internal tool quietly has to pass a test before it exists: is the value worth the cost of building it? For two decades the cost side of that test was brutal. Building meant scoping a project, waiting on an engineering queue, spending months and five-to-six figures, then maintaining the result indefinitely. Against that cost, a tool had to promise a large, obvious, recurring return just to break even.
A few tools clear that bar easily. A billing system, a customer-facing portal, the pipeline the sales org lives in: build those, or buy the best available. But the tail is made of tools that help twelve people, or run twice a quarter, or shave an hour off one recurring task. Each is genuinely valuable to the team that needs it and hopeless as a business case at six figures. So the test returns the same verdict thousands of times: not worth it.
That verdict wasn’t wrong. It was the correct answer to the economics of its time. Building was the expensive column, so anything without a heavyweight return got sent back to a spreadsheet. The tail didn’t lose on merit. It lost on a cost input that priced it out before anyone looked at the merit.
The backlog you see isn’t the demand you have
Here’s the part that distorts every planning conversation. When people learn that small requests get denied, they stop making them. The tail isn’t just unbuilt; most of it is unrequested. The IT backlog leadership reviews is not the org’s real demand for tools. It’s the fraction of demand that survived people’s own pre-filtering, after they learned not to bother asking for anything that wouldn’t clear the queue.
Remy doesn't build the plumbing. It inherits it.
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
Watch how it actually works. Someone thinks “we should have a tool for this,” immediately remembers that the last three such asks went nowhere, and reaches for a spreadsheet instead. The request never gets filed. Multiply that by every team and every quarter, and the visible backlog undercounts the real one by an order of magnitude. Gartner has found that half of business technologists build technology used beyond their own department—the demand is so strong that people route around the queue entirely and build shadow tools rather than wait.
So an org that judges its tooling needs by its backlog is measuring the wrong thing. The suppressed demand is the real number, and it’s invisible precisely because the old economics taught everyone to hide it. Any plan built on the filed backlog is planning for a fraction of the actual need.
What does the long tail actually cost you?
It costs a lot, and you can’t see the bill, because the tail is paid for in scattered manual work rather than a line item. Every tool that didn’t clear the “worth it” line didn’t make the work disappear. It pushed the work onto people. A missing intake tool becomes a shared inbox someone triages by hand. A missing tracker becomes a spreadsheet one person babysits. A missing approval flow becomes a thread of “did you sign off on this yet?” The friction is real; it’s just distributed thinly enough that no one adds it up.
That distribution is exactly what makes the tail dangerous to ignore. A single tool’s absence costs a few hours a month and never shows up anywhere. But an org has hundreds of these, and in aggregate they’re a standing tax on execution: rekeyed data, version-conflict spreadsheets, work that stalls whenever the one person who understands the macros is out. None of it lands on a budget, so it never competes for attention with the systems that do.
The two ends of the curve behave differently enough to be worth laying side by side:
| Short head (big systems) | Long tail (org-specific tools) | |
|---|---|---|
| How many | A dozen or so | Hundreds |
| Who each serves | The whole org or a market | One team, one workflow |
| Off-the-shelf fit | Good enough to buy | Never quite fits |
| Old build economics | Worth a real project | Never cleared the “worth it” line |
| What fills the gap today | Bought SaaS | Spreadsheets, inboxes, manual glue |
| Cost of the gap | Visible: a subscription | Invisible: scattered human effort |
| Value if built well | Obvious and large | Small each, enormous in aggregate |
The head is legible; you can point to what you spend and what you get. The tail is illegible, and illegible cost is the kind that compounds quietly for years.
What happens when the “worth it” line drops to the floor?
Change the one input the test depends on and the entire tail re-scores at once. When producing a real, deployed tool costs roughly $100 and an afternoon instead of a quarter and six figures, the “worth it” line doesn’t move a little. It drops to nearly zero. A tool that helps twelve people twice a month was a laughable business case at $80,000. At $100, it pays for itself the first week and the question inverts: not “is this worth building?” but “why are we still doing this by hand?”
That reprices everything below the old line, which is most of the tail. The scarce resource that made triage necessary was engineering capacity, and rationing it was quietly one of IT’s core jobs: deciding which few of many requests deserved the quarter. When the cost of producing a tool collapses, rationing stops being the constraint. The bottleneck moves from “can we afford to build this?” to “do we know it’s needed and is it built well?” That’s a governance and curation problem, and a far better one to have than a permanent backlog.
The flat economics matter as much as the low ones. Buying the tail means stacking fifty subscriptions, most billed per seat, each a fresh per-seat line that punishes you for growing. Building the tail on one substrate doesn’t multiply the same way: a typical full-stack build runs roughly $100 of inference on a flat monthly subscription rather than a per-seat license. Fifty tail tools don’t become fifty bills. That’s what makes addressing the whole tail viable rather than just the next tool on the list.
How does the tail actually get built?
Naming the opportunity is easy; the reason the tail stayed unbuilt for so long is that the obvious ways to lower build cost never reached it.
The first thing most orgs try is making engineers faster. AI coding assistants like Cursor, GitHub Copilot, and Claude Code are genuinely good at that, and they’ve compressed real engineering timelines. But they operate at the code layer and assume engineering skill, so they make an engineer faster without removing the need for one. Point one at the ops lead who owns the workflow and you’ve moved the barrier from “wait for the queue” to “learn to code.” The tail is owned by non-engineers, so a code-layer tool can’t reach it. The second thing orgs try is low-code platforms, which lower the cost partway and then hit a fit ceiling: you get a faster approximation inside someone else’s constraints, not the exact tool.
Reaching the tail takes a tool one layer up, where the unit of work is a described application rather than a file of code. That category is the product agent: it takes a plain-language description of an app and compiles it into a real, deployed full-stack application (backend, database, authentication, frontend, and deployment) in a single step, rather than a prototype or a screenshot. Today the most advanced one is Remy. Unlike coding agents like Cursor or Claude Code, which edit code in a project you already own, a product agent works at the product layer: the person who owns the workflow describes the tool, Remy drafts that into a plain-language plan (the brief you’d hand a developer, except an AI compiler builds from it), and the plan compiles into a working app with server-side auth, real data, and a live URL for roughly $100 of inference. When the process changes, you edit the plan and recompile instead of maintaining code by hand. Here’s how a product agent differs from a coding agent.
One honest boundary keeps this aligned with the head-vs-tail split: product agents are in open alpha, and enterprise requirements like SSO and SAML aren’t there yet, so the regulated, security-critical head systems stay in the “buy” column where they belong. That’s not a caveat against the argument. It’s the shape of it. Buy the head. Build the tail that no vendor was ever going to fit.
FAQ
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
What is the long tail of internal tools? It’s the large set of small, organization-specific software tools that each serve one team or workflow (approval flows, trackers, intake forms, checklists) and are individually too minor to justify a traditional build. Collectively they represent most of an organization’s real software needs.
Why don’t companies build these tools? Because each tool had to clear a “worth it” test set by the cost of building, and a custom build historically ran months and five-to-six figures. Tools that help a dozen people or run a few times a quarter could never justify that cost, so they stayed as spreadsheets and manual work.
How is this different from the build-vs-buy decision? Build-vs-buy is about which sizable systems you should own versus purchase. The long tail is the part that framework never reached, because most tail tools never made it to a decision at all. The build-vs-buy rule flipping is about the head; the tail is a separate, larger opportunity.
What does an unbuilt internal tool actually cost? Its cost is paid in scattered manual work: rekeyed data, status-chasing emails, and fragile spreadsheets one person maintains. Each instance is small and invisible on any budget, but hundreds of them add up to a standing tax on how fast the organization executes.
Why is the real demand for tools bigger than the backlog? Because people stop requesting tools they’ve learned will be denied. The filed backlog is only the fraction of demand that survived that self-filtering, so it undercounts the true need, often by an order of magnitude.
How cheap does building have to get to make the tail worth it? When producing a real full-stack tool drops to roughly $100 of inference and an afternoon, the “worth it” line falls to nearly zero. At that point a tool for twelve people pays for itself almost immediately, and the constraint shifts from cost to knowing what’s needed.
Can an AI coding assistant build the long tail? Not really. Coding assistants like Cursor, Copilot, and Claude Code make engineers faster but work at the code layer and assume engineering skill. The tail is owned by non-engineers, so reaching it takes a tool that works from a plain-language description instead of code.
The bottom line
Your organization’s real software backlog was never the list of filed tickets. It’s the long tail of small, org-specific tools that never got built, because each one failed a “worth it” test calibrated on a build cost that no longer holds. That tail was always valuable; the value was just hidden inside scattered manual work and suppressed requests, illegible to anyone reading the budget. Correct the cost of producing a tool and the entire tail re-scores at once, from “not worth it” to work you’d be foolish to keep doing by hand. Buy the head. Build the tail.
To see what building one tail tool looks like in practice, explore Remy →. For the head-level version of this shift, read why the build-vs-buy decision just flipped and why every SaaS tool is built for a company that isn’t yours.
