Customised software development: 8 Decisions Before You Build

Customised software development means building an app around a business need that ready-made tools cannot meet well. The aim is to give staff a clear way to do their work, with the right rules, data, and links between systems. It makes sense when the cost of workarounds, errors, or missed work exceeds the cost of building and maintaining a better tool.

This article explains eight decisions to make before you build. It covers the business case, scope, user experience, system links, data, security, ownership, and ongoing support. You will also find a practical way to compare a custom build with a standard product.

When does customised software development make sense?

Start with a real process, rather than a list of screens. For example, a service firm may handle enquiries in one tool, assign jobs in a spreadsheet, and bill clients in another. Each handoff needs someone to copy details. A custom system can connect those steps, but only if the team first agrees on who owns each step.

However, a common need often has a good standard solution. Basic bookkeeping, shared email, and simple task lists rarely need a fresh build. Use those tools unless a clear constraint prevents them from doing the job. A unique workflow alone does not prove that you need custom software.

In practice, the strongest cases have specific gaps. These may include complex approval rules, several customer types, unusual pricing, or data that must move between older systems. Write down the gap and its effect. “We need a dashboard” is vague. “Dispatch needs to see overdue jobs by crew before the morning meeting” gives a developer a useful target.

1. Define the outcome and the baseline

Choose a small set of outcomes that staff can measure. For instance, track the time from enquiry to quote, the number of records staff enter twice, or the hours spent preparing a weekly report. Measure the current process before setting a target. Otherwise, you cannot tell whether the new system helped.

Next, find the source of the problem. A slow approval may reflect an absent manager, rather than poor software. A tool can send alerts and route work to a backup person. It cannot invent a policy or make an unclear business rule fair.

Build the business case from costs you can defend. Include staff time, the impact of errors, subscriptions you can retire, and support costs. Treat expected gains as estimates. Also include training, data cleanup, hosting, and future changes in the total cost.

A useful pilot might cover one branch and one job type. Compare its results with the baseline over a normal work cycle. As a result, you can decide whether to expand using evidence from your own work.

2. Set the scope around a complete workflow

A first release should solve a small process from start to finish. For example, let a coordinator create a job, assign a crew, record completion, and send approved details to billing. A wide system with half-finished steps forces staff back into email and spreadsheets.

Separate must-have rules from future ideas. A must-have item has a clear reason why the process fails without it. A future idea may add value but does not block the first useful release. Record both so that a good idea does not disappear simply because it waits.

In addition, define exceptions. What happens when a client cancels, a crew rejects a job, or a price changes after approval? These cases often reveal more than the normal path. Walk through several recent real jobs and include one that went wrong.

Write acceptance criteria in plain language. For instance: “A supervisor can approve a job cost, but cannot approve their own request.” This gives the team a rule it can test. IBM’s explanation of requirements management describes how teams record and manage such needs through the product lifecycle.

3. Design for the people doing the work

Ask staff to show their current routine. Watch where they search for facts, pause, or ask a colleague for help. A short observation can expose a missing field or a needless approval that a planning meeting misses.

Then test a simple prototype before writing the full app. A prototype can show the layout, key actions, and flow between pages. Give users a task without explaining where to click. Their mistakes reveal whether the screen makes sense.

Mobile use needs its own review. A technician on a phone needs large controls, quick photo uploads, and clear status changes. A finance user at a desk may need filters, bulk actions, and detailed exports. One screen should not force both roles through the same steps.

Meanwhile, consider access needs. Use readable labels, clear error messages, and keyboard-friendly forms. Avoid relying on colour alone to show a problem. These choices help users who work in bright light, use assistive tools, or have limited time.

Keep required fields to what the current step needs. If staff cannot know a value yet, let them save a draft with a clear missing-data status. Otherwise, they may enter false values just to move forward.

4. Decide which systems own each fact

Integration means that software exchanges data with another tool. It does not mean every system should edit every field. Choose one owner for each key fact. For example, the accounting system may own invoice balances, while the job system owns site notes.

