Custom software / Product architecture
How to plan a custom business system before writing code.
A practical framework for turning spreadsheets, messages and manual handoffs into a custom web system without automating the wrong process.
Many custom systems begin with the same sentence: 'We currently do this manually.' The temptation is to copy the current manual process screen by screen. That usually produces expensive software that preserves every historical workaround. A better first step is to understand the operation as a set of states, decisions, people and exceptions.
Trace one real job from start to finish
Do not begin with a feature list. Pick one real order, request, booking, client case or internal task and follow it from the moment it enters the business until it is complete. Write down every person who touches it, every place where information is copied, and every point where somebody has to ask what happens next.
This creates a much more useful map than 'we need a dashboard'. It shows where software can remove uncertainty and where a human decision is genuinely necessary.
Separate states from screens
A status is part of the business model. A screen is only one way of showing it. If a request can be new, reviewed, approved, in progress and complete, those states should be defined independently from whatever dashboard eventually displays them.
Once states are explicit, permissions, notifications and automation become easier to reason about. The team can discuss what may transition from one state to another before frontend details distract the conversation.
- What states can an item be in?
- Who can change each state?
- What information is required before a transition?
- What should happen automatically after a transition?
- What should happen when a transition fails?
Model the exceptions before the happy path looks finished
Real operations have duplicates, missing information, cancelled work, unavailable external services and people changing their mind. If the first specification only describes the perfect path, the difficult behavior gets invented under pressure during implementation.
A useful system does not need every theoretical edge case on day one, but it should make the important exceptions visible and recoverable instead of silently corrupting state.
Define the first version by operational value
An MVP is not simply fewer screens. It is the smallest release that creates a complete useful loop. If a customer can submit something but staff still have no reliable way to process it, the loop is incomplete even if the public interface looks finished.
The first release should normally make one workflow work end-to-end: input, validation, internal visibility, state changes and a clear completion condition. Secondary reporting and convenience automation can follow once real use reveals what matters.
Make ownership and production part of the plan
A business system is not complete when it works on a developer laptop. The plan should include deployment, credentials, backups, environment configuration, domain ownership, access, logs and who is responsible when something fails.
These details are not paperwork around the product. They are part of whether the company can actually rely on it.
TAKEAWAY
The strongest custom systems begin with an operational model, not a feature wishlist. Map one real workflow, define states and responsibility, identify failure cases, then build the smallest complete loop that makes the work easier to operate.