Off-the-shelf software or a custom application?

Compare how a task gets done

A feature list is a weak basis for choosing software. Two products may both promise “order management” while handling revisions, attachments, access and handovers differently. Prepare examples from your own business and ask to work through the same examples in each option.

Include a normal job and exceptions: incomplete information, a changed deadline, cancellation and a correction after work has started. Check what the office user, the person doing the work and the manager can see. A polished screen matters when people can complete the necessary task on it.

Consider three practical routes

Configure what you already use

Ask whether the current program can provide the missing view, field or rule. An unused module may also cover the need. Confirm the answer for the actual edition, licence and setup your business uses; a demonstration of another configuration is not enough.

This option is worth investigating when most relevant information is already in the system. The limitations may be awkward daily use, costly configuration or restrictions on later changes. Include the person who maintains the current software in the discussion.

Adopt an off-the-shelf product

A ready-made product is worth testing for tasks shared by many businesses, such as tracking enquiries, time or service requests. You can inspect existing behaviour before deciding to implement it.

The subscription is only part of the commitment. Someone still needs to agree the workflow, clean and transfer data, set access and train users. Check user limits, paid additions, integration conditions and how you can export information if you leave.

Commission a custom application

Custom software can make sense when important rules do not fit the available products. An example is a job handover requiring specific documents, checks and different permissions for several roles.

You can define the scope and screens around that work. You also need to plan development, testing, maintenance and future changes. Owning source code does not remove dependence on people and infrastructure. Agree how code, documentation and account access will be handed over before the build begins.

A comparison you can use in a supplier meeting

Scroll the table sideways to compare the options.

For each required task, record “works”, “needs configuration”, “needs extra development” or “unsupported”. Add the cost and who confirmed the answer. Leave unverified possibilities as open questions. Do not simply total the features: one missing critical exception can outweigh several useful reports.

Connecting systems may be enough

A small application can support operational work while an existing system continues handling finance. For example, office and workshop users could check job completeness in one place while invoices remain in the accounting tool. This is a possible design, not a promise of compatibility with every ERP.

Before pricing the connection, establish where each piece of information originates, where it can be changed and whether the supplier supports the required data exchange. Decide whether transfer is one-way or two-way. Describe what happens when a connection fails or the same record arrives twice.

If a direct connection is unavailable, a controlled file import may be sufficient. Include its delay and the work needed to check the result. “Integration included” is too vague to tell you what will actually happen. The brigdev service overview shows the areas that can be considered together.

Compare costs over the same period

Choose a common period, such as two years, for your own calculation. That is a comparison horizon, not an expected payback period. Include:

1. Planning, setup or development, testing and moving existing data.
2. Licences, hosting, support and maintaining connections.
3. Staff time for data checks, training and acceptance.
4. Likely changes in users, screens and scope.
5. Exporting data and handing the system to another supplier if necessary.

Mark confirmed quotes separately from assumptions. Ask which limits apply and what is priced separately. The custom application cost guide explains how to distinguish the build price from the wider commitment.

Agree what acceptance will look like

Describe a testable activity instead of writing “the system manages documents”. For example: an office user attaches a revised drawing to a job; an authorised worker sees the current drawing; an authorised supervisor can find the previous one. That gives each supplier a concrete task to address.

Also discuss backups, restoring work, updates and reporting problems. Separate a defect against the agreed scope from a request for a new feature. The proposed support arrangements should match how much the business depends on the system.

Make the first decision about the problem

Pick three tasks that cause the most difficulty. For each, provide an example, its frequency and the consequence of failure. Test the options with the people who will use them and record the unresolved questions.

If a spreadsheet is the starting point, read when replacing Excel makes sense. Then use the requirements brief to give suppliers the same information. Choosing the job to improve comes before choosing technology or a developer.