Web Applications That Still Work on the Day You Have Real Users
Dashboards, customer portals, member areas, internal tools and progressive web apps — built with logins, roles and data volume treated as the job rather than as an afterthought.
- Fixed-price first version
- Your cloud account, your code
- Tested on real devices
A Website Shows Things. A Web Application Does Things.
On a website every visitor sees the same page. In a web application the page depends on who is logged in, what they are allowed to see, and what they did last week. That one difference brings accounts, permissions, saved state, audit history, search, exports and an admin view with it — and those are where the budget goes. The screens are the visible ten percent.
It is also why a quote for “a site with a login area” and a quote for a portal can differ by a factor of five without either being dishonest. Before we price anything we establish how many roles exist, what each one may do, and how much data will be flowing through in year one.
How we scope a first versionSix Shapes of Web Application
Most projects are one of these, or two of them joined together.
Dashboards & Reporting
Operational numbers pulled from several systems into one screen, with filters, date ranges and exports people actually use.
Customer Portals
Where your clients check status, download documents, raise tickets and pay invoices instead of emailing your team to ask.
Member Areas
Gated content, courses, community and subscriptions, with the access rules enforced on the server rather than hidden in the interface.
Internal Tools
The replacement for the shared spreadsheet that four people edit at once and nobody dares to sort.
Workflow & Approval Apps
Requests that move through stages, get approved or rejected, notify the right person and leave a trail you can audit later.
Progressive Web Apps
Installs to the home screen, works offline, sends push notifications — without two native codebases to maintain.
What Sits Behind the Screen You See
The same four layers appear in almost every web application we build. Knowing where each one lives is what makes the thing maintainable by someone other than the person who wrote it.
The interface itself. Renders screens, validates input for convenience, and holds only what the current session needs.
Sessions, permissions and the business rules. Every rule the browser enforces is enforced here again, because anything in the browser can be bypassed.
One documented contract that the web front end, a future mobile app and any integration all use. Built once, not duplicated per client.
The part that is hardest to change later. Indexed for the queries the application really runs, backed up daily, restore tested rather than assumed.
Background jobs, file storage and a cache attach alongside the application layer as the product needs them. We explain the API layer in more depth on the backend and API page.
Logins Are Easy. Permissions Are Where Products Break.
Signing a user in takes a day. Deciding what each one may see, and enforcing it everywhere, is a design decision with consequences for years.
What we set up as standard
- Email and password with proper hashing, plus optional Google or Microsoft sign-in
- Password reset, email verification and session expiry that does not log people out mid-task
- Two-factor authentication where the data justifies it
- Roles defined up front — owner, admin, staff, read-only, customer — not invented as you go
- Every permission checked on the server, not merely hidden in the interface
- An audit trail of who changed what and when, for the argument you will eventually have
The questions we ask before writing any of it
- Can one person belong to more than one organisation or team?
- Does an admin need to view the application as another user in order to support them?
- Who can invite new users, and does an invitation need approving?
- When someone leaves, is their account deleted or deactivated, and what happens to their records?
- Are there records only some people in the same role may see?
- Will you ever need single sign-on because a customer demands it?
Answering the last question early is much cheaper than answering it in year two. Retrofitting a permission model into a live application means touching almost every screen.
The Demo That Dies at 10,000 Rows
This is the single most common reason a handed-over web application has to be partly rebuilt. It works beautifully in the demo and grinds to a stop four months after launch.
Everything loads at once
The list screen fetches every record and the browser filters them. Sorting happens in JavaScript. Each row triggers another query for its customer name. Nobody notices, because the test database has forty rows in it.
- At 200 rows
- Fine
- At 10,000 rows
- Unusable
The server does the work
Pages of results, searching and sorting in the database, indexes on the columns actually filtered, related records fetched in one query, heavy exports pushed to a background job, and a cache in front of the reports that are expensive to build.
- At 200 rows
- Fine
- At 10,000 rows
- Still fine
Illustrative comparison of two common implementation approaches — not measurements from a specific client project.
Before launch we seed the database with a realistic volume of data — the amount you expect after a year, not the amount you have on day one — and click through the slowest screens with it loaded. It takes a couple of days. It is the cheapest insurance in the whole project, because the alternative is rewriting those screens later while users are already depending on them.
Responsive Is Not a Checkbox at the End
Designed narrow first
Every screen is drawn at phone width before desktop. Layouts that are built the other way round end up with a horizontal scrollbar and a squeezed table that nobody can read.
Tables become lists
A twelve-column table cannot be made readable on a 390px screen by shrinking it. On small screens the same data becomes stacked cards showing the three fields that matter, with the rest one tap away.
A named browser list
Current and previous Chrome, Edge, Safari and Firefox, plus mobile Safari and Chrome on Android. Written into the scope so “it looks wrong on my machine” has an agreed answer.
When a PWA Replaces a Native App, and When It Does Not
A progressive web app is a web application that installs to the home screen, runs full screen, works offline and can send push notifications. One codebase instead of three.
Field and operations tools
Staff need it on a phone with patchy signal, you control the rollout, and nobody finds it by browsing an app store.
Portals and dashboards on the go
Users who mostly work on desktop but want the same thing on a phone occasionally, without a separate download.
Hardware and background work
Bluetooth devices, background location tracking, health data, widgets, or heavy camera and sensor use.
Store presence is the channel
If people are meant to discover you by searching the App Store, or in-app purchase is your billing route, a PWA does not get you there.
Where It Runs, and Who Holds the Keys
Your Account
The cloud account is created in your name and billed to your card. We are added as collaborators and can be removed in one click.
Two Environments
A staging copy for you to try things on and a production one for real users, so nothing is ever tested on live data by accident.
Deploy on Push
A pipeline runs the test suite and ships the build. No developer copying files onto a server at midnight, and any release can be rolled back.
Backups & Alerts
Daily database backups with a restore we have actually tested, uptime checks, and error reports that reach a human rather than a log nobody reads.
For most applications at launch the monthly hosting bill is tens of dollars rather than hundreds. We size it for what you actually need and write down what each line item is for, so the number is never a mystery.
When a Web Application Is the Wrong Answer
Telling you this before the contract costs us a project occasionally. Telling you after costs you a great deal more.
From First Call to Live Application
Week 0 — Scoping
We map the roles, the screens each one needs and the data behind them, then come back with a fixed price and a week-by-week plan. Nothing starts until you have that in writing.
Weeks 1–2 — Design & schema
Clickable screens for you to sign off, and the database design agreed at the same time. These two together settle most of what the application will cost to change later.
Weeks 3–10 — Build in sprints
Two-week sprints, each ending in a demo build you can log into yourself. A written update lands at the end of every working day and we reply to anything you raise within one business day.
Before launch — Load and browser pass
Seeded data at realistic volume, the slow screens profiled and fixed, the browser and device list worked through, and a security review of permissions and sessions.
Launch — and the week after
Production deploy, monitoring and backups switched on, credentials and documentation handed over. We watch the error reports closely during the first week, because that is when real usage finds what testing did not.
Web Application Questions
What is the difference between a web application and a website?
A website shows you information. A web application does work for you — it has accounts, it stores and changes data, and what you see depends on who you are. That difference is why a brochure site can be built in days while a portal with logins, roles and reporting takes weeks: almost all of the effort sits behind the screens rather than in them.
How much does a web application cost to build?
Most first versions land between roughly $12,000 and $60,000. The number moves with how many distinct user roles there are, how much of the data has to be reported on, and how many outside systems it has to talk to. A single-role internal tool sits near the bottom of that range and a multi-role customer portal with billing sits near the top. The cost calculator gives you an indicative figure in about a minute.
Will the application work properly on a phone?
Yes. Every screen is built mobile-first and tested on real devices rather than a resized desktop browser. Dense tables are the honest exception: on a phone they become cards or a filtered list rather than a table you pinch and scroll sideways, because a shrunken spreadsheet is unusable on a small screen.
Which browsers do you support?
The current and previous versions of Chrome, Edge, Safari and Firefox on desktop, plus Safari on iOS and Chrome on Android. If some of your users are on something older — an internal tool used on locked-down machines, for example — say so before we start, because it changes which technologies we can use and it is expensive to retrofit.
Can a progressive web app replace a native mobile app?
Often, yes. A progressive web app installs to the home screen, works offline and can send push notifications on both Android and iOS, and it costs far less than building and maintaining two native apps. It is the wrong choice when you need Bluetooth or other specific hardware, background location, deep integration with the phone, or when being in the App Store is itself part of how you get users.
What happens when the data grows past what the demo handled?
That is the failure we design against from the start. Screens are paginated, lists are searched and filtered on the server rather than in the browser, the database is indexed for the queries the application actually runs, and we test against a realistic volume of seeded data before launch rather than the twenty rows a demo uses. Fixing this after launch usually means rewriting the screens that broke.
Who hosts the application and what does hosting cost?
You do, in your own cloud account created in your name on day one. For most applications at launch the monthly bill is modest — usually tens of dollars rather than hundreds — covering the application server, a managed database and backups. We set it up, document it and hand over the credentials. There is no hosting markup and nothing is tied to us.
Often Part of the Same Project
SaaS Product Development
When the web app is the product and customers pay for it monthly, multi-tenancy and billing come with it.
Learn moreBackend & API Development
The API layer in the diagram above, in detail — schema design, integrations, queues and rate limits.
Learn moreAnalytics Dashboards
When the whole point is reporting across several systems rather than day-to-day data entry.
Learn moreTell Us What the Application Has to Do
Describe the roles and the screens you have in mind — we will come back with a realistic scope, timeline and budget range within two business days.