Frontends That Don't Fall Apart
Most frontends start fast and rot over eighteen months. Bundles bloat, accessibility regresses, third-party scripts eat LCP, and nobody can explain why the homepage takes 4 seconds. We build React, Vue, and Svelte frontends with performance budgets, accessibility baselines, and tests that fail the build — not the user.
Your frontend was fast.
Then a year happened.
Frontends don't fail all at once. They degrade a kilobyte at a time. One new analytics script, one more React context, one more 'small' dependency, one new hero video. By month twelve, the Lighthouse score is red, the bundle is 800KB, and nobody on the team remembers what the original performance budget was — or whether one existed.
Bundle size bloat over time
The initial bundle was 120KB. It's now 780KB, half of it duplicate lodash imports and a charting library used on one page. Nobody owns the budget, so it doesn\u2019t exist.
Accessibility regressions
The a11y audit passed at launch. Then three sprints shipped features that broke keyboard nav, skipped focus states, and introduced div-as-button. The next audit is going to hurt.
Third-party scripts eating LCP
Analytics, chat widget, marketing tag manager, cookie banner, heatmap, two A/B tools. Each team added 'just one tag.' Now the main thread is blocked for 3 seconds on mobile.
"Works on my MacBook" syndrome
Devs test on a 2023 M-series laptop on office Wi-Fi. Users are on a 3-year-old Android on a train. The gap between those two experiences is where customers churn.
What You Actually Get
No vague deliverables. Here's exactly what lands in your hands.
A typed, tested codebase
TypeScript strict mode, ESLint, Prettier, Vitest, Playwright. CI that refuses to merge a red PR. Not optional, not "phase 2" — on day one.
Real performance budgets
LCP, CLS, INP, TBT, bundle size — all measured per route, enforced in CI, tracked over time. Regressions fail the build, not the user.
Accessibility baked in
WCAG 2.2 AA verified with Axe in CI, manual keyboard and screen-reader tests on critical flows, and focus management that survives React rerenders.
A living component library
Storybook with every variant, state, and edge case. New devs can onboard in a day. Designers can see what actually shipped.
A Real Frontend Team
A senior frontend engagement is not one generalist with a React template. Six roles on every Pillai Infotech frontend build.
Senior Frontend Engineer
Owns the architecture, state management, data flow, and the "why this framework" decision. Writes code that the next engineer can read.
Performance Specialist
Owns Core Web Vitals, bundle analysis, render profiling, and the performance budget. Lives in the Chrome DevTools Performance tab.
Accessibility Engineer
ARIA patterns, focus management, keyboard traps, screen-reader testing. Catches a11y regressions in PR review, not in audit.
Design System Engineer
Builds the component library against real design tokens. Owns Storybook, variant coverage, and the Figma-to-code pipeline.
Frontend SRE
Error tracking, session replay, real-user monitoring, source maps, alerting on p75 regressions. The person who gets paged when the homepage is slow in Jakarta.
Testing Lead
Unit, component, e2e, visual regression. Owns the test pyramid and the flaky-test budget. Stops "we'll write tests later" before it starts.
You See Everything. In Real Time.
Every Pillai Infotech project comes with a dedicated client dashboard. Kanban boards, live logs, test results, meeting notes — it's all visible the moment it happens. No status-report theatre, no "we'll get back to you", no surprises at the demo. You work with us like you work with your own team.
Kanban Board, Live
Every epic, every story, every task — visible on your dashboard. Drag, comment, reprioritize. It's the same board our team works from.
Documented Everything
Every decision, spec, API contract, and architecture diagram lives in the dashboard. Searchable, versioned, linked to the tasks they shaped.
Live Logs & Test Results
Build logs, deployment logs, test suite results — streamed to your dashboard the moment they run. You never have to ask "did the build pass?"
Meetings → Tasks, Automatically
Every meeting is recorded, transcribed, and every action point is auto-converted into a tracked task assigned to the right person. Nothing gets lost between calls.
Sprint Burndown & Velocity
See exactly how much work is done, how much remains, and our velocity over time. If a sprint is slipping, you see it the same moment we do.
Comment, Approve, Decide — In-Place
Comment on any task, approve designs, sign off on specs, and raise blockers directly in the dashboard. Everything tied to the work, not buried in email threads.
What We Typically Build
The frontend engagements where our performance-and-accessibility discipline pays off fastest.
⚛️ React / Next.js apps
Production Next.js with App Router, server components where they earn their keep, streaming SSR, and a real data layer. Not a boilerplate.
💚 Vue / Nuxt apps
Nuxt 3 with composables, Pinia, and typed API clients. Great for teams that already have Vue muscle memory.
🧡 Svelte / SvelteKit apps
When bundle size and runtime perf matter more than the ecosystem. Smaller, faster, fewer moving parts.
🧩 Micro-frontends
Module federation done carefully, with strict contracts between teams. We'll also tell you when a monolith is the right answer.
🎨 Design-system implementation
Turning a Figma design system into a real, typed, tested component package your product teams consume.
🛟 Legacy jQuery rescues
Incremental strangler-fig migration from jQuery / Backbone / Angular 1 to a modern stack — without a 9-month freeze.
The Frontend Stack We Use
We pick frameworks by the problem, not the hype cycle. Here's what we actually ship on.
Frameworks
Styling & System
Build & Tooling
Testing & Monitoring
A Six-Stage Frontend Delivery Process
Each stage has an output that your engineering org can audit. No stage ends with "it looks good on my machine."
Audit & Architecture
Current stack review, performance baseline, accessibility baseline, risk inventory. Output: a written architecture decision record you can share internally.
Foundations
Repo scaffold, CI, TypeScript config, lint rules, test runner, Storybook, Sentry, design tokens. The boring week that saves the next six months.
Build in Slices
Vertical slices of real features — UI + data + tests + a11y + perf — shipped behind flags. Weekly demos on a real device, not a MacBook.
Performance Pass
Bundle analysis, code-splitting, image optimisation, font strategy, third-party audit, critical CSS. LCP/CLS/INP hit budget before launch.
Accessibility & QA
Automated Axe run in CI, manual keyboard and screen-reader tests, visual regression pass, cross-browser sweep on real devices.
Launch & Monitor
Staged rollout, real-user monitoring, Sentry alerting, Core Web Vitals dashboard, 30-day production warranty.
Three Ways to Engage
Frontend work doesn't fit one shape. Pick the one that matches your stage.
Frontend Audit Sprint
A fixed 2-week audit of your current frontend — performance, accessibility, architecture, testing, observability — with a prioritised remediation plan.
- Core Web Vitals + a11y baseline
- Architecture + dependency review
- Ranked remediation roadmap
Production Frontend Build
End-to-end build or rebuild of a product frontend with performance budgets, tests, and a design system on a fixed timeline.
- Fixed scope, fixed price
- Typical: 8–16 weeks
- 30-day production warranty
Embedded Frontend Squad
A dedicated frontend squad working inside your product team across multiple features and releases.
- Senior engineers + systems engineer
- Monthly retainer, scale up/down
- Best for: ongoing product roadmap
Honest Answers to Frontend Reality Questions
The questions every smart buyer asks before signing. Here's what we tell them.
Which framework should we use — React, Vue, or Svelte?
Depends on your team, not on our preference. If you already have Vue muscle memory, Nuxt is usually the right call. If you're hiring in a market where React is 10x more common, React wins on recruitment alone. If bundle size and runtime perf dominate, Svelte is underrated. We'll give you a written recommendation with trade-offs, not a pitch.
CSR, SSR, or SSG?
Mix. Marketing pages: SSG or ISR for speed and SEO. Authenticated app: mostly CSR with SSR for the first paint on critical routes. A dashboard behind a login doesn't need SSR. We decide per route, not per project — and we\u2019ll explain why in writing.
Do we need a monorepo?
Only if you have more than one frontend that shares code. One app and a component library? A monorepo with Turborepo or Nx is worth it. One app, nothing to share? A monorepo is cargo-culting. We'll tell you plainly.
What performance budgets do you enforce?
Default: LCP p75 < 2.5s, INP p75 < 200ms, CLS < 0.1, initial JS < 170KB gzipped per route. Enforced in CI via Lighthouse and bundle-size checks. Regressions fail the build. Budgets get tuned to your real traffic and devices.
What accessibility level?
WCAG 2.2 AA on every project, verified with Axe in CI plus manual keyboard and screen-reader testing on critical flows. AAA where it matters (contrast on core text, motion-reduced alternatives).
What does your testing strategy look like?
Classic pyramid: lots of unit tests (Vitest), a layer of component tests (Testing Library), a thin layer of e2e tests (Playwright) on the two or three flows that must not break. Visual regression via Playwright or Chromatic on the component library. No snapshot-testing cargo cult.
Do you build a component library from scratch or use shadcn/Radix?
Usually shadcn/ui on top of Radix, styled to your design tokens. You get accessibility and keyboard behaviour for free, and the components live in your repo — no runtime dependency on someone else's library. We build from scratch only when there's a reason.
How does handover work?
Your repo from day one. CI and CD you control. Runbooks for deploys, Sentry, monitoring. A 30-day warranty period after launch where we fix anything that regresses for free. You should be able to fire us and keep shipping.