Service 02 — Web applications

Web applications
that behave like
software.

Static, dynamic, animated, portal or progressive — we create web application solutions that fit your needs, standards and expectations. Full-stack, server-side and browser-delivered, by one team.

What is included

  • Interface and design system
  • Application architecture
  • API and services
  • Performance budget
  • Offline and resilience
  • Accessibility to WCAG 2.1 AA

The browser is the platform

Almost everything we are asked for now runs in a browser: the internal tool, the customer portal, the dashboard the board looks at once a month. It is the only platform every user already has, on every device, with nothing to install and nothing to approve.

That convenience hides real engineering. A web application has to work on a five-year-old Android on hotel Wi-Fi and on a 4K monitor in the office. It has to keep state when the connection drops. It has to be fast enough that people stop reaching for the spreadsheet they were using before.

What we build front to back

Our full stack covers the interface, the services behind it, the database under those, and the infrastructure the whole thing runs on. There is no boundary in the project where one company hands to another and the performance problem becomes nobody's fault.

Deliverables

What you
actually get.

01

Interface and design system

Components, states and motion defined once, so the fortieth screen costs a fraction of the first.

02

Application architecture

Routing, state, permissions and data flow decided deliberately instead of accumulating.

03

API and services

A documented contract between the browser and the back end, versioned so a front-end release cannot break a mobile client.

04

Performance budget

Targets agreed up front and measured at every milestone. Slow is a defect, not a preference.

05

Offline and resilience

Progressive enhancement, retry logic and honest error states for users whose connection is not your office Wi-Fi.

06

Accessibility to WCAG 2.1 AA

Keyboard paths, focus order, contrast and labels — part of the definition of done, not a later phase.

Shapes of the work

Where this
usually lands.

Application typeWhat it solvesWhat we watch
Customer portalSupport load and email ping-pongAuthentication, permissions, audit trail
Internal dashboardDecisions made on stale numbersQuery cost, caching, data freshness
Progressive web appApp-store friction for a simple toolOffline behaviour, install prompt, push
Multi-tenant SaaSBuilding the same thing per clientTenant isolation, billing, onboarding

Stack

What we build
this with.

We work in your stack when you have one. These are our defaults when the choice is ours.

ReactTypeScriptViteNode.jsLaravelPostgreSQLRedisWebSocketsPWAPlaywright

Questions

Before you
commit.

Single-page app or server-rendered?
Whichever serves your users. Content-led products get server rendering for speed and search visibility; tool-like products get a single-page app. Many get both in different areas.
Can it work offline?
To a degree, and we will be specific about which degree. Reading cached data offline is straightforward; writing and syncing is a real feature with a real cost, so we scope it explicitly.
Will it run on shared hosting?
A server-rendered app or static front end absolutely will, and we deploy to shared hosting regularly. If your requirements genuinely need more, we say so before you buy anything.
How do you keep it fast as it grows?
A performance budget agreed at the start, measured at every milestone, and a monitoring dashboard after launch so regressions are visible rather than reported by customers.

Ignition

Need web applications?

Tell us the problem, the users and the systems already in place. We will identify the right discovery or build step.