Web Application Development
Web applications with performance written into the contract.
Speed and accessibility are acceptance criteria in our definition of done, not a clean-up task after launch. We agree the budget before the build and hold the release to it.
The problem we solve
What actually goes wrong.
Web performance degrades by accumulation. No single commit makes an application slow — a dependency here, an unoptimised image there, a third-party script someone added for a campaign. By the time it is measurably bad, the cause is spread across a year of changes.
Accessibility follows the same pattern, except the consequence is that people cannot use the product at all. Retrofitting it means revisiting every component, which is why it so often gets deferred indefinitely.
Both problems are cheap to prevent and expensive to fix. The fix is not heroics at the end; it is a stated budget, enforced in CI, that fails the build when someone exceeds it.
What's included
Activity, deliverable, and how long it takes.
| Activity | Deliverable | Typical duration |
|---|---|---|
| Performance budget | Agreed Core Web Vitals targets and bundle-size ceilings, enforced in CI | Week 1 |
| Frontend architecture | Component structure, state strategy, rendering approach per route | 1–2 weeks |
| API layer | Endpoint contracts, error model, caching strategy | Runs with build |
| Auth & RBAC | Authentication, session handling, role and permission model | 1–2 weeks |
| Responsive UI | Implementation across breakpoints, keyboard paths, and screen readers | Runs with build |
| Accessibility conformance | WCAG 2.1 AA audit, remediation, written statement | Before release |
How we deliver it
Performance budgets, Core Web Vitals, and accessibility as acceptance criteria.
- 01
Agree the budget first
Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, and a JavaScript ceiling. Written into the SOW so it is a contractual target rather than an aspiration.
- 02
Pick a rendering strategy per route
Static, server-rendered, or client-rendered, chosen route by route against what the page actually does. Blanket decisions are where most performance problems begin.
- 03
Enforce it in CI
Lighthouse and bundle-size checks run on every pull request. Exceeding the budget fails the build, so regressions get caught by whoever caused them.
- 04
Build accessible components once
Focus management, semantics, and contrast handled in the component library rather than page by page. Getting it right once is what makes AA affordable.
- 05
Verify on real conditions
Testing on throttled connections and mid-range devices, not just a developer laptop on office wifi. That is where your users actually are.
Technology & tooling
What we build this with.
- Frontend
- React
- Next.js
- TypeScript
- Tailwind CSS
- TanStack Query
- Backend
- Node.js
- NestJS
- REST
- GraphQL
- Data
- PostgreSQL
- Redis
- Verification
- Playwright
- Lighthouse CI
- axe
- k6
Typical engagement
What this usually looks like.
- Team shape
- A delivery manager, two to three engineers, and design input — composition agreed per engagement.
- Duration
- Typically two to six months to a first production release.
- Engagement models that suit it
- Fixed-Scope Project
- Dedicated Team / Pod
Questions we get asked
Answered properly, not deflected.
What performance targets do you commit to?
We agree specific Core Web Vitals thresholds in the SOW rather than promising it will be fast. The targets depend on what the application does — a content site and a data-heavy dashboard should not be held to the same number.
Do you guarantee WCAG 2.1 AA?
We build to it and verify before release with both automated and manual testing. Automated tools catch roughly a third of issues, so the manual pass is the one that matters. We will tell you about anything we could not resolve rather than quietly leave it.
Can you improve an existing application rather than rebuild it?
Usually, and we will say so if that is the better option. We start with an audit that identifies what is actually costing you, because the cause is rarely where people expect it to be.
How do you handle SEO for a JavaScript application?
Server rendering or static generation for anything that needs to be indexed, with metadata and structured data as part of the build rather than a plugin added afterwards.
What about browser support?
We agree the support matrix during discovery, based on your actual analytics rather than a default list. Supporting a browser nobody uses has a real cost.
Other capabilities
The rest of what Laxora builds.
Have a web application development requirement?
Tell us what you are trying to achieve and what constraints you are working under. We will come back within one business day with an honest view of scope and approach.
- First response within one business day
- NDA in place before any disclosure
- Scoped proposal, not a generic quote