What Does a Discovery Phase Look Like in Software Development?.
Discovery is the single most valuable phase of any software project — and the one most likely to save you from building the wrong thing.
You have a product idea. You've found a development partner. You're ready to start building. And then they say something that catches you off guard: "Let's start with a discovery phase."
If you've never been through this before, it sounds like a delay. Another meeting before the meetings. A billable preamble before the real work begins.
It's not. Discovery is the single most valuable phase of any software project — and the one most likely to save you from building the wrong thing.
What discovery actually is.
A discovery phase is a structured period — typically one to three weeks — at the start of a software project where the team works to understand the problem deeply before writing any production code.
The goal is not to produce a specification document that collects dust. The goal is to answer three questions with enough clarity that every subsequent decision becomes easier:
- What are we building, and why?
- For whom, and what does success look like for them?
- What is the fastest path to delivering real value?
Discovery turns vague ideas into buildable plans. It turns assumptions into validated decisions. And it turns a budget into a timeline that everyone — founders, designers, developers — can actually trust.
Why skipping discovery costs more than doing it.
The math is simple but often ignored.
A discovery phase for a typical MVP costs one to three weeks of a team's time. Skipping it and building the wrong feature costs four to eight weeks of wasted development, plus the time to tear it out and rebuild.
We've seen this pattern dozens of times. A founder comes to us after spending three months and €40,000 with another team, with a product that technically works but doesn't solve the problem they set out to solve. The issue is almost never bad engineering. It's that nobody stopped to ask the right questions before the engineering started.
Discovery doesn't slow you down. It's the fastest way to eliminate the work you don't need to do.
What happens during discovery.
Every team runs discovery slightly differently, but the structure follows a consistent arc: understand, define, plan. Here's what that looks like in practice.
Week 1: Understand the problem.
The first few days are about listening. The development team needs to understand your business, your users, and the problem you're trying to solve — at a level of detail that most initial conversations don't reach.
Stakeholder interviews. These are structured conversations with the people closest to the problem: founders, domain experts, customer-facing team members, and — ideally — actual users. The questions are specific and often uncomfortable. Not "what do you want the product to do?" but "what are your users doing today without this product, and why is that painful?"
Competitive and market analysis. What exists already? Not just direct competitors, but adjacent solutions and workarounds your users currently rely on. Understanding what's already out there prevents you from building something the market already has — and reveals gaps you can exploit.
User research. In its simplest form, this means talking to five to ten potential users. Not surveying them. Talking to them. Watching them describe their workflow. Asking them to show you how they currently solve the problem. The insights from even a handful of these conversations are worth more than weeks of internal brainstorming.
The output of this week is a shared understanding of the problem space — documented, discussed, and agreed upon by everyone involved.
Week 2: Define the solution.
Now the team shifts from "what's the problem?" to "what's the smallest thing we can build that solves it?"
User personas and journeys. Based on the research, the team creates a small set of user profiles — not fictional marketing personas, but practical archetypes that represent distinct needs and behaviors. For each one, the team maps the journey: what brings them to the product, what they need to accomplish, and what "done" looks like.
Feature mapping and prioritization. Every feature idea gets captured, then ruthlessly prioritized. The framework we use at Nortis is simple: each feature is placed into one of three categories.
- Must have — the product doesn't work without it. These form the core of your MVP.
- Should have — important but not blocking. These go into the first post-launch iteration.
- Nice to have — desirable but unproven. These wait until user data tells you they matter.
The discipline here is saying "not now" to features you're emotionally attached to. The best products launch with fewer features than their founders wanted — and more clarity about why each one exists.
Technical feasibility. While the product side is being shaped, the engineering team is evaluating the technical landscape. What integrations are needed? What are the data model requirements? Are there API limitations from third-party services? Are there regulatory or compliance constraints?
This is where hidden complexity surfaces. A feature that sounds simple in a pitch deck — "users can sign documents electronically" — might involve e-signature API integration, compliance with eIDAS regulations, document versioning, and audit logging. Better to discover that now than in week six of development.
Week 3: Plan the build.
The final stretch translates everything into a concrete plan.
Wireframes and user flows. Low-fidelity sketches of every screen in the core user journey. These aren't about aesthetics — they're about logic. Does the flow make sense? Can a user accomplish their goal without confusion? Where are the decision points, error states, and edge cases?
Wireframes are fast to produce and — critically — fast to change. Rearranging boxes on a screen takes minutes. Rearranging a built interface takes days.
Technical architecture. The engineering team defines the tech stack, infrastructure approach, data model, and integration strategy. This includes decisions about authentication, hosting, CI/CD, and any third-party services the product depends on.
A good architecture document answers a specific question: if a new developer joined the project tomorrow, could they understand how the system is structured and why?
Backlog and timeline. Every feature from the prioritization exercise gets broken into development tasks, estimated, and sequenced into sprints. The result is a timeline with clear milestones — not a vague "it'll take about three months," but a week-by-week plan showing what gets built when.
Budget and resource plan. Based on the timeline, the team produces a cost estimate broken down by phase. This is where the investment in discovery pays for itself: instead of a rough guess based on a pitch deck, you get a number grounded in actual scope, actual complexity, and actual engineering assessment.
What you get at the end.
A good discovery phase produces a set of deliverables that serve as the foundation for everything that follows:
Problem statement — a clear, concise articulation of what you're solving and for whom. One paragraph, no jargon.
User personas and journey maps — the key user types, their goals, and the paths they take through your product.
Prioritized feature list — every feature categorized as must-have, should-have, or nice-to-have, with rationale for each decision.
Wireframes — screen-by-screen sketches of the core user flows, annotated with interaction notes and edge cases.
Technical architecture document — the system's structure, tech stack choices, integration points, and infrastructure plan.
Project timeline — a phased development plan with milestones, dependencies, and delivery dates.
Budget estimate — a detailed cost breakdown tied to the timeline, with clear assumptions stated.
These documents aren't bureaucratic overhead. They're the shared source of truth that keeps the entire team aligned throughout development. When a question arises mid-build — "should we add this feature?" or "can we change this flow?" — the discovery deliverables provide the context to answer it quickly and confidently.
What discovery is not.
A few common misconceptions worth addressing:
Discovery is not a sales tactic. Some agencies use "discovery" as a way to bill for the proposal process. Legitimate discovery produces tangible deliverables that you own and can take to any development team — even if you choose not to work with the team that ran the discovery.
Discovery is not a requirements document. A traditional requirements specification tries to define everything upfront. Discovery acknowledges that you can't know everything in advance. It defines enough to start building with confidence, while leaving room for learning and iteration once development begins.
Discovery is not design. Wireframes are part of discovery, but high-fidelity visual design is not. Discovery establishes what the product does and how it flows. Design — colors, typography, visual polish — comes after, informed by the wireframes and user insights from discovery.
Discovery is not optional for complex projects. For a simple landing page or marketing site, you don't need a formal discovery phase. For any product with user accounts, data persistence, business logic, or third-party integrations, discovery is not a luxury. It's a prerequisite for a successful build.
How long does it take and what does it cost?
For most startup MVPs and mid-size applications:
| Project complexity | Discovery duration | Typical cost |
|---|---|---|
| Simple MVP (single user type, core flow only) | 1 week | €2,000–€5,000 |
| Standard MVP (multiple user types, integrations) | 2 weeks | €5,000–€12,000 |
| Complex application (enterprise features, compliance) | 3–4 weeks | €10,000–€25,000 |
These numbers vary by team and region, but the ratio holds: discovery typically costs 10–15% of the total project budget and saves 20–40% in avoided rework.
If a development partner quotes you a fixed-price build without any discovery process, that should raise a flag. Either the scope is genuinely trivial, or they're planning to figure it out as they go — which means you're paying for their learning curve during development instead of during discovery.
How to get the most out of discovery.
If you're about to go through a discovery phase, here's how to make it count:
Come prepared, not polished. You don't need a perfect pitch deck. You need honest answers about your users, your market, and your constraints. The messier your thinking is at the start of discovery, the more valuable the process will be.
Bring the decision-maker. Discovery only works if the person who can say "yes, build that" or "no, cut that" is in the room. If every decision requires a chain of approvals after the session, the timeline stretches and the momentum dies.
Be willing to kill your darlings. You will hear "that feature should wait" more than once. That's not the team being difficult — it's the team protecting your budget and timeline. The features that get cut from v1 aren't gone. They're queued for when you have real user data to justify them.
Ask hard questions. A good development partner welcomes scrutiny. Ask them why they're recommending a particular technology. Ask what risks they see. Ask what would happen if the budget were halved. The quality of their answers tells you everything about whether this is the right team.
Treat the deliverables as living documents. The discovery outputs will evolve as development progresses and you learn from real users. They're not a contract — they're a starting point. The best teams update their wireframes and backlog continuously as new information emerges.
The honest truth about discovery.
Discovery isn't glamorous. There are no dramatic reveals or breakthrough moments. It's a series of structured conversations, careful thinking, and deliberate trade-offs that turn an ambiguous idea into a clear plan.
But here's what we've learned from building dozens of products: the projects that invest in discovery launch faster, cost less, and succeed more often than the ones that skip straight to code. Not sometimes. Every time.
The reason is simple. Writing code is fast. Writing the right code — code that solves the right problem, for the right user, in the right way — requires understanding. And understanding requires discovery.
Ready to start?
At Nortis, discovery is how every engagement begins. We'll help you define what to build, validate that it's worth building, and create a plan that respects your budget and timeline. If you have an idea that's ready for structure, we'd love to hear about it.