Process · 6 min read
The website and app development process in 2027, step by step
Every stage of a professional build, from the first call to the weeks after launch, with realistic timings and what you will be asked for at each step.
If you’ve never commissioned a website or an app before, the whole process can feel like a black box. You sign something. Weeks pass. Then either a finished product appears, or (more often) a stream of questions you weren’t expecting and aren’t sure how to answer. It really doesn’t have to work like that.
So here’s how a professional build actually runs, stage by stage, with realistic timings and, most usefully, what you’ll be asked for at each step. I’ve written it around how we work at Razegreen, but you should expect something similar from any serious team.
The whole process on one screen
| Stage | Website | Mobile app | What you provide |
|---|---|---|---|
| 1. Discovery and scoping | 1 week | 1–2 weeks | Goals, audience, examples you like, budget |
| 2. Proposal and contract | A few days | A few days | Decisions and sign-off |
| 3. UX: structure and flows | 1 week | 1–2 weeks | Feedback on sitemap or user flows |
| 4. UI design and prototype | 1–2 weeks | 2–3 weeks | Brand assets, design feedback |
| 5. Development in sprints | 2–4 weeks | 6–12 weeks | Content, access to systems, sprint feedback |
| 6. Testing and fixes | 1 week | 2 weeks | Your own testing on your devices |
| 7. Launch | 1–2 days | 1–2 weeks (store review) | Final approval, store and domain access |
| 8. Warranty and growth | 30 days, then ongoing | 30 days, then ongoing | Early user feedback |
In practice the stages overlap. Design on the later screens often carries on while development starts on the first ones.
1. Discovery and scoping
Honestly, this is where most projects are won or lost. A good team wants to understand what the product has to achieve for the business, who is going to use it, what those people do today instead, and what success looks like in actual numbers. Expect workshops or calls, questions about your competitors, and requests to look at any existing systems the product has to connect to.
What you get out of it is a written scope, a feature list split into “version one” and “later”, a technical approach and an estimate. If a company skips all this and quotes from a two-line email, that quote is a guess.
2. Proposal and contract
You should get an itemised proposal with milestones, payments linked to those milestones, the timeline and a list of what’s excluded. The contract should cover who owns the code and accounts, confidentiality, the warranty, how changes are handled and the exit terms. Our guide on choosing a software company lists what to check.
3. UX: structure before looks
For a website, this stage means the sitemap and wireframes, which is to say which pages exist and what goes on each one, drawn as plain grey boxes. For an app it means user flows: every step from opening the app to finishing each task. Moving a box on a wireframe is cheap. Rebuilding a finished screen isn’t. That’s why this is the stage I’d ask you to give your full attention.
4. UI design and a clickable prototype
Now the product gets its look. Typography, colour, imagery, components, and how all of it behaves on a phone and on a laptop. For apps and more complex websites you should get a clickable prototype you can tap through like the real thing. Show it to a few customers. Their confusion at this point is worth more than anyone’s opinion later on.
What you provide: your logo files, brand guidelines if you have them, and consolidated feedback. One person giving feedback, rather than five, is what keeps this stage on schedule.
5. Development in sprints
Most professional teams now build in short cycles called sprints, usually two weeks long. At the end of each one you should see working software. A status report isn’t the same thing. You click through what’s been built, flag anything that doesn’t match what you expected, and agree what happens next.
Behind the scenes, good practice means a staging environment separate from the live product, code review on every change, automated tests for the paths that matter and regular security checks. You don’t need to understand all of it. You should ask whether it’s happening.
What you provide: content (by far the most common cause of delay on website projects), access to any systems we’re integrating with, and prompt feedback after each sprint demo.
6. Testing
Testing covers features, forms, payments and integrations on real phones as well as laptops, including a mid-range Android handset on a slow connection, because that’s how a lot of Indian customers will actually use it. It should also check speed against Google’s Core Web Vitals, accessibility basics and security. And you should test too. Nobody knows your business rules better than you do.
7. Launch
For a website, launch is usually an hour or two of planned work: switching the domain, redirecting old URLs, submitting the sitemap to Google Search Console and checking that analytics is recording. If you’re replacing an existing site, the redirects are critical, and I explain why in redesigning without losing rankings.
An app launch involves preparing the store listings, screenshots and privacy disclosures, then waiting for Apple and Google to review everything. New personal Google Play accounts also have to run a closed test with at least 12 testers for 14 days before they can publish, so either register a business account or build that time into the plan.
8. Warranty, then growth
You’ll learn more in the first few weeks after launch than in the months before it. A warranty period (30 days, in our case) covers bugs in anything that was agreed. After that it’s your choice whether to carry on with a maintenance plan and a roadmap for the next version. For what that should cost, see our maintenance cost guide.
What actually causes delays
It’s almost never the code. In our experience the usual culprits look like this:
- Content that arrives late, or turns up as a 40-page document that has to be rewritten for the web.
- Feedback from several people who disagree with each other.
- New features added in the middle of a sprint without the timeline moving.
- Waiting on access to a third-party system, a payment gateway account or the app store credentials.
Get content, a single decision-maker and account access sorted early, and most projects finish on time.
What’s different in 2027
Two things now belong in the process from the first week instead of the last. One is data protection. With India’s DPDP Rules fully in force from May 2027, notices, consent, retention and breach handling have to be designed in from the beginning, and adding them at launch is painful. Our DPDP checklist covers what that means. The other is AI. If you want features like smart search or a support assistant, plan the data and integrations for them during discovery. Our guide to AI features and their costs will help you decide which ones are worth it.
Our process at Razegreen
We run exactly these stages, with fixed milestones, a demo every two weeks and a 30-day warranty after launch. To see how it would apply to your project, have a look at our website and mobile app development pages, or get in touch for a scoping call.
