How to Evaluate a Web Application Development Process

Overview: The Seven Phases of Web Application Development

A complete web application development process has seven development phases: discovery and requirements, planning and architecture, UI/UX design, development, quality assurance and testing, deployment and launch, and post-launch support. The phase names matter less than the decision gates attached to them. Each development phase should produce artifacts that the buyer can review before approving the next investment.

The seven phases are:

1. Discovery and Requirements — the discovery phase defines what the application must accomplish, who will use it, which workflows it supports, which integrations are required, and which risks shape the build.
2. Planning and Architecture — converts requirements into technical decisions: structural pattern, database model, API strategy, authentication, infrastructure, integration approach, and deployment plan.
3. UI/UX Design — turns requirements into user flows, interface states, navigation, forms, dashboards, responsive layouts, and a clickable prototype stakeholders can test before code is written.
4. Development — builds working software in sprint increments so stakeholders can review frontend, backend, database, integration, and permission work before the end of the project.
5. Quality Assurance and Testing — verifies workflows, roles, devices, browsers, integrations, regression risk, performance thresholds, access control, and launch readiness.
6. Deployment and Launch — moves the application into production with monitoring, rollback planning, environment configuration, DNS, SSL, credentials, backups, and release communication.
7. Post-Launch Support and Iteration — keeps the application secure, stable, and aligned with user feedback through bug fixes, security patches, performance tuning, monitoring, and feature iteration.

These phases are the operating backbone behind professional custom web application development. Mature web application development services should make every phase visible enough for the buyer to approve, pause, or redirect the next investment with evidence instead of trust alone.

What a Mature Development Process Should Cover

A mature web application development process moves a project through seven phases — discovery, planning and architecture, design, development, quality assurance, deployment, and post-launch support — with specific deliverables, decision gates, and stakeholder responsibilities at each step. The phases themselves are not the differentiator. Every credible vendor will name them. The differentiator is what each phase actually produces, who reviews it, and what happens when the deliverable is not approved.

Use the table below as a buyer's reference for what each phase should deliver. When evaluating a vendor, ask them to walk through their process and check whether their answers match this scope. A vendor that cannot describe phase deliverables in concrete terms — documents, prototypes, working software, test reports, runbooks — is improvising rather than executing a methodology. The Standish Group's 2015 CHAOS Report, summarized by InfoQ, studied 50,000 software projects and defined success around on-time, on-budget delivery with a satisfactory result; that is the same outcome discipline this table is designed to test.

For a deeper walk-through of how each phase actually executes — the engineering work, the team composition, the communication cadence — see the Kavara development process. That page describes how the work is done. The rest of this guide tells you how to evaluate whether the vendor in front of you can do it.

The phase list sets the standard. Knowing what to demand at each phase exposes whether the vendor meets the standard.

What Deliverables Should You Demand at Each Phase

Demand specific deliverables at every phase before approving the next phase. A development company that cannot list concrete deliverables — by document name, by format, by review process — is selling a promise instead of describing a methodology. A phase-gate is a decision checkpoint where the buyer reviews a phase deliverable before authorizing the next phase of work. The phase-gate approach protects budget by surfacing scope, design, and architecture problems before they become scope changes mid-development.

The mapping table below pairs each of the seven phases with what to demand and what a bad answer sounds like.

The deliverables to demand at each phase are:

1. Discovery — Demand a written requirements document, not a verbal summary. The document should cover functional requirements, non-functional requirements (performance, security, availability), user stories with acceptance criteria, integration inventory, scope estimate with budget range, and risk assessment. If the vendor offers a one-page proposal in place of a documented requirements artifact, the discovery has not actually happened. Discovery commonly represents 5% to 10% of the project budget, and PMI's 2014 Requirements Management report found that 47% of unsuccessful projects failed to meet goals because of inaccurate requirements management.

1. Planning and Architecture — Demand an architecture document with technology rationale, not a stack list. The vendor should explain why each major decision was made: why this database, why this cloud, why monolith or microservices, why this authentication model. The buyer does not need to dictate the choices, but the vendor should be able to defend each one against the project requirements. Demand also the database schema, API design, and infrastructure plan in writing.

