When custom software is worth it: follow the work, not the feature list

A US eyewear wholesale business estimated that a tailored ERP and AI-reporting workflow returned about 10 hours each week. The interesting part is not that the project used AI. It is that a recurring piece of work was costly enough, clear enough, and important enough to deserve a system built around it.

Custom software is worth considering when one recurring piece of work is valuable enough to change and the constraint survives cheaper options such as process changes, configuration, and integration.

A feature list starts too late

The usual build-versus-buy conversation begins with features. Can a product support these fields? Does it have this dashboard? Can it send this notification?

Those questions become useful after the workflow is understood. Asked first, they detach the software from the work it is supposed to change.

Start instead with one order, report, customer request, lead, or case. Follow it from the event that creates the work to the point where someone can say it is done. Note who touches it, where it waits, what is copied, which decisions require judgment, and what happens when the information is wrong.

Our software discovery guide turns that trace into a one-page starting artifact and shows what a useful discovery can produce besides a backlog.

The UK Government Digital Service gives similar advice for service discovery: interrogate a proposed solution, reframe it as a problem, understand the wider journey, and quantify the value of solving it before building. Its guidance is written for public services, but the discipline applies just as well to an SME replacing a weekly report. The full discovery guide is unusually practical.

Software requirements are not sitting in somebody’s head waiting to be collected. Requirements engineering researchers Daniela Zowghi and Chad Coulin describe elicitation as seeking, uncovering, acquiring, and elaborating requirements. In plain English: the requirements emerge as we inspect the work and challenge our first explanation of it. Their survey of elicitation methods is old, but that distinction remains useful.

The eyewear project tells us enough, and not everything

The public facts of the wholesale project are deliberately limited. Notus’s founder worked on it through a previous agency. The client is anonymous. The project included a tailored ERP and AI-assisted reporting, and the client estimated roughly 10 hours returned each week.

We do not publish the underlying steps, project cost, or an instrumented time study. That means the 10-hour figure should be read as the client’s estimate, not a laboratory result. It also means the case cannot tell another wholesaler what to build.

It can tell us what evidence made the investment legible:

• there was recurring operational work rather than a one-off annoyance;
• the value could be expressed as time returned each week;
• the solution covered the operational system and the reporting outcome, not an isolated AI demo;
• somebody inside the business could judge whether the report was useful.

The business case was about a changed operating outcome. “Use AI” would have been a technology brief, not a result.

Reject the cheaper options with evidence

Following the work usually produces four possible interventions. They should be tested from the least structurally expensive to the most.

Change nothing yet. Some tasks happen too rarely to justify software. Some processes are still moving every week. If nobody owns the outcome, a new interface will make the lack of ownership more expensive, not less.

Configure an existing product. Standard capabilities should usually stay standard. Payroll, accounting, document signing, and video calls benefit from products whose maintenance and security costs are shared across many customers. A local preference is not automatically a strategic requirement.

Connect the systems. Sometimes each tool is adequate and the damage happens between them. A person exports data, changes the column names, uploads it elsewhere, and sends a message to say it is ready. An integration may remove the handoff without replacing either system.

A spreadsheet deserves the same diagnosis. The grid may be innocent while ownership and handoffs are the real constraint.

Build the constrained part. A custom system becomes plausible when the important workflow does not fit cleanly, the workaround repeats, and the business can own the changed way of working. “Build the bottleneck” is a useful internal phrase, provided we have actually found the bottleneck.

This order is not a ritual. If the work is a customer-facing product that does not exist yet, a build may be the first serious option. Record why each rejected alternative fails the workflow rather than using “custom” as a synonym for “better.”

Use a worksheet, not an industry ROI statistic

Generic claims about the return from custom software are nearly useless. The honest inputs are local. For the work item you traced, fill in what you can observe and leave the rest blank.

Ranges are better than decorative precision. Value time at the real cost of the people doing the work. Treat new revenue as expected gross margin, not headline sales. Include migration and training; the software does not teleport into normal use on launch day.

If the case works only when every assumption is optimistic, the first release is probably too large. Narrow the workflow or leave it alone.

Put AI inside a step that can be checked

Use ordinary code for fixed calculations, permissions, and rules. Use AI where the input is unstructured or where language and judgment are part of the task: extracting information from a document, drafting an explanation, classifying an unusual request, or helping a person inspect a report.

Then decide how the result will be checked. A model can draft a management summary; the numbers underneath should still come from a controlled source. It can suggest a category; a rule or a person can approve a high-impact action. If nobody can describe a good output, adding an agent will not make the requirement clearer.

The architecture should match the step: rules for knowable answers, bounded model calls for language work, and autonomy only where the path is genuinely open.

The wholesale outcome was time returned through an ERP and reporting workflow. It was not “an AI transformation” measured by the number of model calls.

Name the workflow owner before the build

A custom system needs two kinds of ownership.

Technical ownership covers deployments, monitoring, backups, access, security updates, model or API changes, and incident response. Business ownership covers the workflow: which exceptions matter, who can change a rule, how success is measured, and whether the team is using the system as intended.

A supplier can carry much of the first responsibility. It cannot permanently outsource the second.

Name the workflow owner before the build. Give that person a small set of measures connected to the original problem. Review real exceptions after launch. When the workflow changes, decide whether the software, the process, or both should change.

Without that authority, the software can launch while the old spreadsheet remains the unofficial source of truth. The project is technically live and operationally optional.

Where this advice stops

Following one work item is a strong starting point for an SME operational system. It is not a full method for a regulated clinical product, safety-critical software, or a platform with many independent user groups. Those systems need deeper research, security, compliance, and assurance.

Nor does every valuable workflow deserve a build. An existing product may ask the team to change a few preferences while providing reliability that would be unreasonable to reproduce. For standard work, accepting that constraint is often the better engineering and business decision.