The feature promised 'on the roadmap' that never arrives

You asked your support contact for this feature, then your account manager, then at the yearly review. The answer is always the same: it is on the roadmap. It has been there for two years, and nobody can tell you when it will ship.

Why your request stays near the bottom of the pile#

Off-the-shelf software serves thousands of companies, across several trades at once. Every feature added costs development time, testing, documentation, support. The vendor weighs it against every other request received that same week, and picks the one that touches the most clients, or unlocks the most new contracts.

Your request isn't a bad one. It's simply a minority one. If you're the only client in your trade, or one of the few who work this particular way, your need never outweighs the thousand other clients who have no use for it. This isn't bad will: it's the arithmetic of a product built for the largest possible number of people.

The four answers you get instead of a no#

A vendor rarely says no outright. It answers differently, and each answer is worth translating:

None of these answers is a lie. They simply describe a product that has to stay coherent for everyone, not for you.

How to tell if a feature will actually ship#

Four questions are enough to know, before waiting another two years:

• The vendor's changelog over the last two years: does your trade show up even once?
• Is the announced date a precise quarter, a vague season, or just "soon"?
• How many other clients asked for exactly the same thing? If the vendor won't answer, it usually means "not enough".
• Do the vendor's biggest clients work in your trade? If none of them do, your request will never become a priority.

If all four answers are disappointing, the feature won't ship this year, and probably never in the form you expect.

The workaround you build while you wait#

While you wait, someone invents a manual method. Take a building materials distributor whose software can't match a delivery note to its original order on its own: the feature has been requested for a long time, always "on the roadmap". One person re-enters every note by hand, six minutes on average. Across forty-five notes a week, that's four and a half hours a week, roughly two hundred hours a year spent doing what software built for this trade would do on its own. This figure is a hypothesis to show the calculation, not the result of a real company.

This workaround never costs anything the first month. It becomes expensive because it is still there two years later, with the same person still doing it by hand.

What changes with an application built for the company#

A feature request becomes a direct conversation with whoever builds the screen: you look together at how the delivery note arrives, what needs checking, what should flow automatically into the invoice. Priority is set by what it costs your business today, not by what a thousand other clients think.

What changes in practice: the missing screen gets built in a few weeks, not after waiting for a release cycle shared with everyone else. It matches the exact gesture of the person using it, not a generic setting designed to fit every trade at once. And the next request follows the same path, without going back through a roadmap that belongs to someone else.

What not to expect#

Building a feature for a single company doesn't mean everything ships instantly. Requests are still ranked by what they save, and some wait their turn for a few weeks. The difference is that you set that order, not a product serving a thousand other companies at the same time.

Feature promised: the key takeaways#

A feature stuck on a roadmap isn't forgotten out of neglect: it loses, at every arbitration, against the needs of more clients than you. Before waiting another year, four questions are enough to know whether it will actually ship.

The workaround you build while waiting, however small at first, ends up costing more than the feature itself. An application built for a single company changes that order of priority: the grid between Excel, an ERP and custom software and an old ERP opened rather than replaced show how these three tools combine, but it's how we build an application for a single company that actually solves this problem of a feature that never arrives.