Next, agree on the direction and timing of each exchange. A change may need to move at once, once an hour, or at the end of a day. The right choice depends on the work. Instant updates add complexity when a daily batch would suffice.

Plan for failed transfers too. Staff need to see the error, the affected record, and the next action. A system should retry safely without creating a second invoice or payment. Ask your developer to show what happens when the other service goes offline.

If customer details drives the workflow, our article on CRM concepts and cloud CRM basics can help you define which customer records belong in the system. Keep system links focused on useful outcomes, rather than connecting tools for their own sake.

5. Plan data cleanup and migration early

Moving old data often takes more work than moving code. Two spreadsheets may use different names for the same client. A date column may mix formats. Older records may lack the fields the new process needs.

First, list the sources and choose what to move. Active customers, open jobs, and unpaid invoices may matter more than every old attachment. Keep an archive when staff need history but do not need to edit it.

Next, map old fields to new fields and test the mapping on a small sample. Check record counts and selected values. Also compare totals that matter, such as open balances or stock quantities. A successful import message does not prove that the data is correct.

Decide who fixes uncertain records. The developer should flag duplicates and gaps, while the business owner decides which record is valid. Do not let a hidden merge rule erase useful history.

Finally, plan the cutover. Define when staff stop using the old tool, when you take the last export, and how you handle work that arrives during the move. A rollback plan should explain how to restore service if a critical check fails.

6. Make security part of the scope

Security starts with roles. Staff should see and change only the data their work needs. A sales user may create a quote, while a manager approves a discount. Check these rules on the server, rather than merely hiding a button.

In addition, define secure sign-in, session controls, backups, and change logs. Ask what the logs record and who can view them. A log that stores passwords or full sensitive documents creates a new problem.

The OWASP Application Security Verification Standard offers a basis for checking web app controls. Your team can use relevant checks to turn broad promises about security into testable requirements.

Test restoration as well as backup creation. A backup helps only if the team can recover the data and resume work. Set recovery goals based on the process: how much recent work can you lose, and how long can the system remain not available?

7. Clarify ownership, handover, and exit options

Before work starts, agree on access to source code, hosting accounts, databases, and third-party services. The contract should explain what you own, what the supplier licenses, and what ongoing payments cover. Resolve this before the system becomes essential.

However, source code alone is not a complete handover. You also need deployment steps, setup notes, database details, and a list of external services. Another developer should be able to run the system without relying on one person’s memory.

Ask for a data export in a usable format. Check whether it includes attachments, relationships, and history, rather than just a customer list. This protects your ability to change providers or rebuild later.

Choose a support arrangement with clear response expectations. Distinguish a critical outage from a small display issue and a new feature request. Each needs a different response, price, and process.

8. Budget for change after launch

Launch is the start of daily use. Real users will expose cases that a pilot did not cover. Keep a short feedback queue with a clear owner, priority, and reason for each request.

Meanwhile, plan routine work such as security updates, monitoring, database care, and dependency upgrades. These tasks protect the system even when no visible feature changes. Include them in the operating budget.

Review usage before adding features. If staff avoid a page, find out why. The answer may be a confusing label, slow load time, or data they do not trust. More features will not fix those causes.

For linked finance, stock, and operations workflows, custom ERP development may suit a broader scope. Still, expand in stages so that each release has a clear benefit and a stable owner.

Custom build, standard product, or a hybrid?

A standard product works well when its core process fits your needs. Configuration can change fields and workflows without creating a full app. As a result, you may reach a useful result sooner.

A custom build offers more control over unusual rules and the user experience. However, you also take on maintenance and product decisions. Compare full operating costs, rather than a setup fee against a subscription alone.

A hybrid approach often makes sense. Keep a standard accounting or messaging service and build the workflow that sets your business apart. This avoids recreating mature tools while giving staff one clear place to work.

Choose the smallest build that solves the real problem

Good customised software development begins with clear work rules and a measurable need. Define one complete workflow, test it with users, and plan data, security, ownership, and support before launch. Then expand based on results, rather than on a long wish list.