So my web app is built, what next? (2026 guide)

The build being finished is not the finish line. Once your web app or website is working, the next steps fall into four groups: make it safe to run in public (hosting, backups, monitoring, security), make it measurable (analytics and error tracking), make it supportable (who fixes things, and how quickly), and make it earn its keep (pricing, marketing and a plan for the next set of changes). Work through them in that order. In our experience, a good number of the post-launch problems we are called in to fix come from skipping the first group and going straight to the fourth.

This guide sets out what each of those stages actually involves, what it tends to cost in time and attention, and which decisions are worth making before you tell anyone the app exists.

Step one: make it safe to run in public

An app that runs on your laptop and an app that runs in front of paying customers are different things. Before you announce anything, the following need to be settled.

Hosting and environments. You want at least two environments: one live, one staging that mirrors it closely enough to be worth testing on. Deploying straight to live is fine for a hobby project and a slow disaster for a business. We have written separately about where web apps are best hosted and the trade-offs between managed platforms and your own servers.

Backups you have actually restored. A backup you have never tested is a hope, not a backup. Restore one into staging and confirm the data comes back intact. Do this before launch, then on a schedule.

Domains, DNS and certificates. Confirm who owns the domain (it should be you, not a former contractor), that the SSL certificate renews automatically, and that both the www and non-www versions resolve to the same place.

Security basics. Dependency updates, sensible password and session handling, rate limiting on anything public, and no secrets committed to the repository. If you are handling personal data you also have UK GDPR obligations from day one, not from the point you get big enough to notice. Our guide on building a secure web app covers the practical checks.

Access and ownership. Make sure you hold the accounts: source control, hosting, domain registrar, payment provider, analytics. When we take over an existing product, missing credentials are one of the most common causes of delay.

If your app was built quickly with AI coding tools, this stage deserves more attention rather than less. We keep a specific production checklist for vibe-coded apps, because we tend to see the same failure patterns: no tests, no error handling, database access wide open, and secrets sitting in the front end.

Step two: make it measurable

You cannot improve what you are not watching. Three separate things need instrumenting, and people routinely confuse them.

What you need	What it tells you	Effort involved
Uptime monitoring	Whether the app is up, and who gets woken when it is not	Quick to set up, largely off the shelf
Error tracking	What is breaking, for whom, with a stack trace	A short piece of work, mostly configuration
Product analytics	Which features get used, where people give up	Materially longer, because the event design takes thought

Uptime monitoring is the cheapest insurance you will ever buy. Error tracking matters because most users do not report bugs, they just leave. Analytics takes real thought, because it is only useful if you decide in advance which handful of events represent progress: sign-up completed, first project created, invite sent, subscription started. Five well-chosen events that you look at weekly beat two hundred that nobody opens.

Step three: decide who supports it, and how fast

This is the question founders most often postpone. Software is never finished: browsers change, dependencies get patched, integrations alter their APIs, and users find edge cases you did not imagine. Somebody has to deal with that.

There are three realistic options.

• In-house. Sensible once you have enough work to keep a developer busy and enough process that they are not the only person who understands the system.
• Retained agency or development partner. You buy a block of hours a month covering updates, monitoring and fixes. Predictable, and you are not carrying employment overhead. UK agency rates generally sit between £75 and £150 per hour.
• Ad hoc. You call someone when it breaks. Cheapest on paper, most expensive when the break happens at a bad time and nobody is familiar with the codebase.

Whichever you pick, agree a response expectation in writing: what counts as critical, how quickly someone starts work, and what happens outside office hours. Budget for ongoing work as a real line item rather than an occasional surprise, and expect the figure to rise with the number of integrations you depend on.

Documentation belongs here too. A short README covering how to run the project, how to deploy it, what the environment variables are, and where the third-party accounts live will save you far more than it costs to write.

Step four: pricing, if you are selling it

If the plan is to turn the app into a subscription business, pricing is a product decision rather than a spreadsheet exercise. A few things hold true fairly consistently.

