A new piece of software starts making promises before anyone writes the first line of code.
It will save time. It will connect the team. It will replace the spreadsheet, reduce duplication, give customers somewhere to go, and make a process that currently feels improvised look deliberate. Some of those promises may be true. Some may even justify the project.
But the software will ask for things too.
It will need somewhere to run and someone to understand that place. It will need credentials, updates, backups, documentation, monitoring, migration, and an answer to the question of who owns the problem when something fails. Dependencies will change. APIs will disappear. Passwords will expire. A certificate will fail to renew for reasons that seem personally targeted. Eventually someone will have to work out why the thing that has been sending emails without complaint for eighteen months has suddenly decided that this particular Tuesday is where it draws the line.
None of this is an argument against building software. It is an argument for counting honestly.
Software is usually described as an asset: a product, a tool, a capability, an advantage. That is only half the accounting. Every system also creates obligations, and those obligations begin the moment the system becomes important enough for somebody to depend on it.
So the first question should not be whether software can solve the problem.
Almost anything can be solved with enough software.
The better question is whether the problem is worth the software it creates.
The request is not yet the problem
Imagine a small team decides it needs a customer portal.
The request sounds reasonable. Customers need somewhere to log in, see their documents, check progress, send messages and perhaps approve the next step. Before long there are sketches of dashboards, conversations about authentication, permissions, branding, notifications, and whether the landing page should greet the customer by name.
This is often where software work begins.
It is usually too early.
“We need a portal” is not yet a description of the problem. It is a proposed answer to one.
Perhaps customers keep emailing because they cannot find documents they were already sent. Perhaps staff spend hours giving the same status updates. Perhaps approvals disappear into long email threads. Perhaps customers do not know who owns the next step. Perhaps the internal process is inconsistent enough that nobody can confidently explain what is happening at all.
Those are different problems, even if they all happen to produce the sentence “we need a portal.”
One might be solved by a shared document space. Another by automated status updates. Another by a better approval workflow. Another may require changing the internal process before exposing any of it to customers.
If the process itself is confused, a portal may simply give customers a beautifully designed view of the confusion.
Software is very good at formalising whatever it is given, including bad processes.
That is why a requested solution should be treated as evidence, not definition. It tells us that something hurts. It does not yet tell us where the pain lives.
The useful question is not:
What should the portal do?
It is:
What work are we actually trying to remove?
That difference is small in language and enormous in consequence.
Once the work is visible, the range of legitimate answers becomes wider. The answer may be custom software. It may be an existing product. It may be one narrow automation. It may be a change to an internal process. It may be doing almost nothing technically and fixing the part where six people are maintaining the same information in different places.
The point is not to prefer one category of answer.
The point is to avoid falling in love with the proposed solution before the problem has finished introducing itself.
Complexity moves
Suppose the team does the work properly and confirms that something really does need to change.
Now the familiar options appear: keep the process manual, buy something, adapt something already in use, or build a custom system.
There is a temptation to turn this into ideology.
Build versus buy. Custom versus commodity. SaaS versus local. Simple versus sophisticated. Engineers, being engineers, are perfectly capable of turning a practical trade-off into a small religious war by lunchtime.
Reality is less interested in the categories.
Every option removes some burden and creates another.
Keeping the work manual avoids software maintenance, but the organisation continues paying in labour, repetition, inconsistency and memory. Buying software removes most implementation work, but introduces subscription cost, vendor dependency, integration, migration and the product’s own assumptions about how the work should be done. Building custom software gives much greater control over the workflow, but now somebody owns a system.
Complexity rarely disappears.
It moves.
That is the more useful way to think about the decision. Do not compare code to no code. Compare the total burden carried by each option.
Take the portal again.
A custom system might remove three hours of repetitive status emails each week. That is real value. But if it also introduces authentication, account recovery, permissions, email delivery, infrastructure, security updates, backups, logging and support, then the meaningful comparison is not:
three hours of emails versus a portal.
It is:
the burden of the current process versus the burden of the system that replaces it.
The new burden may still be much smaller. If the team spends forty hours each month coordinating work manually, then owning a modest system that removes most of that effort may be an excellent trade.
The problem is not that software has costs.
The problem is that its costs often arrive later than its benefits.
A demo shows the customer logging in.
It does not show somebody upgrading a dependency eighteen months later because a vulnerability has appeared in a library nobody remembers choosing.
The prototype shows the approval screen.
It does not show the migration required when the accounting platform changes.
The proposal lists the features.
It rarely contains a slide titled Things Someone Will Be Responsible For Forever Unless We Deliberately Retire Them.
The demo is not lying.
It is simply showing the part of the system that photographs well.
Good engineering has to count the rest.
Build where the difference matters
None of this means custom software should be avoided.
It means custom software should earn its place.
There are plenty of situations where ordinary tools handle the work badly enough that owning the difference makes sense. A workflow may be unusually specific. Existing products may force unnecessary steps or fail to represent something important. Integration may matter more than any single feature. Control over data may be essential. Reliability may justify tighter ownership. The volume of repeated work may simply be large enough that removing it creates a clear operational advantage.
Those are good reasons to build.
“We could make the dashboard nicer” is weaker.
Custom software should encode a meaningful difference, not merely a preference for custom software.
That distinction matters because building software is seductive in a very particular way. A blank repository is clean. There are no inherited naming mistakes, no awkward settings pages, no third-party workflow assumptions. Every field can be called the right thing. Every screen can follow the actual process.
Then users arrive.
Users create expectations. Expectations create edge cases. Edge cases create support. The application accumulates data, and the data accumulates importance. Integrations appear. Permissions matter. Someone asks for one harmless exception. Someone else asks why that exception cannot become standard.
At some point, usually without ceremony, the thing stops being a project and becomes infrastructure.
That transition is what should be priced into the original decision.
The team considering the portal should therefore ask a harder question than whether a custom solution would be better.
It almost certainly could be better, given enough time and attention.
The real question is whether the difference is important enough to own.
If existing systems cannot represent a critical approval workflow without constant correction, perhaps the answer is yes.
If the main advantage is that a custom portal could use the company’s typography and place the logo seventeen pixels further left, perhaps civilisation can endure the compromise.
The bar is not technical possibility.
The bar is whether the advantage is worth the obligation.
Ownership is part of the deliverable
If the team does choose to build, then ownership has to mean more than paying for source code.
Can the data be exported?
Can another engineer understand the system without performing archaeology?
Can credentials and infrastructure be transferred?
Can a dependency be replaced?
Can the team tell when something has failed without calling the original developer?
Is there a recovery path?
Can the software survive the departure of the person who remembers how deployment really works?
These questions are often treated as maintenance concerns, as though the engineering is finished once the main behaviour works.
They are part of the engineering.
A system that works beautifully while its original developer remains present may be a successful implementation. A system that becomes opaque the moment that person leaves has not been fully handed over.
The same principle applies to data.
If customers upload documents, create records, approve work and build years of history inside the portal, then the ability to move that information matters. Not because migration is glamorous. Very little in computing becomes less glamorous as quickly as migration. It matters because systems change.
A hosting provider becomes unsuitable. A vendor disappears. The organisation grows. The architecture ages. A better system arrives. Or someone simply decides that the portal no longer deserves to exist.
That last case matters more than it usually gets credit for.
Software should be allowed to end.
A well-owned system does not have to be permanent. It has to be understandable enough that replacing or retiring it remains possible.
If leaving a system requires reconstructing years of state from undocumented tables and begging the one remaining engineer who vaguely remembers the import process, then ownership was never quite what everyone thought it was.
Real ownership includes the ability to change your mind.
The smallest complete solution
By this point, “build less” is too crude to be useful.
The goal is not less code at any cost.
The goal is less total burden for the people doing the work.
Sometimes that means building nothing. Sometimes it means configuring what already exists. Sometimes it means adding one narrow automation. Sometimes it means replacing the spreadsheet that became mission-critical infrastructure despite containing a tab called FINAL_v7_USE_THIS.
And sometimes it really does mean building the portal.
The engineering judgement lies in choosing the smallest intervention that solves the real problem without hiding the remaining work somewhere else.
That final condition is important.
A tiny application that forces somebody to reconcile three spreadsheets every Friday is not automatically simpler than a larger system that performs the reconciliation reliably. In the same way, a comprehensive platform that anticipates every possible future case is not necessarily more complete. It may simply create a much larger thing for the organisation to understand and maintain forever.
The smallest complete solution sits between those failures.
It removes enough work to justify its existence. It leaves the remaining work visible. It can survive ordinary failure. It can be understood, operated and handed over. It gives the organisation control over the things it has good reason to control.
And then it stops.
There will always be another feature available. Another integration. Another workflow that could be absorbed. Another abstraction that makes the architecture diagram look more impressive. Another service, queue, agent, registry or tasteful rectangle waiting to be added because somebody can imagine a future in which it might be useful.
That does not mean it belongs in the system.
Good engineering is not measured by how much software a problem can support.
It is measured by how much unnecessary burden the solution removes without creating a worse burden in its place.
So before building the portal, ask what problem it is actually solving. Ask what work disappears if it succeeds. Ask what obligations appear because it exists. Ask who will carry those obligations a year from now, when the launch meeting has been forgotten and the people who built the first version are working on something else.
Then ask whether the difference is worth owning.
Sometimes the answer will be yes.
Sometimes the right system will be much smaller than anyone expected.
And sometimes the best piece of software you can build is the one you decide nobody should have to maintain.