5 steps, 3 screen types, 1 build plan
5 steps move the work from your first message to a live product: requirements, design, development, review and support planning. The plan starts with what users must do, not with a feature list assembled without context.
A website, web application or mobile application can be the main product. A project can also connect these formats when users need more than one way to complete a task. Design and adaptation can cover desktop, mobile and tablet screens.
We first match product tasks to screens and workflows. Then we record which features belong in the agreed work. That includes AI integration, SEO setup, admin pages and maintenance. Your team gets clear points to review as the project moves forward.
For a wider view of our creative and development work, see the design and development studio. Bring your intended user tasks and existing materials to the first conversation. We use them to identify open questions before design begins.
Which build format fits the product?
3 common formats cover different user needs: a website, a web application and a mobile application. Pick the format by the task users need to complete and the screens that task requires.
| Format | What it supports | What to send |
|---|---|---|
| Website | Product pages and defined visitor actions | Page list, content and brand materials |
| Web application | Browser-based workflows and product features | User roles, tasks and business rules |
| Mobile application | Product tasks designed for mobile use | Required screens and user actions |
| Combined build | Connected website and app requirements | How each format serves its users |
A landing page can suit a focused product explanation or a single visitor action. See landing page design when that is the main requirement. A broader application makes more sense when users need defined workflows or business logic beyond a page.
Before choosing, write down the user, the task and the result each screen should support.
If you need both a website and an application, list what belongs in each. That simple split helps us plan connected work. It also stops every feature from being treated as essential for the first release.
3 inputs that shape the first build
3 inputs make the first build plan concrete: user tasks, required screens and product rules. Share these before design. The team can then turn broad requests into reviewable work.
- Users: name the people who will use the product and their roles.
- Tasks: list what each user needs to do, in the order it happens.
- Screens: identify the pages or app screens each task requires.
- Rules: explain what users can do at each step and what happens next.
- Devices: mark whether desktop, mobile and tablet layouts are needed.
- Admin: say whether an admin panel or page is part of the project.
- AI: describe the feature and where it belongs in a user workflow.
- SEO: name the website pages and setup tasks to include.
- Support: explain what maintenance or management assistance you need.
Existing products need a short inventory too. Send current designs and relevant materials. Add a clear note about what stays, changes or needs new work. For a consistent visual identity, consider brand book development alongside the product design.
We use a named review step before design. We compare requested features with user tasks and flag open decisions. You get a written list of what is clear and what needs your answer. That check keeps assumptions visible before they turn into conflicting review comments.
How do 5 project steps take work to review?
5 steps give both teams a clear route from the first product conversation to review. Each step has a practical output. You can see what needs your input and what comes next.
- Send the product brief: describe users, tasks, required screens and existing materials. Include any known product requirements.
- Review requirements: we discuss workflows, device adaptation, AI, SEO, admin and support needs. Open decisions are written down.
- Confirm the work: agree the design and development tasks, review responsibilities and project timing before the build begins.
- Design and develop: we create the agreed screens and functionality. Your team reviews the work against the recorded requirements.
- Check and plan support: compare the finished work with the agreed tasks. Then confirm any included maintenance or management assistance.
A useful review comment names the screen, the user task and the expected behavior. For example, identify which workflow does not match the agreed rule. That gives the team a clear issue to assess. It works better than a general request to make the product feel different.
If the project needs visual assets, connect them to the product’s screens and identity. We can coordinate them with banner and video banner design.
Review, support and the next move
3 review points keep design, functionality and post-build support visible: screen requirements, workflow behavior and the agreed maintenance plan. Record feedback in one shared place. Name who can approve changes for your team.
- Screen check: compare each layout with the required device and user task.
- Workflow check: test the behavior against the written product rules.
- Feature check: confirm each included feature answers a named user need.
- Support check: state what maintenance or management assistance is included.
- Change check: discuss new requests before treating them as part of the build.
One limit matters for website work: search engines control crawling and ranking. SEO setup cannot promise a search position. We agree the site tasks we will complete, but search placement remains outside the build team’s control.
Maintenance is clearest when the plan names the product area, expected assistance and how new requests are handled. The same clarity helps teams distinguish included support from later feature work. For related creative and development services, visit the studio overview.
Send us your product brief, required screens and target user tasks. We review open decisions, then send a written quote within 2 working days.
How it works
- Send the product briefDescribe the product, its users and the tasks they need to complete. Add required screens, existing designs and any known feature needs.
- Review the requirementsWe discuss workflows, device adaptation, AI, SEO, admin and maintenance needs. Open questions are recorded for your team.
- Confirm the workAgree the design and development tasks, review responsibilities and timing before the build begins.
- Design and developWe complete the agreed screens and functionality. Your team reviews them against the recorded requirements.
- Check and plan supportCompare completed work with the agreed tasks. Confirm any maintenance or management assistance included after the build.
Frequently asked questions
What should I send before discussing an app or website?
4 useful inputs are your product description, user tasks, required screens and existing materials. Add known workflow rules, device needs and feature requests. Note whether you need AI integration, SEO setup, an admin page or maintenance. We review open questions with you before confirming the work.
Can one project cover a website and a mobile application?
2 or more formats can sit in one project when their user tasks are clear. Tell us what visitors do on the website and what app users need to accomplish. We can then plan the design, workflows and screen adaptation around those separate requirements.
Can you add AI to a product that already exists?
1 defined user task is the right starting point for an AI feature. Explain what the feature should help users do and where it fits in the existing workflow. Share relevant product materials too. We review the requested function before including AI integration in the project plan.
Is SEO setup part of website development?
SEO setup can be included when the website plan names the pages and tasks involved. Tell us which pages matter and what setup you expect. We record that work for review, separately from design and functionality. Search placement is not something a build team controls.
What sets the timeline for a web3 app build?
Project timing is agreed after the requirements review, not assigned as one schedule for every build. The format, screens, workflows, feature requests and review process all shape the plan. We clarify those points with you before confirming timing. Both teams then know what the schedule covers.
Can you guarantee where my website appears in search?
No. Search engines control crawling and ranking, so a development team cannot promise a search position. We can agree and complete the SEO setup tasks listed for your website. Then we check those tasks against the project requirements. The report records the agreed work, not a claim about search placement.
Can you maintain the product after development?
Maintenance and management assistance can be included when the project plan defines them. Name the website or app areas that need support and the kind of help your team expects. We can then record those responsibilities alongside the build. That keeps post-build support clear.
Tell us about your project
Answer four quick questions and a manager will send you a plan, timing and a price range within the hour. Everything stays confidential.
Loading the form…