Choose a workflow you can watch someone complete
Imagine a small equipment rental business that wants a customer portal. The first feature list might include bookings, payments, messaging, inventory, contracts, reports, and a mobile app. The useful starting question is smaller: which task causes enough trouble today that someone will try a new way of doing it?
For this hypothetical business, the first promise could be: “A returning customer can request available equipment for a date range, and an operator can confirm the request.” That is still real software. It has users, information, decisions, and a clear finish. It also gives you a test: can a customer and operator complete the transaction without reverting to the spreadsheet halfway through?
Draw the whole path before adding more paths
Write each step as a change in state. A request starts as a draft, becomes submitted, and ends confirmed or declined. Decide who can make each transition and what information they need. Ask what happens if the customer closes the browser, the operator declines the dates, or the same request is submitted twice.
Those questions expose work that a screen list misses. “Dashboard, login, booking page” describes places, but it does not describe a functioning service. Build the smallest complete path first, including its ordinary failure states. A polished dashboard has limited value if the underlying request cannot reach a clear outcome. Use rough screens and sample records to review the path before paying for detailed visual design.
Reduce features without removing access rules
A first release can omit automated reporting, a custom theme editor, or a complicated loyalty program. It still needs an answer to who may see and change each record. In the rental example, a customer should see their own requests, while an operator may need a wider view. Write that down as a permissions table before development.
OWASP recommends denying access by default and checking permissions on every request. Hiding an admin button in the interface is not enough. Ask the developer to demonstrate that a customer cannot retrieve another customer’s record by changing a URL or request identifier. This is a concrete test of the product’s boundaries, and it belongs in the first release rather than an unspecified later security phase.
Reference: OWASP: Authorization cheat sheet (opens in a new tab)
Keep manual work deliberate and visible
An operator can manually confirm availability in an early release if that is an explicit part of the service. The interface should say a request awaits confirmation, and the business needs a place to review outstanding requests. Manual work becomes a problem when the customer sees “booked” while an unseen operator still has to make the booking possible.
List each manual step, its owner, and the information needed to perform it. Decide how someone notices a stuck request. You can learn from real use before automating every exception, but do not disguise an unfinished workflow as an automatic one. If the service cannot be delivered reliably with the planned manual work, reduce the promise again or include the missing operational tool.
Treat integrations as dependencies
A payment provider, calendar, email service, or inventory feed brings its own setup, access, and failure conditions. Name the exact service you plan to use and check its current documentation before estimating the integration. “Connect to our system” is not a priceable requirement if nobody knows whether that system has an API, an export, or only a browser interface.
For each integration, identify the account owner, the data exchanged, and what the user sees when it is unavailable. Ask for a test using the provider’s supported test environment or an approved real transaction. A developer should not have to invent a successful payment or message to make a demo look complete. Keep integration assumptions visible in the proposal and resolve the riskiest one early.
Buy evidence before buying the next feature
Give the first release a short acceptance script. A customer creates a request. An operator reviews it. The customer sees the decision. An unauthorized account cannot open it. A failed submission produces a useful error. The owner can retrieve the data and understands who handles support. Review those steps in the working product, not only in a design prototype.
Then observe a small number of intended users with their permission. Record where they hesitate, what they misunderstand, and which work still happens outside the product. These observations are more useful than a long wish list assembled before anyone has used it. Fund the next release around the most consequential gap. The first version earns its keep by teaching you what a complete, valuable workflow actually requires.
