Contents
Most custom software projects begin with a list of features. A dashboard. A customer portal. An approval workflow. An integration with the accounting system.
That list feels productive because it gives everyone something to point at. It is also one of the easiest ways to build the wrong thing with confidence.
The better starting point is a decision.
What does somebody on your team repeatedly have to decide? Which information do they hunt for first? What gets delayed because nobody knows who owns the next move? Where does a small mistake turn into an expensive correction three days later?
Software earns its keep when it helps a person make one of those decisions with less uncertainty.
A feature is not a problem statement
“We need a customer dashboard” is a feature request.
“Our account managers cannot tell which customers need attention before the weekly meeting” is a business problem.
Those statements may lead to the same interface. They may not. The second one leaves room for a report, a notification, a better data model, or a small change to the meeting itself. The first one assumes the answer before anyone has described the problem.
This is why a project can launch with every promised screen and still disappoint people. The screens exist, but the decision that justified them is still slow, unclear, or dependent on a spreadsheet someone maintains by hand.
The first question for a custom software project should be: “What decision should become easier?”
Describe the decision precisely
A useful decision has four parts:
- Who makes it?
- What triggers it?
- What information is available at that moment?
- What happens if the decision is late or wrong?
Take a common example: deciding whether to follow up with a sales lead.
The owner might be a salesperson. The trigger might be a new inquiry or a quote that has gone unanswered. The available information might include the service requested, the last contact, and the next promised step. The consequence of delay might be a lost opportunity or a customer who assumes the company is disorganized.
Now the software conversation has somewhere to go. It may need a queue, a clear owner, a reminder, a short history, and a way to record the next action. It probably does not need a twelve-screen sales platform on the first release.
That distinction protects the project from feature inflation. Every proposed feature has to answer a simple question: does this help someone make the target decision, or does it merely make the product feel more complete?
Find the expensive hesitation
The most valuable workflow is not always the one people perform most often. It is often the one where hesitation is expensive.
An employee may enter invoices all day without much trouble. They may spend only ten minutes deciding whether an invoice is suspicious, but those ten minutes can block payment, create duplicate work, or hide a larger problem.
Look for moments like these:
- A request sits in an inbox because nobody knows who owns it.
- A quote waits for approval because the decision-maker cannot see the margin.
- A customer gets a different answer depending on which employee responds.
- A manager asks for the same report every Monday because the underlying data is scattered.
- A handoff fails because the next person cannot see what was promised.
These are not abstract “efficiency” problems. They are visible points where information, ownership, and timing stop lining up.
Good software makes that misalignment harder to ignore and easier to correct.
Build the smallest useful loop
Once you know the decision, design the smallest loop around it:
- Capture the trigger.
- Put the decision in front of the right person.
- Show only the information needed now.
- Record the choice and its next action.
- Make the result visible to whoever depends on it.
That loop may become a custom application. It may begin as an internal tool. It may connect an existing CRM to a system your team already uses. The technology should follow the shape of the decision.
This is also where a prototype earns its place. A prototype should not be a decorative preview of every planned feature. It should test whether the proposed workflow gives a real person enough confidence to act.
If the user still needs to open four other tools, ask a coworker for context, and keep a private note beside the new screen, the prototype has found a problem. That is useful progress.
Keep the source of truth obvious
Custom software becomes fragile when nobody can answer where a value came from.
If a status appears in three systems, which one controls it? If a customer changes an address, which record updates first? If an approval is reversed, where is that decision recorded?
These questions are less glamorous than a polished dashboard, but they determine whether the system can be trusted. The integration design guidance from Microsoft makes the same underlying point from a different angle: systems need clear boundaries and explicit movement of information when events cross those boundaries.
You do not need a complicated architecture for every internal workflow. You do need to decide which system owns which fact before you connect five systems together.
The brief should make tradeoffs visible
A good software brief is allowed to say no.
It should name the decision, the people involved, the current failure, the smallest useful loop, and the things the first release will deliberately leave out.
That last part matters. A project that tries to satisfy every department at once usually produces a system that nobody fully trusts. A narrower first release gives the team a chance to learn which assumptions were wrong while the cost of changing direction is still reasonable.
At Pixelworx, this is the work we do before turning a workflow into custom software or moving a tested idea from prototype to production. The code matters. So does choosing the right decision to support.
Start there. The feature list will be much easier to write afterward.