1. Design — Demand an interactive clickable prototype, not static mockups. A prototype that stakeholders can navigate exposes workflow problems before code is written. Demand also a design system covering reusable components and responsive specifications across desktop, tablet, and mobile. IBM Systems Sciences Institute defect-cost research is commonly summarized as a directional curve: defects found in design can cost 3 to 5 times more to correct than requirements defects, and the multiplier increases as defects move toward QA and production.

1. Development — Demand a working software demo every two weeks, not status reports. Sprint demos let stakeholders inspect features live, ask questions, and adjust priority before the next sprint commits. If a vendor goes four or more weeks without showing working software, the project is at risk regardless of what status reports claim. Demand also transparent budget tracking: spend to date and remaining budget, visible at all times.

1. Quality Assurance — Demand a test plan, bug reports with severity classification, performance benchmarks, and a launch readiness checklist. QA is not a checkbox. IBM Systems Sciences Institute's cost-to-fix curve places defects found during testing at roughly 15 times the requirements-phase baseline and production defects as high as 100 times that baseline, so late defects can affect users, production data, support load, and downstream features at the same time. A vendor that cannot show its test plan and security scan results before launch is asking the buyer to absorb that cost premium.

1. Deployment — Demand monitoring, alerting, backup procedures, and a rollback plan before the launch button is pressed. Launch without monitoring is flying blind. The vendor should show the deployment pipeline, the production environment configuration, and the launch checklist covering DNS, SSL, credentials, and rollback readiness.

1. Post-Launch — Demand an SLA covering bug response time by severity, security patch cadence, and feature iteration process. Vague availability is not a support model. A vendor without a structured post-launch model is building software it will not stand behind.

If a development company cannot describe these deliverables in concrete terms, the process is probably not structured enough to produce predictable outcomes. The phase-gate model also gives the buyer a series of stop points. If discovery does not produce a usable requirements document, do not approve the architecture phase. If architecture does not produce a defended document, do not approve development. The deliverables exist to make decision points enforceable.

Demanding deliverables exposes process maturity. Recognizing process red flags exposes the vendors that should not advance to contract.

Process Red Flags That Indicate Project Risk

Process red flags during evaluation predict project failure during development. The same patterns appear across failed projects: vague phase descriptions, missing artifacts, unstructured communication, no defined change management, and no documented post-launch model. A vendor that exhibits these signals before signature usually exhibits them at scale after the contract starts.

The diagram below shows the five process red flags with a severity rubric — one flag warrants follow-up, two or more warrant escalation, three or more warrant declining.

The five most consistent process red flags are:

1. No phase-gate model — just "we are agile." Real agile has structure: sprint cadence, demo schedule, backlog management, change-order process, and decision ownership. "We are agile" without specific tools, ceremonies, and artifacts usually means the team improvises. Ask the vendor to walk through a sprint cycle from planning through demo. A practitioner can describe the cadence in five minutes. A generalist offers reassurance.

1. No working software demos for four or more weeks during development. A development team that cannot or does not show working software every two weeks is hiding progress, struggling with delivery, or running an internal process that excludes stakeholder feedback. This is the single most reliable signal that a project is off track. Avoid vendors who propose "big reveal" development where the buyer sees the application only at the end.

1. Discovery skipped, compressed, or replaced with a fixed estimate. Moving from sales call to fixed development estimate without discovery means the estimate is guesswork. Discovery is where scope, integrations, risk, and cost assumptions become real. PMI's 2014 Requirements Management study found that inaccurate requirements management caused 47% of unsuccessful projects to miss their original goals, so a vendor that skips discovery is choosing the failure mode.

1. No documented change-management process. Requirements change in every project. The question is whether changes are evaluated, documented, priced, and approved before implementation, or whether they are absorbed silently into the backlog. Ask the vendor what happens when a stakeholder requests a new feature mid-sprint. The right answer covers scope review, cost and timeline impact, and written approval. The wrong answer is "we figure it out."

