Building fast isn't enough to make a custom software project work

An SME can now get a working prototype of custom software in a few days with AI, where it used to take weeks. That's real progress. It's also a trap: a prototype that runs gives the impression the project is good, when it proves nothing about the one question that actually matters, whether anyone will really use it.

Josh Elman, a former product lead at LinkedIn and Twitter, sums up this shift in a recent essay: the cost of building has collapsed, but the cost of judgment, deciding what to build and for whom, hasn't moved an inch.

What AI changed, and what it didn't

It used to be that a company wanting custom software had to write everything down first: requirements, budget, timeline, before spending a single euro on development. The logic was simple: development was expensive, so you had to be sure before committing.

That logic has flipped. Building a first prototype now costs almost nothing and takes a few days. The risk is assuming that flip solves the underlying problem. It just relocates it: now that anyone can build almost anything, deciding what to build is the only work left.

💡 A prototype doesn't exist to prove a project works technically. It exists to find out, before investing in the real build, whether the original idea holds up once it meets a real user.

The test most people skip: real frequency

The question most business owners ask about a custom software project is whether people use it. The better question is more precise: do people take the exact action the tool was built for, and how often.

A tool can show impressive numbers (accounts created, logins, tickets opened) without anyone ever taking the action that justifies its existence. The right move, before building anything, is naming three things:

• Purpose: why someone would open this tool and fold it into their day.
• Core action: what they actually do inside it, not what they look at.
• Expected frequency: several times a day, once a week, or twice a year. All three are legitimate, as long as you know which one before building, not after.

🔍 The test before starting a project: if no one on the team can answer these three questions in one sentence each, this isn't a project ready to build yet. It's still an idea that needs scoping.

The questions we get asked most often

How do I know if my idea is worth a full build before paying for one?

Three concrete signals to check before writing a check. First, is the task already being done by hand, regularly, by more than one person? A tool that replaces a real repetitive action has a much better shot at adoption than one that offers a new way of doing something nobody asked for. Second, can you name one specific person who would use it in week one, not "the team" in general? If you can't name that person, that's the clearest signal a real user is still missing from the idea. Third, can you say in one sentence what that person will do differently afterward, concretely? If the answer stays vague, the idea isn't ready to build. It's still ready to be sharpened.

Why does a well-built internal tool end up going unused?

Usually it isn't a technical quality problem. It's that the tool ships on the assumption its usefulness is obvious, without anyone showing, step by step, what to actually do inside it. Teams drift back to their old habits, not because the tool is bad, but because nobody taught them the new reflex. The fix is almost never one more feature. It's better support during the first few uses.

Should I start with a prototype, or a full spec?

Neither comes first, really. A prototype exists to quickly check whether an idea holds up against real use, it takes a few days and costs little. A full spec exists to scope the real build, once you already know the idea holds up. Writing a full spec before testing the idea means detailing a plan for something that hasn't proven its usefulness yet. Testing before specifying is the order that wastes the least.

How long does proper scoping actually take?

Usually a few days, not weeks. Most of that time doesn't go into writing a document, it goes into talking to future users to check that the purpose, the core action, and the expected frequency hold up. That's a lot shorter, and cheaper, than finding out the answers after several months of development.

An example that makes the problem clear

The now-classic case is early Twitter. The service was already in the news, millions of people signed up out of curiosity, and almost none of them came back. The problem wasn't technical: nobody understood what to actually do once signed up. The home page showed an empty box with nothing on it, and newcomers left about as fast as they'd arrived.

The team fixed it not by adding features, but by teaching the product step by step right from sign-up: first explaining what a tweet is, then getting people to follow one account, then showing how that single action filled their timeline immediately. That redesign of onboarding moved retention more than any other feature shipped that year.

⚠️ The trap to avoid: this isn't a problem reserved for big US tech companies. An SME owner who has an internal tool built (scheduling, client tracking, a portal) falls into the same trap the moment they ship it without showing the team, step by step, what to concretely do in it.

What this changes about how you launch a project

Nightborn applies this principle before any development starts: Product Discovery exists specifically to answer these three questions (purpose, core action, frequency) before committing a build budget, to avoid finding out after the fact that a well-built tool answers no real need.

That's what made the difference on the Medicheck project: before building the custom back-office software, the Nightborn team first spent time understanding how the operations staff actually worked day to day. The result: processing time for a medical check dropped from 20 to 5 minutes, because the tool matched how the team already worked, not an abstract idea of what they might need.

On a larger project, that's the role of an MVP: build only the version that lets you verify real usage, before investing in everything else.

Key takeaways

• A prototype that works proves nothing about adoption. It only proves the tech holds up.
• The real work, before building, is naming the purpose, the core action, and the expected frequency of the tool.
• The technical part got fast. The judgment on what to build didn't, and that's where a project's success or failure actually gets decided.

Next time a prototype impresses you, the right question isn't "does it work technically?" It's "who's actually going to use this, and for what, once the novelty wears off?"