For browser software that has to behave, not just load
Web Application Development
A website that only needs to display information is a simpler build than one that has to remember who is logged in, keep data current, and stay usable on a bad connection. This practice exists for the second kind: browser software judged by whether it behaves correctly under real, messy, concurrent use.
What separates an application from a website
State, freshness and offline behaviour, walked through against real, concurrent use.
90 secSample frame · video pending01Before any component ships
Is this a website problem or an application problem?
Most complaints about a build feeling slow are actually state or data problems wearing a performance costume. Four questions separate a genuine application gap from a display issue a simpler fix would solve.
Does a refresh lose anything the user cares about?
If a reload silently discards form data or scroll position, that is a state problem, not a rendering one. Users notice this immediately, even when they cannot name it.
Do two users ever see different truths?
Stale or conflicting data between concurrent users signals a freshness gap that a faster server will not fix by itself.
Does the application assume a fast, constant connection?
Real users carry old phones and patchy networks. An application that only works well in the office is missing a real share of its own users.
Is access control enforced in more than one place?
Authentication checked only in the interface is not authentication. The server has to agree with the screen, every time.
| Website | Application | |
|---|---|---|
| State after a refresh | Resets to a default | Preserved as the user left it |
| Data freshness | Whatever loaded last | Deliberately live or explicitly cached |
| Offline behaviour | Blank or broken | Degrades to something usable |
| Access control | Often interface-only | Enforced on the server, every time |
02Agreed before any code
The ledger that keeps a web build honest
Web builds drift when working on a single machine quietly becomes the actual bar for done. This ledger sets what you bring, what gets built, what comes back, and what stays yours regardless of engagement shape.
- Your side
You bring
- The current build and the workflows it should support
- Examples of where state or session breaks today
- Any users already tolerating the current behaviour
- Our side
We build
- Client-side state management fitted to the real workflow
- Session and authentication that survives a refresh correctly
- Data fetching that feels live instead of reloaded
- Your side
You receive
- An application that holds state the way users expect
- Authentication that behaves correctly across tabs and sessions
- A codebase your team can extend without relearning it
Never leaves you
- Product direction and every workflow decision
- The user relationships already built on the current version
- All intellectual property from the first commit
Where the line sitsA website is display. An application is state, session and memory. Moving from one to the other is real engineering, not a redesign.
03From a symptom to working behaviour
Four stages, each closing on evidence you can test
Applications that behave badly usually skipped a stage here quietly. This system closes each one with something you can click through yourself, not a status update.
Diagnose what is actually breaking
State, freshness, offline behaviour or access control get separated from each other, because the fix for one rarely fixes another.
The real symptom named plainlyChoose the pattern that fits the workflow
How state is held, how data refreshes and how much offline behaviour is worth building get decided against your actual users.
A decision you can defend laterBuild and test under real conditions
The application is exercised on slow connections, with multiple concurrent users, before anyone calls the behaviour fixed.
Behaviour you can test yourselfHand over the patterns, not just the code
Your team receives the reasoning behind every state and data decision, so the next feature follows the same discipline.
A system your team can maintain
04What actually drives the number
Four drivers, not a flat per-page rate
Web application work is priced against the assessment, because these four factors change effort well beyond a simple page count.
How much state the application actually holds
A form with five fields costs less to get right than a workspace holding dozens of interdependent values.
How fresh the data genuinely needs to be
Near-real-time updates cost meaningfully more to build and operate than data that only needs to refresh every few minutes.
How much offline behaviour is worth building
Full offline support is expensive. Graceful degradation for the parts users actually hit offline usually costs far less.
Depth of access control required
Role-based access across many resource types costs more to build and test than a single shared login.
05Evidence and proof
Applications that finally behaved the way users expected.
Web application proof is behaviour that held up under real, concurrent, imperfect use. Every record here is placeholder proof awaiting the client's written sign-off.
Explore case studies
A dashboard that looked live was actually an hour behind.
Nexa Foundry's floor managers made decisions on production data that quietly lagged behind reality. A freshness strategy closed the gap without rebuilding the dashboard from scratch.
- Data lag
- From roughly an hour to near-live
- Rebuild required
- None
An application that broke every time a clinician's connection dropped.
Koru Health's clinicians worked from hospital wifi that dropped constantly, and the application lost their notes every time. Graceful offline handling stopped the data loss without changing how clinicians worked.
- Data loss incidents
- Eliminated
- Clinician-reported friction
- Substantially reduced
Our dispatchers were looking at data that was already wrong by the time they acted on it. Nobody had named that as the actual problem before.
Sample · pending client approval
06Read this first
When web application engineering is the wrong starting point
Building full application behaviour for a page that only needs to display information spends budget nobody asked for. Three honest exits route straight past this practice when a simpler build already fits. When application work is genuinely justified, it runs on React, Next.js and Node, with Postgres and cloud infrastructure underneath.
- Application development
The platform itself is still undecided
If web, mobile or another shape has not been chosen yet, that decision belongs earlier, before any application patterns get built.
- SaaS development
The product is a multi-tenant subscription business
Billing, plan gating and tenant isolation are a distinct discipline from making one application behave correctly.
- Hire Developers
Your team already owns the architecture
If the state and data patterns are already decided, adding engineers into that decision moves faster than a new build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The behaviour gap is well understood | Priorities and acceptance | State, data and delivery |
| Delivery pod | The workflow will evolve with real use | Product decisions each cycle | Engineering, quality and releases |
| Team extension | Your architecture is already decided | Standards and review | Named engineers and continuity |
07Straight answers
Asked before an application build starts.
01How is this different from application development?
Application development helps decide which platform to build on. This practice starts once web is already the answer, and focuses on making the browser build behave like software.
02Do you build single-page applications or traditional websites?
Both, depending on what the workflow actually needs. The architecture follows the state and data requirements, not a default preference for one pattern over another.
03What frameworks do you use for state management?
React with modern state libraries most commonly, chosen against how much state the application actually holds rather than habit. The pattern is scoped to the workflow, not assumed upfront.
04Can you fix an existing application instead of rebuilding it?
Yes, and this is the more common request. Diagnosing whether state, freshness or offline behaviour is the actual gap usually avoids a full rebuild entirely.
05How do you handle authentication and access control?
Access is enforced on the server, never only in the interface, regardless of how the login screen looks. Role and permission logic is tested independently of the front end.
06What does a web application build cost?
Cost is priced against how much state the application holds, how fresh the data needs to be, and how much offline behaviour is worth building.
07Is this the right practice for a multi-tenant SaaS product?
Not on its own. A subscription product with billing and tenant isolation needs the SaaS development practice, which handles that as a distinct discipline.