Custom Software Does Not Have to Mean Starting From Nothing

Custom software should reflect the work that makes a business distinct. It need not rebuild every ordinary capability from the beginning. Accounts, permissions, record handling, notifications, and common page patterns can often come from an established foundation. The important question is whether reuse frees the team to solve your real business problem while leaving the result understandable and adaptable.

Identify where the business needs a tailored answer

Write down the workflow that standard products handle poorly. Perhaps a service business has unusual approval steps, or a distributor coordinates orders across locations in a particular way. Describe the people, decisions, and exceptions, not just the screens you imagine. Then separate common supporting functions. A login form may be essential, but its uniqueness is unlikely to win customers or help staff deliver better work.

The GOV.UK standard on common components and patterns recommends reusing established solutions for recurring problems. Although it governs public services, the principle helps an SME ask how much project time is being spent on genuinely distinctive work. Reuse can be sensible without turning the whole product into a generic template.

Ask what is already available and who maintains it

An existing capability still needs to be configured and tested against your rules. Staff roles must reflect who can see a customer record or approve a change. Notifications must be triggered by the right event and written in language customers understand. Ask the developer which parts are reused, how they are maintained, and how a change to the shared foundation is checked against your application. Reuse is valuable when it has ownership, tests, and a clear boundary.

Avoid assuming that a ready-made component guarantees a lower bill or a faster launch. It may need adaptation, and some customer requirements do not fit it well. Ask for a project estimate that distinguishes foundation work, tailoring, data transfer, and testing. Compare the full delivery and operating costs, not a claim about the number of reusable parts.

Ask to see a working example of a common capability where possible. A developer can show how a new staff member receives access or how a customer notification is generated. This makes reuse concrete and gives the owner a chance to catch a mismatch with the business's rules. A polished demo is not proof of every future scenario, so include an awkward case and ask what would need tailoring.

Preserve room for change

Custom work should be placed where future changes can be made without disturbing unrelated capabilities. Ask how a new staff role, changed approval rule, or second location would be handled. A developer should be able to explain the likely effort in business terms and identify where assumptions remain. The GOV.UK guide to choosing technology highlights the importance of adapting as user needs become clearer and considering total ownership cost.

Start with a narrow useful release and learn from staff or customers. A reusable foundation can make it easier to deliver common functions, but it does not tell you whether the particular workflow is right. Test the whole task, including exceptions and the handoffs around it. Record what is configured, what is custom, and who can change each part later. This keeps a future provider from having to rediscover the original decisions.

Holism uses a Software Product Line foundation alongside AI-assisted development and an experienced developer. The foundation supports common capabilities; the developer judges where tailoring is needed and remains accountable for the product. The owner contributes goals and domain knowledge. Custom software is most useful when the business pays for a solution to its distinctive work rather than repeated invention of ordinary functions.