A sales director signs off a customer portal with a small agency in January. By the autumn the portal works and customers use it, but the code is in the agency's repository, the servers run in the agency's cloud account, and every change, however small, goes back to the same agency at the agency's price.
Nothing in that project failed technically.
Web application development usually goes wrong in the business decisions around the code: what to build first, who owns what, and who keeps the app running in year three. Those decisions belong to the people who pay for the app, and they are easier to get right before the first contract than after it.
What is a web application, and do you need one?
A web application is software people use through a browser. They sign in, enter or change data, and the application does something with it: books a room, approves an invoice, prices an order. Online banking, a hotel booking engine, a client portal and a CRM such as Salesforce are all web apps.
A website is mainly for reading, while a web app is for getting something done. The line blurs in places, since an online store is a catalog to read and a checkout to use, but the difference decides the budget: a website is content on a content management system, while a web app has business rules, user accounts, integrations and data that must stay correct.
If you only need to publish pages, buy a CMS or a website builder. Web application development starts when people need to do something on the page that changes data in your business.
Web app or mobile app?
One web app serves every device from one codebase, and an update reaches every user the moment it is deployed, with no app store review in between. A native mobile app earns its extra cost when the product needs deep access to the phone (background location, the camera all day, long offline use) or a place on the customer's home screen that a browser bookmark will not give it.
Either way, the phone is where most people will meet the app. Mobile devices account for 58.99% of web page views worldwide (StatCounter, September 2026), so a customer-facing web app is designed for the small screen first. An internal tool used at a desk can start from the desktop.
Types of web applications and the challenges each one brings
Developers sort web apps by how they are built: single-page, progressive, server-rendered. For planning and budgeting, the more useful split is by what the app does for the business, because each kind tends to get hard in its own place. The matrix shows where, in our experience, the effort and the risk usually go.
Customer portals and self-service apps
Client portals, patient portals and account areas let customers check orders, download invoices or file a claim without phoning anyone. The screens are rarely the hard part. The data behind them lives in the ERP, the CRM and the billing system, and most of the budget goes into integration: fetching that data, keeping it consistent and deciding what the portal shows when one of those systems is down. Sign-in, user roles and accessibility come close behind.
E-commerce and marketplaces
A standard online shop is a product category, and a hosted commerce platform will usually serve it for less than a custom build. Custom web application development pays off when pricing, stock or the marketplace logic is what sets the business apart.
Then the hard parts are peak load, payments and live data.
For Mennica Skarbowa, a Polish precious-metals distributor, we built a real-time pricing engine that follows the gold price intraday and sends prices to every web store and physical shop from one place, because in a low-margin business a late price is a lost margin. Card payments go through a payment provider, so card data never touches your servers; the payment integration guide covers the options.
SaaS products
A software-as-a-service product is a web app sold by subscription to many customers at once. It adds multi-tenancy, which means keeping each customer's data apart on shared infrastructure, plus subscription billing, self-service onboarding and an uptime promise in every contract. Larger customers will also send security questionnaires before they sign. The guide to starting a SaaS company covers the business side.
Internal tools and workflow apps
Quoting tools, approval flows, scheduling and back-office dashboards replace spreadsheets and email chains. Load is rarely a problem, since the users are your own staff. Adoption is. The process written in the manual is seldom the process people follow, and if the new tool is slower than the old spreadsheet for even one common case, people go back to the spreadsheet. Watch the real work before designing the screens.
Data-heavy and real-time platforms
Search, booking, pricing and analytics platforms answer many requests over large data sets, often within a second. Their challenge is speed and the cost of keeping it as volume grows, which we come back to under planning for scale.
Single-page, multi-page and progressive web apps
These labels describe delivery, and each has a business consequence.
A single-page app loads once and then feels like desktop software, which suits tools people use all day behind a login. A multi-page app loads a new page on each click, which is simpler and easy for search engines to index, so it suits public catalogues and content. Modern frameworks mix the two: public pages rendered on the server for search, the logged-in part as a single-page app.
A progressive web app (PWA) can be installed on a phone's home screen and keep working with a weak connection. The GIS-based project management system we built for a real estate management company uses one for field survey work, where signal is not guaranteed.
The web application development process, from idea to launch
Most web app projects pass through the same stages, whatever the methodology on the contract. The roadmap shows the typical durations for a first release of moderate scope in our projects: about six to eight months from the first conversation to launch. Heavy integration or a regulator's approval adds to that.
The guide to custom software development explains each stage in detail. Here is what the business side does at each one.
Start with the business case, not the feature list
Write one page before talking to any developer: who will use the app, which number it should move (time to quote, calls to support, orders per visitor), what that is worth a year, and the budget range you can defend. Then name the riskiest assumption, the one that would sink the project if it proved wrong, such as "customers will upload their own documents". The first release should test it. A minimum viable product is the cheapest way to do that.
Discovery and design: turning the idea into a scope and a price
In discovery, an analyst and an architect interview the future users, map the systems the app must talk to and write down the scope, including what is deliberately left out. You should leave with a written ballpark estimate with its assumptions, and that is the moment for a go or no-go decision.
Design then produces a clickable prototype that real users try before any code is written, since moving a button in a prototype takes an afternoon and moving it after the build takes a sprint. The architects set targets for response time, peak load and availability as numbers the team can test against.
Building the first release in weekly increments
The build takes most of the time and money. Insist on seeing working software every week, deployed to a test environment, rather than a status report. The hardest integration and the main user journey go first, while there is still time to fix what they reveal.
Your side needs a product owner: one person who can make a scope decision within a day and say no to new features. Before launch, your own staff run real scenarios in acceptance testing, and somebody has to clear time in their calendars for it.
Cost follows from the roadmap: team size, multiplied by months, multiplied by the rate. A team of five or six for six months is roughly 30 to 36 person-months, and the custom development guide shows how to compare quotes on that basis.
Launch is the start of the app's working life
Release to a pilot group, one region or a share of traffic first, with monitoring and analytics already running. The first weeks of real use produce a more useful backlog than any workshop, because it comes from people doing their jobs.
Good practices for web application development projects
The projects that run smoothly share a few habits on the client side as well as the vendor's:
- One named product owner who can decide scope quickly and has the time to do it.
- A demo of deployed software every week or two, so progress is something you can click.
- Performance and availability written as numbers, such as a page that loads in under two seconds on a mid-range phone, and tested before launch.
- Analytics and error monitoring in the first release, so decisions after launch rest on data.
- Security and accessibility checked for every feature as part of "done", not left for a phase at the end.
- A short decision log recording why the big choices were made, for whoever inherits the app.
Five traps in web application development, and how to avoid them
The troubled projects we are asked to rescue rarely failed on technology. Most fell into one of these.
Scope creep
New ideas arrive the moment people see working software, and many of them are good. The trap is adding them without a price. Keep a written list of what is out of scope, have every change estimated before work starts, and hold the launch date while moving the extras to a second release. Then every addition to the budget is a decision somebody made.
Vendor lock-in
Lock-in comes from three places: a proprietary platform or low-code tool you cannot leave without a rewrite, an agency's in-house framework only its own developers know, and heavy use of one cloud provider's specialist services. Some of it is a fair trade; a managed database saves real work. Accept it knowingly. Prefer open, widely used frameworks and standard databases, keep the infrastructure described in code so it can be recreated elsewhere, and put an exit and handover clause in the contract.
Code and accounts you do not own
The portal in the opening paragraph is the common case.
The source code, the repository, the cloud accounts and the domain should be registered to your company, with the developers given access, never the other way round. The contract should assign the intellectual property to you on payment. Check this before signing, because after launch it becomes a negotiation.
Security and compliance left until the end
Software vulnerabilities are now the most common way in.
In Verizon's 2026 Data Breach Investigations Report, exploitation of vulnerabilities became the most common way into an organization, at 31% of breaches, up from 20% a year earlier, and a third party was involved in 48% of breaches, up from 30%. The average breach now costs $4.99 million, a record and 12% more than a year before, according to IBM's Cost of a Data Breach Report 2026, a study run with the Ponemon Institute by a company that sells security services.
Compliance arrives on the same schedule.
Personal data of people in the EU falls under GDPR. Card payments bring PCI DSS, and EU financial firms have answered to DORA since January 2025. The European Accessibility Act has applied since 28 June 2025 to services such as e-commerce, banking and passenger transport, with an exemption for service businesses with fewer than 10 employees and under EUR 2 million in turnover (Your Europe). Each is easier to design in than to retrofit. Ask for a threat model in the design stage, automated scans of the code and its libraries on every change, and a penetration test before launch; our secure Java guide shows what that looks like in practice.
No budget for maintenance
A web app runs on frameworks, libraries and cloud services that ship security fixes every month, and somebody has to apply them. Organizations are slow at it: in Verizon's 2026 report, only 26% of critical, actively exploited vulnerabilities were fully fixed in 2025, and the median fix took 43 days. Agree a yearly running budget before launch, covering hosting, monitoring, updates and small improvements, and name who owns the app once the build team moves on. The software maintenance process guide compares the models.
How to make a web app future-proof
Nobody can predict what a business will need from its web app in five years. The realistic aim is an app that a new team can understand, change and scale without starting again. Eight checks cover most of it.
An architecture that can change
For most first releases, a well-structured single application, split into clear modules, is cheaper to build and run than a set of microservices. A module can be moved into its own service later, when it needs to scale or ship on its own schedule. Put an API between the screens and the business logic from the start, so a mobile app, a partner or an AI assistant can use the same functions later without a rebuild.
A mainstream, well-supported stack
Choose technologies that many developers already know.
In the 2025 Stack Overflow Developer Survey, PostgreSQL is used by 55.6% of respondents, Node.js by 48.7% and React by 44.7%, and Spring Boot, the Java framework we use for most of our systems, by 14.7%. A mainstream stack means a wide hiring pool, years of security fixes and answers to most problems already written down. A niche framework, however elegant, ties the app to the few people who know it.
Tests and documentation that outlive the team
Automated tests are what let a new developer change the code on a Monday without breaking something on Tuesday. Documentation does not need to be long: an architecture overview, how to build and deploy the app, and the decision log. Ask for both in the contract. The types of software testing guide explains which tests to expect.
Planning for scale without overbuilding
Write down the volumes you expect in year one and year three (users, orders, searches at peak) and have the app tested against the second figure before launch. There is no need to build for a hundred times today's traffic on day one, as long as the architecture leaves a way to grow.
A UK hotel metasearch engine shows what happens when it does not. Its database cluster had stopped scaling: another server added about 2% to the cost and 0.1% to the throughput. After we moved availability search into an in-memory data grid, the engine served 300 million queries a day, 50% more traffic, with response time down 60% and infrastructure cost down 80%.
Leaving room for AI features
The AI features businesses ask for most are practical: search in plain language, summaries of long documents, assistants for support staff, sorting incoming requests. They depend on things a web app either has or lacks: clean data with a clear owner, APIs to reach it, and logs of what happened. Keep the AI model behind your own interface, so you can switch providers, and keep a person in the loop wherever a wrong answer costs money or breaks a rule.
Developers are cautious too.
In the 2025 Stack Overflow survey, 84% use or plan to use AI tools, yet 46% distrust the accuracy of what those tools produce, against 33% who trust it. Ask any team you hire how they review AI-written code; our AI integration work starts from the same rule.
Hiring web developers: in-house team, freelancers or a software house
Once the business case holds, somebody has to build the app. There are three ways to get the people, and many companies end up combining them.
| Factor | In-house team | Freelancers | Software house |
|---|---|---|---|
| Time to start | Months: recruiting comes first | Days to weeks | Weeks: the team already exists |
| Cost structure | Salaries, benefits and tooling, whatever the workload | An hourly or daily rate per person | A team rate against a written estimate |
| Range of skills | The people you hired | One person, one skill set | Specialists brought in for the weeks they are needed |
| Continuity | Strong while people stay | Weak: a freelancer can leave mid-project | The company replaces people and keeps the knowledge |
| Your management load | High: you run the team | High: you coordinate every person | Lower: the partner runs delivery, you own the product |
| Best for | Software that is your product for years | A defined piece of work with an internal lead | A first release, a rebuild, or capacity your team lacks |
An in-house team makes sense when the web app is your product and will need developers for years; the cost is months of recruiting before the first release. Freelancers work well for a defined piece of work, such as a design system or a single integration, when someone on your side leads the technical decisions. A software house brings a team that has worked together before, starts in weeks and adds specialists in security, performance or cloud for as long as they are needed.
A common pattern combines the routes: a software house builds the first release while you hire, then hands over a documented app to your own team or stays on for support. If you are hiring directly, our guide to hiring full stack developers covers what to test for. If you are comparing partners abroad, software development in Poland covers rates and the talent pool, and the custom software development guide lists the checks to make before signing.
Stratoflow is a software house in Poland that has built and modernized business-critical Java systems since 2013. Our engineers are direct employees, we do not subcontract, and attrition is 7%, so the architect who scopes a web app stays on it. After a scoping call you get a written ballpark with its assumptions, then working software every week, with the code in your repository from the first commit. When a hosted platform would serve you better than a custom web app, we say so. If you have an idea that needs a web application behind it, book a thirty-minute call and leave with a view of scope, price model and whether we are the right team to build it.