Project Planning Guide
Planning a web or app project step by step
Most project problems start before any code is written. Scope is vague, decisions are unmade, and everyone assumes someone else has it covered. This guide walks through the early stages in plain steps: discovery, wireframes, MVP scope, and timelines.
The cost of a vague brief
Why planning pays off
A week of planning can save months of rework. When requirements are written down and agreed, developers build the right thing and clients know what to expect. When they are not, every meeting turns into a negotiation about what was actually promised. Planning is not bureaucracy. It is the cheapest part of the project.
The pattern repeats across industries: a business asks for a mobile app, the brief arrives as a paragraph, and three months later the delivered product solves a slightly different problem. Writing the requirements down does not slow the work. It moves the difficult conversation to a stage where changing direction is still affordable.
- Agreed requirements give the build one shared definition of done.
- Written scope turns arguments about memory into decisions about content.
- Planning hours cost a fraction of the development hours they protect.
Planning stage · Scope, decisions and written requirements
Discovery stage
Where the team maps the problem before anyone proposes a solution. Workshops, research, and a review of what already exists.
Discovery: the first stage
Discovery is where the team maps the problem before proposing a solution. It usually involves workshops, user research, and a review of what already exists. Tools like Miro are common here, because they let people sketch flows and journeys on a shared board. The output is a clear picture of what the product needs to do and for whom.
A discovery phase can run as a short series of sessions or a few weeks of interviews, depending on how much is already known. What matters is the sequence: understand the problem, then the people affected by it, and only then the feature list. Skipping ahead to features usually means rebuilding them later.
Problem
What the business is trying to fix, in one or two sentences everyone accepts.
People
Who uses the product, what they do today, and where the current process fails them.
Constraints
Systems the product must connect to, and the rules it must operate within.
Discovery output
What discovery should produce
A written problem statement. A list of users and their needs. A rough feature list, sorted into must-have and nice-to-have. Any technical constraints, such as integrations with existing systems. If a discovery phase ends without these, it has not finished.
A problem statement
One page, agreed by the people who can approve the work.
Users and needs
Who the product serves, and what each group actually does with it.
A rough feature list
Sorted early into must-have and nice-to-have, before anyone estimates it.
Technical constraints
Integrations with existing systems, and anything the product must not break.
Sketching structure before visual design
Discovery · Problem, people, features and constraints
Wireframes: structure before style
A wireframe is a low-detail sketch of a screen or flow. It shows what goes where, without colours or final visuals. Wireframes are cheap to change, which is the whole point. They surface disagreements about structure early, before design work makes those changes expensive. A wireframe is not a design, and treating it as one causes confusion.
The value shows up in the arguments they prevent. Two people can look at a grey box and disagree about whether a search field belongs on the first screen; that conversation costs an hour. The same disagreement discovered after visual design and front-end work costs considerably more.
Wireframe stage
Review wireframes with the people who will approve the build. Agree on what each screen does before visual design starts, and keep the sketches on file as the reference for later scope questions.
Scope decision
Defining an MVP
An MVP, or minimum viable product, is the smallest version that delivers real value. It is not a half-finished product. It is a deliberate scope decision: what must be there at launch, and what can wait. Getting this wrong in either direction hurts. Too much scope delays launch; too little means the product does not do its job.
A useful test is to describe the launch version in one sentence a customer would recognise. If the sentence needs three clauses and a list, the scope is still too wide for a first release.
Feature sort
Sorting features
A simple method: list every feature, then mark each one as must-have, should-have, or later. Must-haves are what the product cannot launch without. Should-haves are valuable but not blocking. Later is everything else. This list becomes the reference point when scope pressure arrives, which it will.
Must-have
The product does not work without it.
Should-have
Worth building, but not blocking launch.
Later
Real ideas that wait for a future release.
MVP scope · What ships at launch and what waits
Delivery planning
Timelines and stages
A typical project moves through discovery, design, development, testing, and launch. Each stage depends on the one before it, and feedback delays compound. Timelines are estimates, not promises, and they change when scope changes. The useful question is not how long will it take but what has to be true for this stage to finish.
-
Discovery
The problem statement, users, and feature list are agreed and written down.
-
Design
Wireframes settle structure, then visual design and UI/UX detail follow the approved flows.
-
Development
Web development and mobile app development run against the fixed MVP scope, with the feature list as the reference.
-
Testing
Each agreed requirement gets checked before launch, and defects are triaged by impact.
-
Launch
The build goes live with the support terms already agreed, not negotiated after something breaks.
Stages depend on each other · Feedback delays compound
Content planning
Content and CMS decisions
If the site or app has content, decide early how it will be managed. A CMS lets non-technical staff update pages without a developer. Choosing one late means rework, and choosing one that does not fit the content type causes ongoing friction. This decision belongs in planning, not after launch.
Start by listing what will actually be published: product pages, articles, listings, help articles, or a mix. Then ask who edits them and how often. A CMS that fits the content model keeps editing simple for years; one that does not turns every small update into a developer request.
Approvals
Who owns what
Decide who approves design, who signs off on scope, and who is the day-to-day contact. Projects stall when no one is sure who can say yes. Write the names down. It sounds obvious, and it is the thing most often skipped.
- One named design approver, so feedback has a single route.
- One named scope owner, who can settle must-have versus later.
- One day-to-day contact for questions between review meetings.
After launch
Handover and support
Plan for what happens after launch. Who maintains the build, who fixes bugs, and how are updates requested? Support terms should be agreed before the project ends, not after something breaks. A build without a support plan is a build that ages badly.
Agree how requests arrive, how quickly routine changes are handled, and what counts as a bug rather than a new feature. When those lines are written down, both sides know what to expect from the first week onward.
Before development starts
A planning checklist
If any line is missing, that is the next conversation. Run through the list with the people who will approve the work, and record what is still open.
- Problem statement written and agreed
- Users and their needs listed
- Features sorted into must-have and later
- Wireframes reviewed and agreed
- MVP scope fixed and written down
- Timeline with named stages
- Content approach and CMS decision made
- Owners named for design, scope and contact
- Support terms agreed before the build ends
Common questions
Planning questions, answered
Short answers to the questions that come up most often at the start of a project.
How long does a typical website or mobile app project take?
It varies with scope, integrations, and how fast feedback happens. A simple site can move quickly; a custom app with integrations takes longer. The planning stage is where a realistic estimate gets built.
Do I need a wireframe before design?
Yes, in most cases. Wireframes settle structure and flow before visual design makes changes expensive. Skipping them tends to push those decisions into development.
What if I do not know what I want yet?
That is what discovery is for. It turns a rough idea into a defined problem and a feature list. You do not need answers at the start, but you do need to make the decisions discovery surfaces.
Where to go next
The planning steps above are the same ones used to scope real builds. If you want to compare how those builds are approached, or check what happens after launch, the guides below cover both in the same plain register.
Questions about a specific project can go to the contact page. ViewBinary Digital answers enquiries Monday to Friday, 9:00 AM – 6:00 PM.