When a client first comes with a web application idea, the assumption is almost always the same: this is mostly about coding. You bring a brief, a developer sits down at a computer, and a few weeks later it's done. The reality is different — coding accounts for roughly a third of the entire process. The rest is made up of things that are equally important, and without which the code itself would be worthless. This article walks through every phase from the first meeting through architecture, design, and testing to launch and long-term operation.
Phase 1: Discovery — what you want and why
Discovery is the most important phase of the entire project. If you enter it with a vague brief, everything that follows will be built on the wrong foundation.
Discovery covers:
- Application goal — what the application should do, for whom, and why now
- Users — who will use it, how technically proficient they are, what they expect from it
- Scope — what is necessary for launch (MVP) and what can come later
- Integrations — connections with existing systems (ERP, CRM, payment gateways, third-party APIs)
- Security and regulatory requirements — GDPR, industry standards, internal policies
As a client you should come prepared with: a description of the problem the application solves, an overview of existing systems it needs to connect with, and ideally a description of how the current process works — even if it's manual. The more precisely you can describe "how we do it today", the better.
Discovery typically takes 1–3 weeks and produces a requirements document — not wireframes, not code, just a precise description of what will be built and what will not.
Real-world example: Manufacturing company Kovostav s.r.o. came in with a request for a "subcontractor portal". After two days of discovery, it became clear that the portal was meant to solve five different problems simultaneously — document approval, order tracking, invoicing, time tracking, and communication. Three of the five problems could be solved by configuring the existing ERP. The portal ended up focused solely on document approval and communication. Development was three times cheaper and faster than originally planned.
Phase 2: Architecture and technology choices
Once you know what you're building, you need to decide how you're building it. This decision will influence development for years to come — poor architecture will follow you through every sprint.
What gets decided in architecture
Database: Relational databases (PostgreSQL, MySQL) for structured data with clear relationships. Document databases (MongoDB) for flexible schemas. Redis for caching and session storage. Most applications need a combination.
Backend: Node.js, Python (Django/FastAPI), PHP (Laravel), Go, .NET — each technology has its strengths, and the choice depends on the type of application, performance requirements, developer availability, and existing infrastructure.
Frontend: Server-side rendering (Next.js) for SEO and fast loading, SPAs (React, Vue) for interactive applications, or a combination of both.
Infrastructure: Dedicated server, cloud (AWS, Azure, Google Cloud), or PaaS (Vercel, Railway). This depends on availability requirements, scalability needs, and budget.
Practical tip: Don't choose the trendiest technology. Choose the technology you have developers for and know you'll be able to hire another developer for in three years. Applications evolve — the team and language stay.
The output of the architecture phase is technical documentation — a component diagram, database schema, API description, and stack selection.
Phase 3: Design and UX
Design is not about making an application look good. Design is about making it usable. Poor UX will complicate user adoption more than any bug in the code.
The design phase proceeds in several steps:
- Wireframes — simple schematic sketches without colors or details. They solve layout, information hierarchy, and user flow.
- User flows — maps of how a user moves through the application from entry to goal.
- Mockups — visually faithful designs with colors, typography, and icons, but still without interactivity.
- Prototype — a clickable prototype on which usability can be tested before a single line of code is written.
This phase is the moment when the client should be most involved. It is infinitely cheaper to move a button in a mockup than to rewrite a finished component.
Real-world example: Logistics company Tranzit CZ requested an internal application for dispatchers. The main screen looked clean in the mockups. When testing the prototype with real dispatchers, it became clear that a dispatcher opens an average of 12 orders per hour and needs to see their status simultaneously, not sequentially. A Kanban view was added before the first line of code was written — saving roughly 40 hours of development.
Phase 4: Development in sprints
The actual development happens in iterations — sprints that typically last 1–2 weeks. At the end of each sprint there is something functional that can be seen and tested.
What a sprint looks like in practice
- Planning — the team selects features from the backlog to develop in the given sprint
- Development — backend and frontend work in parallel, continuously integrating
- Demo — at the end of the sprint the client sees what was completed and gives feedback
- Retrospective — the team evaluates what went well and what did not
As a client you should: be available for questions (ideally within 24 hours), come to demos prepared with context, and avoid focusing on cosmetic details in the early sprints — those get addressed at the end.
The key is that the backlog is not set in stone. If during development a particular feature turns out to make less sense than originally thought, its priority is adjusted. Agile development does not mean chaos — it means the ability to respond to new information.
Practical tip: Request access to the test environment throughout development, not just for demos. The earlier you see the real application, the earlier you catch any gap between your expectations and reality.
Phase 5: Testing
Testing is not a final check before launch. It happens continuously throughout development.
Types of testing
| Test type | What it tests | When it runs |
|---|---|---|
| Unit tests | Individual functions in isolation | Continuously during development |
| Integration tests | Communication between components | After every merge |
| End-to-end tests | Complete user flows in the browser | Before every release |
| User testing | Whether real users understand the app | After UI completion |
| Security testing | Vulnerabilities, authorization, injection | Before launch |
| Performance testing | Behavior under load | Before launch |
UAT (User Acceptance Testing) is the phase where the client and selected key users systematically test the application against the original requirements. It typically takes 1–2 weeks and is a prerequisite for moving to production.
Real-world example: An accounting application for FinServis Praha passed internal testing without issues. During UAT, the financial director noticed that importing invoices from a specific vendor generated duplicate records due to a particular data format. The problem would have surfaced on day one in production, requiring manual data correction. Catching it in the testing phase cost 3 hours — fixing it in production would have cost 3 days and significant stress for the entire accounting department.
Phase 6: Deployment and launch
Deployment is not flipping a single switch. It is a managed process that minimizes risk.
What happens before launch
CI/CD pipeline — an automated chain that, on every code change, automatically runs tests, builds the application, and deploys it to the staging environment. Nobody deploys manually via FTP.
Staging environment — an identical copy of production on which final testing takes place. Staging must have the same configuration, database schema, and data (anonymized) as production.
The go-live checklist includes:
- Database backup before launch
- A prepared rollback plan (how to revert if something fails)
- Monitoring tools active from the very first moment
- Team notifications on errors
- Tested SSL certificates and DNS configuration
- GDPR and cookie compliance
Practical tip: Launch on a Thursday morning, not a Friday afternoon. You have the whole day to respond to any issues with the full team available.
Phase 7: Operation and iteration
Launch is not the end of the project — it is the beginning of its life. Every application needs care after launch.
Monitoring tracks performance, availability, errors, and user behavior. Tools like Sentry, Datadog, or custom dashboards give immediate visibility into what is happening.
Bug fixes after launch are inevitable. No application is without bugs — what matters is having an established process for reporting, prioritizing, and fixing them.
Iterations come based on real usage data. Features you considered most important may be rarely used. Features you postponed may turn out to be critical. Production data is the most valuable input for further development.
A good application is never finished — it simply moves from the "development" phase into the "continuous improvement" phase.
Timeline and cost comparison
The table below is a rough guide. Actual figures depend on specific requirements, integration with existing systems, and the chosen technology stack.
| Application type | Description | Development duration | Approximate cost |
|---|---|---|---|
| Simple application | CRUD, 3–5 screens, single user role | 6–10 weeks | €6,000–14,000 |
| Medium complexity | Multiple roles, integrations, reporting, notifications | 3–6 months | €16,000–36,000 |
| Complex / enterprise | Complex workflows, multiple integrations, high availability | 6–18 months | €40,000 and up |
These costs cover discovery, design, development, testing, and launch. They do not include annual operation, hosting, and ongoing iterations after launch.
Practical tip: An underestimated budget is the most common cause of failed projects — not bad code, not the wrong technology. It is better to scope down to a solid MVP and iterate than to arrive with an over-ambitious brief and run out of money halfway through.
At BASAD Studios, we guide clients through the entire web application development process — from initial analysis through design and development to launch and operation. If you are planning a web application and want to know how to approach it, get in touch or check out our web application service.