Subscription pricing suits software that is continually improved, because the revenue continues alongside the cost of maintaining it. Two or three tiers are usually enough: a starting tier that solves one clear problem, a main tier that most customers will buy, and a larger tier for organisations that need more seats, more volume or more control.

Pick a metric that grows with the value your customer gets, whether that is users, transactions or storage, so that customers who get more out of the product pay more without feeling penalised. Then look at what retention is actually worth to you: our guide to calculating customer lifetime value sets out the arithmetic, and it will tell you far more about whether the business works than any competitor’s price list.

Expect to change your prices. Launch pricing is a hypothesis, and the first ten paying customers are the experiment.

Step five: the first ninety days

Once the app is live, your job shifts from building to learning. A pattern that works well:

Weeks 1 to 2. Watch the error tracker daily and fix what appears. Talk to every early user personally. Do not add features yet.

Weeks 3 to 6. Look at where people stop in your analytics funnel. The most valuable early work is almost always removing friction from onboarding rather than adding capability at the far end of the product.

Weeks 7 to 12. Now start on new features, chosen from what you have learned rather than what was on the original wish list. Keep a visible roadmap so that the decisions are deliberate; we have written about building a product roadmap for SaaS if you want a structure for it.

Marketing runs alongside all of this. Sort out the basics first: a landing page that explains what the product does in a sentence, working analytics, indexable pages, and one channel you commit to properly rather than five you dabble in.

Frequently asked questions

What should I do immediately after my website or web app is built?

Before you tell anyone about it, secure the foundations. Confirm you own the domain and all accounts, set up a staging environment separate from live, take a backup and test restoring it, install uptime monitoring and error tracking, and check that SSL and dependency updates are handled. Then add analytics for a small number of meaningful events. Announcing a product before these are in place is how small problems become public ones.

How much does it cost to maintain a web app after launch?

It depends on complexity, the number of third-party integrations and how quickly you need problems fixed. A simple app with few integrations may need only occasional attention, whilst a live SaaS platform with paying customers needs continuous monitoring, security patching and improvement work. UK agency rates typically fall between £75 and £150 per hour, and most businesses find a retained monthly block more predictable than paying for emergencies as they arise.

Do I need to keep updating my app if nothing is broken?

Yes. Dependencies receive security patches, browsers and mobile operating systems change, and third-party APIs are deprecated on their own schedules rather than yours. An app left untouched for a year is usually not stable, it is quietly accumulating vulnerabilities and breaking integrations. Regular small updates are considerably cheaper and less disruptive than the large remedial project that follows years of neglect.

How do I turn my web app into a SaaS business?

Add the commercial layer: subscription billing, user accounts with roles and permissions, tenant separation so one customer’s data cannot reach another’s, and self-service sign-up. Then decide on two or three pricing tiers based on a value metric that grows with usage. The technical work is usually smaller than the operational work of support, billing disputes, onboarding and retention, so plan for both.

Should I add more features or improve what I have?

In the first six weeks, improve what you have. Early users abandon products because of confusion and friction far more often than because of missing capability. Watch where people stop in your onboarding funnel and fix that first. Once you have customers who use the product regularly and can tell you what they need next, feature work becomes a much better investment because it is informed rather than speculative.

Who should host my web app, me or my developer?

Host it under accounts you own, even if your developer manages them day to day. Agency-owned hosting and domains are one of the most common reasons businesses get stuck when they want to change supplier. Give your development partner administrative access rather than ownership, keep the billing on your card, and make sure you can retrieve the source code and database yourself at any point.

Where to go from here

If you have an app that works and you are deciding what happens next, we are happy to look at it. We support and extend live products as well as building them from scratch, including apps that other people built. Our web application development and SaaS development pages set out how we work, and if you are budgeting for the next phase the cost estimator will give you a realistic range in a couple of minutes. Otherwise, get in touch and tell us where you have got to.