The web application development process turns a business need into software people use in a browser: submitting requests, managing bookings, approving orders. It covers discovery, requirements, design, development, testing, launch, and ongoing operation. How these activities are organized depends on the project.
At each stage, keep three questions in mind: what does your team provide, what does the development team deliver, and how do you check the result? The stages overlap and repeat as the product grows, so agree on responsibilities, acceptance, and handover before development begins, not after.
Many websites already include application features. So the useful starting point is not the technology but something simpler: the work a person needs to get done.
The process at a glance
The seven stages below are a practical way to organize the work. They are not a mandatory sequence and not an estimate of project length. Testing, security, and documentation run through the whole build, including any dedicated testing and acceptance stage.
| Stage | What your team provides | What you receive and review |
|---|---|---|
| 1 · Discovery | Business problem, users, current workflow | First-release scope and priorities |
| 2 · Requirements | Business rules, roles, constraints | Expected behavior and acceptance criteria |
| 3 · Design | Feedback on tasks and screens | User flows and a prototype |
| 4 · Development | Decisions and access to agreed systems | Working features you can try |
| 5 · Testing and acceptance | Representative users and scenarios | Test results, known issues, acceptance record |
| 6 · Launch | Operational contacts and launch approval | A deployed app and an operating plan |
| 7 · Handover and support | People responsible for running the app | Agreed code, access, documentation, and support terms |
Throughout this guide, picture a customer portal (see a real build example): a customer submits a request with a document, an employee changes its status, and the customer receives a notification. This is an illustrative example, not a client case study.
1. Define the problem and the first release
Start with the people: who will use the application and what they need to accomplish. Show how it works today, including spreadsheets, forms, and manual steps. And say plainly where work gets delayed or information gets lost.
What goes into the first release
For the portal, the first release might cover submission, status tracking, and notifications. Payments and reporting can wait. Write down both decisions, what is in and what is out, so an estimate has clear boundaries.
Ask what discovery produces
Published provider data, for example, describes a discovery output as “Scoped roadmap + technical recommendations — yours to keep,” with a design stage producing wireframes and an architecture blueprint. These are examples of named outputs, not a standard package every provider supplies.
Your decision: does the proposed first release solve the right problem, and is the work outside its scope explicit?
2. Agree on requirements and responsibilities
You do not need to arrive with a complete technical specification unless that is part of your agreement. You do need someone who can explain the business rules and make decisions.
What to prepare
Context: User roles, example data, existing systems, planned integrations, and relevant constraints.
Data: Where real data is unnecessary, use anonymized or synthetic examples.
Decisions: Name a decision-maker and agree how quickly questions need answers.
One published provider FAQ names “a feature list and any planned integrations” as useful starting information. Your project may also need rules for permissions, record retention, or approvals.
For the portal
Clarify who can view a request, which employee roles can change its status, and what happens when a document upload fails. An acceptance criterion might say that one customer must not be able to access another customer's request, including through a direct link.
Your decision: are the requirements specific enough to check, and does each unresolved question have an owner?
3. Review the user flow and prototype
A prototype shows how people will move through the application before all the underlying logic exists. Walk through a complete task rather than commenting only on colors and page layouts.
For the portal, follow the whole path: submission, confirmation, employee review, and notification. And not only the successful path; look at empty screens, validation errors, and permission restrictions too.
Ask which parts of the prototype are interactive demonstrations and which represent working software. Approving a design does not establish that the database, integrations, or access controls are ready.
Your decision: can each user complete the intended task, and have the important error states been considered?
Technology choices
Before implementation, ask the team to explain its technology choices in terms of your requirements: integrations, expected load, data handling, operating costs, and who will maintain the app. You do not need to choose a framework yourself. You do need to understand significant dependencies and trade-offs, including the limits of any managed or no-code platform.
4. Build and review working features
How the app is put together
In short: the frontend is what people use; the backend handles application rules and requests; a database stores information; and integrations connect the app to services such as email or payment systems. The project may use managed services for some of these functions.
Ask for a live demo
Not a screenshot, but a working scenario with suitable test data. For the portal, that means creating a request, saving it, changing its status, and checking what the customer sees. A finished screen alone does not demonstrate the whole workflow.
A defect or a new requirement
Record feedback against a version or demonstration date. And separate two things: a feature that fails an agreed requirement is one case; wanting it to behave differently is a change request. That distinction helps the team investigate issues and assess changes without silently expanding the scope.
Your decision: does the working feature match the agreed behavior, and which feedback needs a scope decision?
How AI and vibe coding fit into the process
Clients increasingly ask a fair question: if an application can be assembled with AI, what does the studio still do, and which stages remain? AI speeds up part of the path, but it does not remove the decisions the team is responsible for.
- What changes: the first prototype, draft code, and interface iterations can be produced quickly with AI.
- What stays: requirements, architecture decisions, access and data checks, testing, acceptance, launch, and handover. These are the same stages as in the rest of this guide.
- If a prototype already exists: first review the code, dependencies, infrastructure, and fit to the requirements, then decide what to keep, refine, or replace. Do not assume in advance either a full rewrite or readiness to launch.
There is a solid reference point here. GitHub's responsible-use guidance advises reviewing and testing code produced by an AI agent before it goes into a project, including for errors and security issues (GitHub Docs).
| What already works with AI | What to check before launch |
|---|---|
| The main screens work | Errors, empty states, and real user scenarios |
| Sign-up and login exist | Who can reach another user's data and admin functions |
| A database and APIs are connected | Secrets, access rights, and failure handling |
| The app is deployed | Monitoring, backups, and recovery |
| The code can be exported | Repository, dependencies, instructions, and whether another team can maintain it |
Your decision: for anything built with AI, is it accepted against real scenarios, checked for access and security, documented, and maintainable by another team?
5. Test the application and record acceptance
Testing and acceptance are different
Testing answers the question of how the software behaves and how well. Acceptance records whether a specific result is accepted, needs changes, or is accepted with agreed exceptions. And your participation does not replace the development team's technical testing.
Key terms
| Term | What it means for your project |
|---|---|
| Acceptance criteria | Conditions a particular feature or deliverable must meet |
| Definition of Done | In Scrum, the quality requirements a usable addition to the product, called an Increment, must meet |
| QA and testing | QA focuses on the processes used to achieve quality; testing checks the software and helps identify defects |
| User acceptance testing, or UAT | Intended users or customer representatives check whether agreed scenarios meet their business needs |
| Sign-off | A recorded acceptance decision covering a specified result and any agreed exceptions |
The Scrum Guide defines the Definition of Done in relation to the quality of an Increment. It does not make a Sprint Review a mandatory release gate. If your contract requires customer approval before release, describe that approval separately.
A portal acceptance example
It illustrates the format, not a complete security or testing plan.
| Scenario | Expected result | Evidence to record |
|---|---|---|
| Customer submits a valid request | The request is saved and a confirmation appears | Test case, build version, result |
| Customer attempts to open someone else's request | Access is denied and no protected content is exposed | Test accounts and result |
| Authorized employee changes the status | The new status is saved and the agreed notification is sent | Request ID, notification result |
Which checks to agree
Agree in advance: functional tests for expected behavior, integration tests for connected systems, regression tests after changes, and browser and device compatibility checks. Set performance targets against expected usage. Specify security and accessibility requirements early, then check them throughout the build: access restrictions, keyboard navigation, form labels, and error messages. These examples do not establish complete security or accessibility compliance; they are simply what is worth checking.
Record the decision
Record who reviewed the release, the issues that remain, the decision, and the date. And agree in advance on the review window, the rejection procedure, retesting, and what happens if no one responds. Those details come from the project agreement, not from the word “tested.”
How to handle changes after approval
When a new requirement appears, ask for its effect on both price and schedule before you authorize it. An hourly rate alone does not tell you the total cost or the delivery impact.
Published provider terms state: “For bigger changes, we review the impact on scope, budget, and timelines with you before moving forward,” and describe updating the statement of work when scope, timelines, or deliverables change. That is one published approach, not a universal rule.
A compact change record:
Request and reason: what needs to change, and why?
Scope impact: which behavior, deliverables, or acceptance criteria change?
Cost and schedule: estimated additional work, price, dependencies, and revised dates.
Decision: approve, defer, or decline; name the approver and date.
For the portal, adding SMS alongside agreed email notifications is a new request. An agreed email notification that fails is an issue to investigate against the existing requirements. Whether a fix is included depends on the agreement and the cause.
6. Launch with an operating plan
Deployment puts a version of the application into its target environment. But to keep the service running, launch also needs people and procedures.
Who is responsible for what
Before release, confirm who handles the environment, data migration, monitoring, backups, recovery, and incidents. Agree on the launch checks and what would trigger a rollback. Test recovery procedures in a suitable environment rather than improvising them during a production incident.
For the portal, verify the core submission and notification workflow after deployment using an agreed test procedure. Name the person who will respond if it stops working.
Your decision: are the release checks complete, known issues addressed or explicitly accepted, and operational responsibilities assigned?
7. Hand over the app and agree on ongoing work
Handover can happen gradually, with your team receiving repository access and documentation during development. The final handover simply confirms that the agreed materials and responsibilities are in place.
Published provider data describes handover materials as “architecture diagrams, runbooks, and a recorded walkthrough.” A runbook explains recurring operational tasks and what to do when something goes wrong. Ask for documentation that the person running your app can actually use.
Code ownership, access, and licences are different
Separate the contractual rights to custom code from repository permissions and the practical ability to deploy it. Also identify third-party components and any reusable software owned by the provider.
One published provider states: “Once the project is complete and fully paid for, all rights to the source code, documentation, and other deliverables are transferred to you.” Another describes transfer of project-specific deliverables “as defined in the project agreement.” Preserve those conditions when comparing proposals.
Another published FAQ ties transfer to final payment and states: “The accelerator layer is licensed perpetually and royalty-free,” retaining vendor reuse rights for that component, while other ownership wording on the same page is broader. Ask for the agreement to resolve exactly what is assigned and what remains licensed; the page does not support an unqualified claim that every component becomes your exclusive property.
For cloud and hosting services, agree on account ownership, administrator roles, billing, data export, and how you can leave the service. Managed hosting may use the provider's account, so an account transfer is not always the arrangement. Confirm the exit process instead of assuming that shared credentials give you control.
Warranty, maintenance, and new features
Three different things. A warranty can cover specified defects for a defined period. Maintenance can cover updates and ongoing operation. New features extend the agreed behavior. The scope and price of each depend on the agreement.
Published provider terms describe a “standard 3-6 month warranty period at no additional cost, depending on the project scope and agreement.” That does not establish a universal six-month term or an exact start date for your project.
Ask what is covered, when the period begins, how to report a defect, what is excluded, and what becomes paid work. A response-time commitment is also different from a promise to resolve every issue within that time.
A handover checklist you can use
This is an editorial checklist to adapt to your agreement, not a statement of iQyra's service terms.
Code and rights: delivered repositories, custom-code rights, payment conditions, dependencies, and licences.
Access: repository administrators, cloud and hosting arrangements, domain and third-party service responsibilities.
Operations: deployment instructions, configuration requirements, monitoring, backup and recovery procedures, and incident contacts.
Data: agreed migration or export formats, access permissions, and responsibilities for retained copies.
Knowledge: architecture notes, known limitations, training, and an identified operational owner.
Acceptance and support: accepted version, open issues, warranty terms, support scope, and change approval process.
Record where each item is stored, who controls it, and how receipt was checked. Keep passwords and secrets out of the checklist; use the agreed secure access process.
The provider examples come from selected public pages reviewed for this article through September 30, 2026, using saved research material. They describe published statements, not independently verified delivery practices, a ranking, or a representative market survey. Source URLs and saved page excerpts are retained in the editorial research record. Check current terms and your project agreement. The process table, portal example, and checklists are editorial tools.