Skip to main content
nimbryx
← All posts
StrategySoftware Development10 June 2025 · 5 min read

Why Most Software Gets Built Backwards

Most software projects pick a tool first and go looking for the problem later. Why that sits behind half the failures we get called in to fix.

Here's how most software projects we get called into started. Someone sat through a SaaS demo, liked what they saw, signed up, and then spent six months bending the business to fit the tool. It didn't fit. It almost never fits cleanly. So the workarounds arrived: a spreadsheet running alongside, a WhatsApp group for the things the tool couldn't track, and one junior person who quietly became the "system admin" because they were the only one who knew how to translate between the software and what was actually happening on the floor.

That's building backwards. Almost everyone does it, and almost nobody admits it.

The right direction

Start with the workflow. Not the feature list, not the platform, not the framework someone on LinkedIn swears by. The first question is what does this business actually do? And we mean in detail. Who touches a record first? Who touches it next, and under what conditions? Where does the information come from, and who needs it at the end?

Once you can answer that, you can judge whether an existing tool serves you or whether you need something built around the way you work. Before that, you're just comparing demos.

What backwards looks like in practice

  • You change the process to suit the software.Your team stops doing what works and starts doing what the tool allows. Give it a year and the tool's logic has become your logic, even where it's plainly wrong for you.
  • Edge cases turn into manual exceptions.The tool can't handle certain cases, so someone writes them down in a shared notes file. The file gets forgotten. Then the person who knew the exceptions leaves, and you rediscover them one angry customer at a time.
  • Reports are always nearly right. The data is in there somewhere, just never in the shape you need. Every board meeting starts with someone exporting, cleaning and reformatting.
You end up with a system that records your compromises instead of how your business works.

What forward looks like

When software is built around a workflow instead of dropped on top of one, you notice something odd. People use it without being chased. It's not that the screens are pretty. It's that the system matches how they already think about their job, so there's nothing to translate.

Custom software gets you there when the brief is right. A configurable off-the-shelf tool sometimes gets you there too. What almost never gets you there is a selection process that began with a sales demo.

The one question to ask first

Before demos, before proposals, before you talk to a single vendor or developer, write down what happens when a new order comes in. Or a new client is onboarded. Or something goes wrong. Plain language. Every handoff. Include the embarrassing bits that still happen on paper or in somebody's notebook.

That document is your real requirements. The rest is implementation.


Every Nimbryx engagement starts with exactly this conversation, before anyone mentions technology. If you can't tell whether you need custom software or just a better-configured tool, it's a conversation worth having. Get in touch.

ShareWhatsAppLinkedInX

Work with Nimbryx

Have something you want built?

We work with a small number of clients at a time. If you have a project in mind, tell us what it is — no long forms, no agency boilerplate.

Start a conversation →