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

A US eyewear wholesaler estimated that a tailored ERP and AI-assisted reporting workflow gave its team about 10 hours back each week. We should be careful with that number: it was the client’s estimate, not a time study, and we don’t have public detail about the steps underneath it. Nevertheless, it tells us something more useful than a long feature list. There was recurring work, the team could feel its cost each week, and the new workflow changed it enough for the difference to be noticed.

That’s the level at which we’d decide whether custom software is worth owning. A dashboard request is less useful than knowing which piece of work keeps consuming time and why process changes, configuration, or integration haven’t removed the constraint. Sometimes, however, an existing product will still be the right answer, because custom software earns its place only when the remaining problem is specific and valuable enough (and when the business is ready to own what it builds).

Start with the work, not a tour of features

Build-versus-buy conversations often begin inside a product comparison, with the team checking whether a tool supports its fields, includes the dashboard, or can send the notification. Those questions become useful later, but asked first they detach the software from the work it’s meant to change.

Instead, we’d take one order, report, customer request, lead, or case and follow it from the event that created the work until somebody could honestly say it was done. We want to see who touched it, where it waited, what was copied, what required judgment, and what happened when the information was wrong (details that tend to vanish from a product comparison).

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. It asks teams to challenge a proposed solution, restate it as a problem, understand the wider journey, and consider the value of solving it before they build. The guidance was written for public services, but the discipline applies just as well to an SME replacing a weekly report, and the full discovery guide is unusually practical.

Software requirements aren’t, however, sitting intact in somebody’s head, waiting for us to collect them. Researchers Daniela Zowghi and Chad Coulin describe the work as seeking, uncovering, acquiring, and elaborating requirements. Put more plainly, the requirement develops as we inspect the work and challenge our first explanation of it. Their survey of elicitation methods is old, but the distinction remains useful.

What the eyewear result can and can’t tell us

The public facts about the wholesale project are deliberately limited. Notus’s founder worked on it through a previous agency, the client remains anonymous, and the system included a tailored ERP with AI-assisted reporting. We don’t publish the underlying steps, the project cost, an adoption timeline, or an instrumented time study.

Therefore, the ten-hour figure can’t tell another wholesaler what to build, nor should it be presented as a laboratory result. It can tell us why the investment was legible inside that business: the work recurred, its value could be expressed as time returned each week, and somebody close to the work could judge whether the reporting outcome was useful. Moreover, the system addressed the operational workflow alongside the reporting (not an isolated AI demonstration placed on top).

“Use AI” would have been a technology brief. Time returned to the team was an operating outcome, although in this case it remains a client estimate with all the qualifications above.

Nevertheless, that limited result is still more useful for this decision than an unsupported industry average, because it stays attached to work somebody inside the company could recognize.

Try to avoid the custom build

Once we’ve followed the work, we therefore try the cheaper explanations first. Perhaps nothing should change yet because the task happens rarely, the process is still moving every week, or nobody owns the outcome. A new interface won’t repair missing ownership, because it will simply make the ambiguity cost more (and may hide it behind cleaner screens).

An existing product may already handle the important part. Standard capabilities should usually remain standard. Payroll, accounting, document signing, and video calls benefit from products whose security and maintenance costs are spread across many customers, so a local preference doesn’t automatically become a strategic requirement (even when the preference is perfectly reasonable).

Or perhaps each existing tool is fine while the handoff between them is expensive. Somebody still exports data, renames columns, uploads it elsewhere, and sends a message to say it’s ready. A small integration may remove that repeated work without replacing either system, which is often a far better bargain.

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

Only after those possibilities fail does the custom part become clear: the important workflow doesn’t fit cleanly, the workaround keeps returning, and the business is willing to own a changed way of working. “Build the bottleneck” is a useful phrase only if we’ve actually found the bottleneck (and recorded why a configured product or a small connection won’t remove it).

This isn’t a ritual that forces every project through four gates. If the work is a customer-facing product that doesn’t exist yet, building may be the first serious option. We simply want a specific reason that the cheaper alternative fails the workflow, instead of using “custom” as a synonym for “better.”

Use local evidence instead of an industry ROI number

Generic claims about the return from custom software are nearly useless for this decision. Therefore, the honest inputs are local, so for the work item we’ve traced, we’d fill in what can be observed and leave the rest blank.

Ranges are better than decorative precision (particularly when the baseline is based on a small sample). Time should be valued at the real cost of the people doing the work, and new revenue should be treated as expected gross margin rather than headline sales. Migration and training belong in the cost because software doesn’t teleport into normal use on launch day.

When the case only works with every assumption set to its optimistic edge, however, the first release is probably too large. We’d narrow the workflow or leave it alone.

If AI belongs, put it somewhere checkable

Fixed calculations, permissions, and known rules belong in ordinary code. AI becomes useful when a step contains unstructured information, language, or judgment: extracting details from a document, drafting an explanation, classifying an unusual request, or helping somebody inspect a report.

We then decide how the result will be checked. A model may draft a management summary while the numbers underneath continue to come from a controlled source, or it may suggest a category while a rule or person approves any high-impact action. If nobody can describe what a good output looks like, however, adding an agent won’t make the requirement clearer (it may only make the uncertainty harder to inspect).

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 person who will own the changed work

A custom system needs technical ownership and business ownership, which are related but not interchangeable. Deployments, monitoring, backups, access, security updates, model or API changes, and incident response sit on the technical side. The workflow owner decides which exceptions matter, who may change a rule, how success will be measured, and whether the team is using the system as intended.

A supplier can carry much of the first responsibility but can’t, however, permanently outsource the second. Before building, we’d name the workflow owner and agree on a small number of measures tied to the original problem, while after launch that person needs enough authority to review real exceptions and decide whether a change belongs in the software, the process, or both (because the workflow won’t remain fixed just because its first version has shipped).

Furthermore, the owner has to be close enough to the work to notice when the original assumptions no longer hold; otherwise a well-maintained system can preserve an outdated process perfectly.

Without that ownership, the application can launch while the old spreadsheet remains the unofficial source of truth. The project is technically live and operationally optional, which is an expensive way to discover that nobody was responsible for changing the work.

Where this advice stops

Following one work item is a good starting point for an SME operational system. It isn’t a complete method for a regulated clinical product, safety-critical software, or a platform with many independent user groups, because those systems need deeper research, security, compliance, and assurance.

Nevertheless, not every valuable workflow deserves a build. An existing product may ask the team to give up a few preferences while providing reliability that would be unreasonable to recreate alone. For standard work, accepting that constraint is often the better engineering decision and the better business decision too.