We use cookies to improve your experience. By continuing to use this site, you agree to our Privacy Policy.
We need a client portal" isn't a requirement. Define these 8 things before anyone writes any code.
Georgiana Nutas
-1-1600x900.webp)
Written by
Georgiana Nutas
Building modern web applications at BluDeskSoft. We write about what we learn along the way.
We'd love to chat about your project. First consultation is always free - no strings attached.
7 things you should control after your website launches. Check them now.
A surprising amount of software gets built from sentences like these:
"We need a client portal."
"We want a dashboard."
"We need something to replace Excel."
They're good starting points. They are not development requirements. Ask ten people on the team what "client portal" means, and you'll get ten different apps.
That gap is what a discovery phase is for. It doesn't mean months of workshops or an 80-page document nobody reads. It means removing the most expensive unknowns before they turn into code. A wrong assumption costs a few minutes to fix in a conversation and a few weeks to fix in a codebase.
Nielsen Norman Group describes discovery as the phase where a team investigates the problem, clarifies what needs solving, and gathers enough information to decide where to go next. Below are the eight things worth defining before development starts, what should come out of the process, and what you can safely leave to the technical team.
Discovery is the work of getting clear on seven things, roughly in this order:
Problem → Users → Workflows → Rules → Scope → Constraints → Success
Most projects take a shorter path by default: Idea → Features → Development. That path skips everything that makes a feature list buildable.
It helps to keep discovery separate from the two phases around it:
When discovery is skipped, design and development end up answering the first question by accident, one small decision at a time.
The goal is to reduce uncertainty, not to produce paperwork. If a document doesn't help someone make a decision, it doesn't belong here. Atlassian's guidance on product requirements follows the same logic: goals, assumptions, user stories, design, success metrics, and, just as importantly, what is explicitly out of scope.
"We need an app" describes a solution. A problem sounds more like this:
"Our operations team spends six hours every week consolidating orders from three spreadsheets, and errors happen because nobody knows which file is current."
The second version tells a developer what hurts, how often, and for whom. It also leaves room for a better answer than the one you walked in with. Sometimes a client asks for a dashboard when the real issue is a lack of a shared workflow. A dashboard on top of a broken process just displays the broken process more nicely.
The rule: describe the problem before you describe the solution.
A client portal looks like it has one type of user. After a few conversations, it usually has five:
Suddenly, permissions aren't a detail. They're part of the architecture. For each user type, write down:
People often forget the third question, and it often matters most.
Don't list screens. List journeys.
Create account → create company → invite team → create request → approve request → receive confirmation.
Or, for an internal tool:
Employee reports an issue → manager reviews → maintenance assigns → technician resolves → issue closes.
Screens come later. First, understand how work moves through the system, who hands it to whom, and where it sits waiting. The delays and errors you want to remove usually live in those handoffs.
Take a requirement that sounds finished: "Users can cancel a booking."
Now ask:
The happy path is usually easy to build. The rules around everything that can go wrong are where the complexity hides. Every answer becomes a rule, and every rule becomes code, tests, and maintenance. You don't need to settle every edge case in discovery, but you do need to know which requirements have them.
You don't need to design a database. You do need to understand what exists in the system.
In a CRM, that might be companies, users, contacts, deals, activities, and documents. Then come the relationships:
These sentences look simple, but they shape architecture, search, permissions, and reporting. The last one alone decides how data is separated across the whole product.
This is where hidden costs show up most often. Stripe, HubSpot, an ERP, accounting software, an email provider, Google Calendar, an existing database, an internal API.
"We need Stripe" isn't a requirement. What exactly should happen between the product and Stripe?
That's the difference between an integration that's mentioned in a brief and one that's understood. It's also worth finding out early who owns the other system and whether it has an API.
This isn't a debate about MVP theory. It's a scope boundary.
V1:
Later:
One of the most valuable outputs of discovery is often the list of things you've decided not to build yet. Atlassian recommends documenting out-of-scope items for the same reason: it keeps the team focused, and it gives you something to point to when a "quick addition" appears in week six. "Later" doesn't mean "never". It means not in this budget and not in this release.
"Launch the app" is a milestone, not a result. Better targets look like this:
Metrics keep helping after launch. When there are more ideas than time, you can ask which one moves the number you care about.
Not a 150-page document. A short set of answers:
Add wireframes for the highest-risk flows if they're needed. That's their job here: testing the parts most likely to be misunderstood, not drawing every screen before anyone has agreed on what the product does.
Usually four things, roughly in this order.
Developers fill the gaps with assumptions. Two developers can read the same sentence and build two different features. Neither of them is wrong.
Estimates become unreliable. Not because the developer can't estimate, but because the scope is still moving.
Scope creep appears halfway through. The client says, "Of course managers need approval permissions." The developer says, "That wasn't in the original scope." Both can be right, because nobody wrote it down.
You build the wrong workflow perfectly. This is the costliest one. The software is technically clean and solves the wrong problem, and you only find out when real people start using it.
There's no honest fixed answer. Discovery should be proportional to uncertainty, not to project price.
A simple internal tool may need only a few focused sessions. A multi-role SaaS platform with payments, integrations, permissions, and complex workflows needs significantly more. A small project can be full of unknowns, and a large one can be very well defined.
If what you're planning is a marketing website rather than an application, our guide on how to write a website brief is a better starting point.
Founders sometimes read an article like this and think, "Great, now I need to choose a database before I can talk to an agency."
You don't. You don't need to know:
You need to know your business and your problem. The technical team should help turn that understanding into a technical solution. You bring the domain knowledge, they bring the technical judgment, and discovery is where the two meet.
☐ What problem are we solving?
☐ Who are the users?
☐ What can each role do?
☐ What are the main workflows?
☐ Which business rules affect those workflows?
☐ What data needs to exist?
☐ Which external systems need to connect?
☐ What belongs in V1?
☐ What is explicitly out of scope?
☐ What would make the launch successful?
☐ What assumptions still need validation?
Starting development with unanswered questions is normal. Starting with unanswered questions you haven't identified is the expensive part.
If you're planning a custom application, discovery is where "we need a platform" becomes something a product and development team can actually build. BluDeskSoft can help map the users, workflows, requirements, and technical constraints before development begins. You can read more about our custom web application development or discuss your web app project.
BluDeskSoft-800x450.webp)
