SmartQ360
SmartQ360 is a garage management platform now used by 45+ garages across Kerala. I inherited it a quarter built and badly coded from a freelance team, and rebuilt the entire frontend from scratch, solo, into a live white-labeled, subscription product.
Particulars
- Client
- QCentro (SmartQ360)
- Timeline
- Dec 2024 – Jan 2025
- Role
- Sole frontend engineer
- Team
- With a backend developer, designer, PM and QA
- Model
- Live SaaS, white-label and subscription
Record summary
45+
garages in Kerala
8
core modules
6
entity types
1
frontend engineer
The handover
When SmartQ360 reached me it was about a quarter built, and in trouble. A freelance team had left a shattered codebase: no structure, no conventions, styling that did not match the Figma, and a long tail of bugs. It was a Figma-to-screens conversion at best.
I took it over as the sole frontend engineer, working alongside a backend developer, a designer, a PM and QA, and rebuilt the frontend from the ground up on top of what existed.
Fig. 01
The SmartQ360 dashboard
What I rebuilt
I restructured the project from scratch: a clear file and folder architecture, predictable state through React context providers for the active garage and the subscription, standardised styling, and code-quality conventions the team could build on. I also built the responsive experience from zero, since the app had none, so it works on a garage-floor phone as well as a desktop.
From there I owned the whole product surface, from authentication and the dashboard through every module, to production.
What I built
- A search-first dashboard: find any customer by phone or vehicle by registration number, with live suggestions.
- Full management of customers, vehicles with service history, jobs, staff, and a priced services catalogue.
- Multi-garage support with per-garage data isolation and quick switching between locations.
- Subscriptions and white-label setup, so each garage runs the platform as its own.
- Token auth with OTP recovery, role-based access, and Zod validation across every form.
- A job workflow whose status changes drive customer updates, including automated WhatsApp invoices.
How it is built
The app is a React single-page application with Material UI and Tailwind for the interface, TanStack Table for the data-heavy listings, React Hook Form with Zod for validation, and Axios against the backend APIs. State that spans the app, the active garage and the subscription, lives in dedicated context providers. I set the conventions so the codebase stayed consistent as features grew.
Fig. 02
A job in progress on mobile
Hard parts
- Rebuilding on top of a broken codebase without stopping delivery: untangling the mess while still shipping features.
- Per-garage data isolation and switching, so one account never sees another garage's customers or jobs.
- Keeping dense listings of customers, vehicles and jobs fast and readable with tables, pagination and filters.
- A genuinely mobile-first experience for the garage floor, built from scratch because the app had none.
- Bringing structure, state and styling standards to a codebase that had none, on my own.
Outcomes
- Shipped to production: SmartQ360 is live and used by 45+ garages across Kerala.
- Sold as a white-labeled, subscription product each garage runs as its own.
- A quarter-finished, broken handover turned into a maintainable, standardised codebase.
How I approached it
- 01
Stabilise before you extend
I fixed the foundation, the structure, state and styling, before building new features on top of it.
- 02
Own the whole surface
As the only frontend engineer, I treated every screen and edge case as mine.
- 03
Design for the garage floor
Real users are on a phone next to a car, so the responsive experience came first, not last.
- 04
Standards are a gift to the next developer
Clean structure and conventions so anyone picking it up could move fast.
