Before you commission custom software

Write down the work that matters

A software decision is easier to evaluate when it starts with a task someone needs to complete. Describe the task, the information required and the result. Include the exceptions that people currently resolve outside the system. A feature checklist alone can miss those details.

Use those examples to test an existing product and a proposed custom application against the same requirements. Ask someone who does the work to walk through the examples. Record where the process fits, where it requires a workaround and where your team would need to change its practice.

Include the connections in the decision

Buying a product does not remove the need to connect it to the rest of your business. Data still needs to arrive in the right form, permissions need to match responsibilities and failures need somewhere to go. A demonstration that uses prepared data may not reveal that work.

The article You Can’t Buy Integration, published on Martin Fowler’s site, makes this distinction explicit: purchasing software does not purchase a finished integration architecture. Apply that idea by asking who will own each connection and how changes on either side will be handled.

• What information enters and leaves the system?
• Which system is authoritative when records disagree?
• Who can change a connection, and how is that change tested?
• How will staff recognize and recover a failed handoff?

Compare ownership after launch

For a product, understand configuration, access, export options and the work required when the supplier changes something. For custom software, understand maintenance, documentation, monitoring and the team responsible for updates. Include those responsibilities in the comparison.

A custom application can be appropriate when a distinctive workflow is central to the business and available products would force costly compromises. An existing product can be appropriate when the work is well served and your organization can adopt its operating model. Some situations need both: a purchased system with a small, deliberately scoped custom component.

Test the uncertain part first

If one integration or workflow determines the whole decision, investigate it before committing to a large build. A focused technical check or working prototype should answer a named question, with a clear rule for deciding what happens next.

We can help evaluate the choices, develop a custom application or take on a defined software scope. The useful outcome is a system your people can operate and maintain, with responsibilities understood before delivery begins.