1. No post-launch support offering or SLA. A vendor that builds and walks away leaves the buyer responsible for vulnerabilities, dependency updates, bugs, infrastructure issues, and browser compatibility. A production application without a support model degrades within months. If the proposal does not define a post-launch SLA, the vendor is selling code, not software.

These red flags should be weighted by severity. One unclear answer may require follow-up. Repeated ambiguity across phase deliverables, demo cadence, change management, and post-launch support compound into project risk that the buyer absorbs after the contract starts. The full evaluation framework — including team composition, technical expertise, and reference checks — is in the how to choose a development company guide. The process red flags above are the subset that vendor process descriptions expose directly.

Recognizing red flags screens out the wrong vendors. Comparing process maturity selects between the right ones.

How to Compare Process Maturity Across Vendors

Process maturity comparison is a direct, side-by-side evaluation of how three to five candidate vendors handle the same project requirements. The comparison should use a written rubric so that decisions are auditable and so that subjective impressions are forced into specific categories.

The vendor that scores higher across these dimensions is the safer choice — even if its hourly rate is higher. Process maturity reduces project risk because mature processes catch problems early, document decisions, and produce evidence at every phase. PMI's 2020 Pulse of the Profession report found that organizations undervaluing project management as a strategic competency reported 67% more projects failing outright. Immature processes accumulate risk silently until milestone reviews surface problems that are now expensive to fix.

The strongest comparison sessions use the same questions, the same rubric, and the same evaluators across every vendor. Save reference notes, sample artifacts, and answers to comparison questions in a single document so the final decision is auditable. Process maturity comparison also exposes whether vendors can credibly explain the research, standards, and operating assumptions behind their methodology. A vendor explaining sprint structure should be able to reference recognized agile practices. A vendor explaining requirements work should be able to explain how requirements risk is reduced. A vendor explaining QA should be able to explain how testing lowers post-launch cost. Vendors who can defend the reasoning behind their process have usually built around it. Vendors who cannot usually built around tradition.

Process maturity comparison narrows the field. Methodology selection determines which mature process actually fits the project.

How Long Does Each Phase Take

Phase timelines vary by application complexity, integration depth, compliance requirements, team size, and client decision speed. A simple application may move from discovery to launch in 2 to 4 months. A mid-complexity custom web application usually needs 4 to 8 months. Complex enterprise applications with regulated data, multiple integrations, and migration work often require 8 to 12 months or more.

Development usually consumes the largest share of time, but the discovery phase and architecture phase determine whether that development time produces stable progress or expensive rework. Compressing the early development phases rarely saves money if requirements, integrations, or architecture decisions are still unresolved.

The timeline pattern matters more than the exact week count. Development is usually 40% to 50% of total duration, but the early gates decide whether that time produces working software or rework. A vendor who compresses discovery and architecture while protecting a large development block is usually protecting coding time at the expense of decision quality.

What Deliverables Should You Expect at Each Phase

Every development phase should produce something reviewable. The minimum buyer-side checklist is requirements and risks from discovery, technical rationale from architecture, prototypes from design, working software from development, test evidence from QA, launch and rollback plans from deployment, and an operating model from support. If one of those artifacts is missing, the buyer should treat the phase as incomplete.

The checklist is intentionally artifact-based because artifacts can be reviewed, compared, revised, and transferred. Verbal process explanations cannot. A requirements document, architecture rationale, prototype, sprint demo, test plan, runbook, and SLA are the evidence layer behind a mature web application development process.

What Is Agile vs Waterfall for Web Applications

Agile is an iterative sprint methodology with frequent demos and flexible priority. Waterfall is a sequential methodology with fixed phase sign-offs. Hybrid locks discovery and architecture first, then builds features in agile sprints.

Methodology selection should match the project type, not the vendor's preference. The wrong methodology — even when executed well — produces predictable failure modes: agile on a fixed-scope compliance project produces scope drift, waterfall on a discovery-heavy product project produces misalignment at the end, and hybrid without clear phase boundaries produces both.

The three primary methodologies are:

1. Agile. Iterative development in two-week sprints with priorities that can evolve as the team learns. Agile fits most custom web application development projects because requirements often change after stakeholders see working software.

