The Case for Building Internal Tools Instead of Forcing New Workflows

When a workflow doesn’t match an off-the-shelf tool, two paths exist. Option one: change the workflow to match the tool. Option two: build a tool that matches the workflow. Companies pick option one most of the time. They usually shouldn’t.

Why “force the workflow” feels easier

It feels cheaper. The tool already exists. You just have to teach the team how to use it. No engineering, no project timeline.

It feels lower-risk. Off-the-shelf tools have references, support, and proven patterns.

It feels modern. Adopting “best practices” sounds like operational maturity.

All three are partially true. None of them account for the cost of forcing a workflow that doesn’t fit.

What forcing actually costs

Three real costs:

Adoption resistance. People don’t naturally adopt workflows that don’t match how they actually work. They develop workarounds. They use the official tool minimally. The investment underdelivers. (See How to Tell If Your Team Is Working Around Software.)

Information loss. The “old workflow” had nuance the team had developed over years. The forced workflow loses that nuance. Decisions get worse before they get better.

Continuous friction. Every quarter, the team rediscovers that the tool doesn’t quite fit. They add another workaround. Maintenance compounds.

When building wins

Building wins when:

• The workflow is specific to your business
• Volume is high enough that small efficiencies compound
• The workflow is likely to evolve (and you want control of the evolution)
• The team has expressed adoption resistance to off-the-shelf alternatives

Insurance workflows. Multi-state moving. Complex healthcare scheduling. Specialty manufacturing. All examples where building tools that match the workflow has consistently outperformed forcing workflows into generic tools.

When forcing wins

Forcing wins when:

• The workflow really is generic (accounting, payroll, calendar)
• The off-the-shelf tool fits 90%+ of the actual workflow
• Customization isn’t really needed, just configuration
• The team doesn’t have strong attachment to the existing workflow

For these, don’t build. The off-the-shelf vendor has solved the problem better than you would.

The takeaway

Most companies, asked the test question honestly, find they’re forcing more workflows than they should. The fix is to admit it, pick one workflow at a time, and build the tools that actually fit. (See How to Build Software Around People, Not Just Processes.)