A web app is software that runs in the browser, with no download and no app store. For a lot of ideas it does everything a mobile app would, for less, and it updates the moment you push a change.
This is the decision that saves or wastes the most money, and it gets made too late on most projects. The two do different jobs. Getting it right up front matters more than anything about the build itself.
Runs in the browser
Opened through a link, on a laptop or a phone, with nothing to download. One codebase serves everyone and every update is live immediately.
The right call when
Installed from the store
Downloaded onto the phone, with an icon on the home screen. Slower to change, but it reaches parts of the device a browser cannot.
The right call when
If your list sits mostly in the right-hand column, a web app is the wrong spend and we will say so. The honest version of this page recommends a mobile app when that is what the idea needs, and points you to cross-platform app development when you want both without building the same thing twice.
Almost always something people log into and use, rather than something they read. If your idea fits one of these shapes, the browser is a natural home for it.
The screen your team lives in all day. Numbers, records, controls, and everything in one place instead of five browser tabs and a spreadsheet.
A logged-in area where your customers see their account, their orders, their documents, or their progress. Fewer emails to your team, more self-service for them.
Software you charge people to use, month after month. Sign-up, subscriptions, user accounts, and the core tool that makes it worth paying for.
The thing your business runs on that no off-the-shelf product quite fits. Built around how your team actually works instead of forcing the work to fit the software.
Two sides meeting in the middle. People listing and people buying, or people offering time and people booking it, with the matching and payments handled underneath.
Something that takes in a lot of information and makes it useful. Reporting, tracking, calculations, or anything where the value is in turning raw data into a clear answer.
A website is mostly pages to read. A web app has moving parts underneath, and knowing the parts helps you see where the work and the cost really sit. Here is the whole thing, top to bottom.
Everything the user sees and clicks. This is the part people judge, and the part that has to stay simple even when the app behind it is not.
The rules that decide what happens. Who can do what, what a button actually does, how one action affects another. Most of the real work lives here, out of sight.
Where everything is stored and how it is organised. Get this right early and the app can grow. Get it wrong and every later change fights the structure it started with.
Logging in, and controlling who is allowed to see and do what. An admin, a paying customer, and a free user are three different sets of permissions to get right.
The hosting and setup that keeps it online, backed up, and quick as more people use it. Quiet when it works, and the first thing you notice when it does not.
You do not need to understand any of this to work with us. It is here so that when we talk about why one feature is a week and another is a month, it makes sense. The layers that hide underneath are usually where the time goes, and where a build that looks simple turns out not to be.
Two web apps that sound the same in a sentence can differ wildly in price. It is rarely the number of screens. It is these things, and knowing them lets you shape the budget instead of being surprised by it.
One type of user is straightforward. An admin, a customer, and a team member each seeing different things is three apps sharing a login, and roughly three times the thinking.
A page that loads when you open it is simple. Something that updates the instant someone else changes it, like a chat or a live feed, is a different and heavier kind of build.
Every outside service it talks to, payments, email, a CRM, a shipping tool, is a connection to build and maintain. A few are normal. Many is where scope quietly grows.
A few thousand records behaves differently to a few million. If it needs to stay quick at scale, that gets designed in from the start rather than patched on when it slows down.
The cheapest way to control the cost is to build less at first. We would rather ship a focused first version, watch how it gets used, and add from there, than quote a large number for features that turn out not to matter. If you are testing an idea rather than replacing a working system, that is closer to MVP development.
In working slices, not one long silent stretch. You see it running early and often, so nothing is a surprise at the end.
We map who uses it and what they need to do, and agree the shortest path through each of those before any design starts.
Screens for the real flows, not decoration. You approve how it looks and works before it is built, when changes are still cheap.
One working piece at a time, each one usable. You are never waiting months to see something you can click through.
Checked with the kind of information it will actually hold, and the edge cases that break things, before anyone relies on it.
Live, handed over, and documented. The code is yours, and we can stay on for changes and upkeep or step back cleanly.
If you are still weighing up web against native, or want both, the other paths sit right here. Same team, one conversation about which fits.
Related app services
A website is mostly there to be read. You visit, take in the pages, and maybe fill in a form. A web app is there to be used. You log in and do things: manage records, run a process, track something, work.
The line is roughly whether people accomplish tasks in it or just read it. If your team or your customers would spend real time inside it doing work, that is an app, and it is built differently underneath.
A web app if people use it at a desk as much as on a phone, if you want to change it often, and if budget matters. A mobile app if you need the camera or GPS as core, full offline use, or a home-screen presence that has to feel native.
Plenty of ideas that people assume need a mobile app work perfectly well in the browser. We would rather have that conversation with you before anything is built than after.
Yes. A web app is built to work across screen sizes, so the same app adjusts for a laptop, a tablet, and a phone. There is one thing to build and maintain, not a separate version per device.
If it also needs to be installable and open from the home screen like an app, that can be added on top. It is worth deciding early, because it shapes a few choices in the build.
Yes, fully. The code, the accounts, and everything the app runs on are yours. You are not locked into us to keep it working, and you can take it to another team whenever you want.
We hand it over documented, so whoever works on it next can find their way around. Being easy to leave is the point. It is why clients stay.
A focused first version is usually a couple of months. Something with several user types, live updates, and outside connections runs longer. The honest answer comes after we understand what it needs to do, not before.
Because we build in slices, you see working parts along the way rather than waiting for one big reveal at the end. That also means we can launch a useful first version and keep adding, instead of holding everything back until all of it is finished.
Yes, when it is built with that in mind, which is why the data and hosting decisions get made carefully at the start. An app designed for growth handles more users by adding resources, not by being rebuilt.
We do not over-engineer a small app for a scale it may never reach, because that wastes money too. The aim is a build that fits where you are now and has a clear path to where you are heading.
Thirty minutes on the idea, whether a web app is the right shape for it, and roughly what it would take to build.
Or email hello@culmen.digital