Custom software projects fail for many reasons, but one stands out: building for an imagined workflow instead of the real one.

When we start a new project at shift42, we spend time understanding how teams actually operate. Not the process documented in manuals, but the workarounds, the spreadsheets, the sticky notes, and the informal systems that keep things running.

The gap between design and reality

Most operations have evolved organically. Teams develop shortcuts, create their own tools, and find ways to make imperfect systems work. This institutional knowledge is invaluable.

“The best software doesn’t replace how people work. It amplifies what already works and removes friction from what doesn’t.”

Ignore these patterns, and you end up with software that people tolerate rather than use. The moment pressure hits, they’ll revert to the old spreadsheet because it actually makes sense to them. We’ve seen it happen: expensive systems gathering dust while the real work happens elsewhere.

Starting with observation

Before we write any code, we watch. We sit with the people who’ll use the software and see how they actually get through their day. The documented process rarely tells the full story. It’s the exceptions that matter. These are the things that happen often enough to be routine but never made it into any manual.

Where do people hesitate? Where do they copy data from one place to another? Where do they pick up the phone instead of using the system? These friction points tell us more than any requirements document.

Why this takes longer (and why that’s fine)

This approach isn’t fast. Spending time upfront to understand real workflows delays the first line of code. But it dramatically shortens everything that comes after. Training becomes simpler because the software already feels familiar. Adoption happens naturally because the tool fits the work, not the other way around.

The alternative is to build quickly and iterate. It sounds efficient until you’re on your third major revision and people still aren’t using it.

Conclusion

The goal isn’t perfect software. It’s software that makes real operations more effective. When teams see their actual workflow reflected in the tools we build, adoption becomes natural rather than forced.

Want to discuss how custom software could support your operations? Get in touch.