1. Waterfall. Sequential phases where each phase completes before the next begins. Waterfall fits compliance-driven projects with immutable requirements, fixed-scope contracts, and procurement environments where phase-gate sign-offs are mandatory.

1. Hybrid. A discovery and architecture phase executed sequentially followed by agile sprints during build. Hybrid fits projects where architecture decisions are high-stakes, but feature implementation benefits from iterative feedback.

If a development company proposes pure waterfall for a custom web application without a compliance reason, ask why. If a vendor proposes pure agile on a contractually fixed-scope project, ask how scope changes will be handled. Methodology selection should be a deliberate choice tied to project characteristics, not a default.

Methodology and process maturity together determine whether the vendor is the right partner. Evaluating whether the process is working once development is underway is the next step.

How to Evaluate Whether Your Development Process Is Working

A development process is working when progress is visible, risks are surfaced early, and decisions are documented before implementation changes direction. The best signal is not a polished status report; the best signal is working software that stakeholders can inspect. Five health indicators show whether an in-progress project is under control:

1. Working software appears every 2 weeks, not only status reports.
2. Budget tracking is transparent, so spend and remaining budget are visible.
3. The team surfaces problems early instead of waiting for milestone deadlines.
4. Scope changes are documented with cost impact before implementation.
5. The client can explain what the team accomplished this sprint in one paragraph.

Warning signs include no working demos for 4 or more weeks, repeated "infrastructure" updates without visible features, avoided budget conversations, and unclear ownership of decisions. A healthy web application development process makes reality visible before problems become expensive. CISQ's 2022 Cost of Poor Software Quality in the US report estimated poor software quality at $2.41 trillion and accumulated technical debt at roughly $1.52 trillion, which is why unresolved process problems should be treated as operating risk rather than temporary delivery noise. If two or more warning signs appear simultaneously, escalate inside the engagement and request a process review with the vendor's senior leadership.

What to Ask About Process Before You Sign

The questions that expose process maturity in 90 minutes of conversation are specific and answerable. Ask each candidate vendor the same set so the answers are comparable.

1. Walk us through your sprint cycle from planning through demo, naming the artifacts produced in each ceremony.
2. Show an anonymized requirements document, sprint demo agenda, or status report from a previous mid-market project.
3. What happens when a stakeholder requests a new feature mid-sprint?
4. How do we see progress between sprint reviews?
5. What is the SLA for critical bug response after launch, and how is it enforced?

Strong answers include specific tools (Jira, Linear, GitHub), specific cadences (two-week sprints, weekly status, monthly architecture review), specific artifacts (requirements document template, sprint demo deck format, runbook structure), and specific escalation paths. Weak answers stay at the level of "we are agile" or "we are always available."

The vendor that can show the artifacts is selling a process. The vendor that cannot is selling a promise. The cost of asking is zero. The cost of skipping is the project.

How Does Process Differ by Application Type

The seven-phase structure is consistent, but emphasis shifts by application type. SaaS projects need deeper architecture work for multi-tenancy and cross-tenant QA. Enterprise portals need heavier discovery for role-based access, SSO, and permission mapping. MVP projects compress timelines while preserving discovery, architecture, QA, and launch gates. Dashboard projects need data pipeline validation before visualization development. Healthcare and fintech projects need compliance scoping in discovery.

A vendor that adjusts process emphasis by application type understands the engineering. A vendor that runs every project with identical phase weightings is selling a template. The buyer's evaluation should test whether the vendor's process flexes to fit the project.

The web application development process is the operating model for how a vendor turns business requirements into production software. Evaluating that process before signature is the cheapest way to predict project outcomes — far cheaper than discovering process gaps at month four. Demand specific deliverables at each phase, recognize the red flags that indicate weak process, compare maturity across vendors with a written rubric, and match the methodology to the project type.

The vendor that welcomes structured process evaluation is usually the vendor whose process can withstand it. The vendor that deflects process questions with reassurance is usually the vendor whose process cannot.

Explore Kavara's service model for production applications to see how this process delivers across SaaS, portal, dashboard, MVP, and enterprise software categories, or start a project conversation to evaluate Kavara against the framework on this page.