Atmora Tech

Engineering

Web apps that hold up
on a bad connection

A web application is a distributed system with a rendering problem attached to it. We build ones that stay responsive on a five-year-old laptop over hotel Wi-Fi, because that is where enterprise software gets genuinely used.

Overview

Browser-delivered software measured on the slowest device your users actually own.

Start with the constraint most teams discover late: your users are not on the machine you built on. Warehouse terminals, hospital workstations, a regional sales laptop with sixty tabs open. We agree a performance budget in the first week, typically 180 KB of critical-path JavaScript, and fail the build when a pull request breaks it.

Rendering strategy then follows the workload. Content-heavy screens are server-rendered and cached at the edge; a dense pricing grid or a scheduling board is a client application with a well-defined data layer. Mixing the two deliberately beats picking one approach and forcing every screen through it.

Accessibility belongs in the definition of done, not in a remediation project two years later. We build to WCAG 2.2 AA with keyboard paths and focus order tested in CI on every pull request, which also matters commercially the moment public-sector and regulated buyers put conformance evidence into their tender documents.

1.4 s
largest contentful paint at the 75th percentile on 4G
172 KB
median critical-path JavaScript after budget enforcement
0 blockers
WCAG 2.2 AA blockers at independent audit on four launches

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Performance budgets enforced in CI

    Route-level budgets for JavaScript weight, largest contentful paint and interaction latency, checked on every pull request against throttled hardware profiles instead of a developer laptop on fibre.

  • Rendering strategy per route

    Server rendering, static generation, streaming and client-side routing chosen screen by screen, with the reasoning recorded so the next engineer does not quietly reverse the decision six months on.

  • Dense data interfaces

    Virtualised grids of a hundred thousand rows, dependent filters, optimistic updates and conflict resolution, built so a mistyped filter cannot lock the browser tab for eight seconds mid-shift.

  • Offline tolerance and resilience

    Request queueing, background sync and honest degraded states, so a supervisor who loses signal between warehouse aisles does not also lose the last twenty minutes of entered work.

  • Accessibility to WCAG 2.2 AA

    Semantic structure, focus management and keyboard paths verified by axe-core in CI and by manual screen-reader passes over the flows that carry legal or financial consequences.

  • Observability from the browser

    Real user monitoring keyed to release version, plus session replay on error, so a slow quarter-end in one region gets traced to a specific query rather than debated in a status meeting.

Deliverables

What you get

  • Component library with documented states and accessibility notes
  • Route-level performance budgets wired into the CI pipeline
  • Rendering strategy document recording the reasoning per screen
  • Playwright end-to-end suite covering the revenue-critical paths
  • Real user monitoring dashboards keyed to release version
  • Browser support matrix agreed against your own device fleet data

Stack

What we build it with

  • TypeScript
  • React
  • Next.js
  • Vite
  • TanStack Query
  • Tailwind CSS
  • Playwright
  • k6
  • Redis
  • PostgreSQL
  • Cloudflare
  • Sentry

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Measure the real environment

    We pull device, browser and network data from your existing analytics before designing anything, because a performance budget only means something if it reflects your users.

  2. Interface architecture

    Routes, data boundaries, caching and state ownership are settled up front. Most web application pain traces back to state that quietly ended up living in three places.

  3. Build with the budgets on

    Feature work runs with performance and accessibility gates active from the first pull request, so regressions surface in minutes rather than in a pre-launch audit.

  4. Load and failure testing

    k6 scenarios at expected peak and twice peak, plus deliberate failure of each backing service to confirm the interface degrades usefully rather than rendering a blank page.

  5. Release and watch

    Progressive rollout by cohort with monitoring tied to the release version, and an automatic rollback trigger on error rate instead of a judgement call at midnight.

When this is the wrong engagement

If the brief is a five-page brochure site with a contact form, a content management system and a competent template will serve you better and cost a fraction of an application build.

FAQ

Questions we get asked

React, or something lighter?

It depends on the screen. Dense, stateful interfaces justify a framework; a document viewer or a marketing surface often does not and ships faster without one. We have delivered both inside the same product, and the boundary between them is an architectural decision we document rather than a house preference.

Do we also need a separate mobile app?

Frequently not. A well-built responsive application with offline queueing covers most field use and avoids two store review cycles on every release. An app earns its place when you need camera pipelines, background location, Bluetooth peripherals, or push that must arrive while the app is closed.

How do you keep performance from decaying after launch?

The budget stays in the pipeline. A pull request that pushes critical-path JavaScript past the agreed figure fails, so the fix is a conversation at review time rather than a rescue project two years later. Real user monitoring watches the same metrics against live traffic.

Can you work with our existing design system?

Yes, and we prefer to. We audit it first for accessibility gaps and missing states, then extend it rather than introducing a parallel set of components. Where a component genuinely cannot support an interaction, we propose the change back into your system instead of forking it.

Related

More in Engineering

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project