Custom business software: a guide for decision-makers

Custom business software is built for a defined job in your organisation: a customer portal, an approval workflow, a shared operational system or a product you sell. It is worth considering when available products cannot reasonably support the important rules. It is not automatically cheaper, safer or more effective than buying and configuring an existing tool.

Our custom software development service starts by working out what people need to accomplish. Use this guide to prepare that decision before committing to a build.

Choose the business outcome before the features

Describe what should become possible. A customer might need to find the maintenance guidance for their equipment. A manager might need to approve a request with the right information available. An accounts colleague might need to see whether an invoice reached the accounting system.

For each task, identify the people involved, the current steps, the information required and the exceptions. A list of screens is easier to assess once those decisions are clear.

Compare buying, improving, connecting and building

Try a representative task in an existing product. Check the subscription level, permissions, export options and limitations that matter to that task. Configuration or a small improvement may provide a better route than a new application.

If the individual products work well but staff repeatedly move information between them, investigate an integration. Cloudfusion’s MTE Xpress work includes a Shiplogic-to-Sage invoice connection, with review and recovery tools. The purpose was a specific flow of information between existing systems.

A custom build becomes a stronger option when the important workflow or customer experience needs its own implementation. Genio Roasters’ customer aftercare portal brings maintenance guidance, diagnostics and training into one experience, supported by content management and completion tracking.

Define one complete journey for the first release

Choose a task people can finish. Include sign-in where needed, the records behind the interface, administration and the actions staff must take. Decide what can wait without making the first version incomplete.

For ViaVia, member journeys include invitations, trust connections, trip requests and private chat. The case study explains the connected application and the role of its technologies. Use examples like this to discuss scope, rather than assuming every app needs the same features.

Settle data ownership and access early

Decide which system owns each record and who can view or change it. Identify any existing information that must move, how it will be checked and what should happen to incomplete or duplicated records. Plan with synthetic or safely prepared examples.

Confirm account ownership, source code rights, licences, exports and the handover in the agreement. Discuss privacy and security requirements as part of the scope; a custom application does not establish legal compliance by itself.

Price the running system as well as the build

Separate discovery, design, development, data preparation, launch and ongoing operation. Hosting, subscriptions, monitoring, maintenance and future changes all affect the total cost. Compare proposals using the same assumptions and time period.

Be specific about who will look after releases, access changes and connected services. Agree the support scope and response arrangements. If more investigation is required before a reliable quote, establish the discovery work and fee first.

Test decisions and exceptions, not only screens

Write acceptance examples in ordinary language. A user should see only the records they are allowed to access. A repeated message should not create an unintended second action. A failed transfer should become visible to the person responsible for resolving it.

Agree how these behaviours will be checked and review working features with the people who will use them. A demonstration shows a particular example; it is not a substitute for the project’s security, load and recovery testing.

Decide what you will measure before launch

Choose a baseline that relates to the task: completion time, waiting time, repeated entry, exceptions or requests for help. Include the time spent checking and correcting work. Compare similar tasks after the team has had time to use the new system.

Our guide to measuring software efficiency explains how to make that comparison useful without relying on a generic savings percentage.

Prepare the first conversation

Bring the task you want to improve, the tools you use now, the people involved and any fixed constraints. A safe example of a real working day is more useful than a long wish list.

See our custom software projects, compare systems integration and existing software improvements, then discuss a suitable first phase.