Haraka Gari
A Two-Sided Automobile Marketplace MVP, Built in a 6-Day AI-Agent-Driven Sprint
Haraka Gari is a two-sided automobile marketplace connecting customers with vetted showrooms: browse and search vehicles, inquire directly, apply for financing, and book test drives, while showrooms manage their own inventory and admins moderate the platform. Built end-to-end — frontend, backend, database, security, and QA — as a Next.js + Supabase application, developed under an AI-agent-driven engineering process (Claude Code) that enforced its own quality gates: mandatory PR review, automated testing, and staged release checkpoints, all defined in a single project constitution.
The result: a two-sided marketplace with customer, showroom and admin roles, live in production 6 days after kickoff, with security enforced at the database level and two authorization bugs caught in review before launch.
Project Overview
One Engineer. Six Days. No Room for Shortcuts.
The brief: ship a production-ready MVP — functional, secure, tested, and visually matched to Figma — on a compressed engineering schedule, with no room for over-engineering. Three constraints shaped every decision.
One Engineer, AI-Agent-Assisted
Covering architecture, frontend, backend, security, QA, and release engineering, with no dedicated team to split the work across.
A Hard Ban on Scope Creep
The project's engineering constitution explicitly forbids premature Phase 2 infrastructure — microservices, Redis, queues, API gateways — and requires every feature to trace back to an approved requirement.
A Non-Negotiable Quality Bar
Every feature needed unit/integration tests, E2E coverage for critical journeys, database-enforced authorization, and independent code review before merge — no shortcuts for speed.
A Written Constitution, Not Just a Schedule
The project ran under a written engineering constitution that assigned each phase of work to a specialized agent role — Architect, Frontend, Backend/Data, Full-Stack, Code, QA, E2E, Security, Performance, Code Review, and Release — so no single pass through a feature skipped testing, security, or review. Every feature moved through the same lifecycle: inspect existing code, plan, implement, unit/integration test, E2E test, security review, open a PR, get independent code-review approval, merge, then update the live progress tracker.
- 01
Foundation, authentication, UI shell, test infrastructure.
- 02
Showrooms, vehicle CRUD, admin foundation.
- 03
Marketplace: vehicle and showroom discovery, search, filters.
- 04
Finance calculator, inquiry flow, admin dashboard.
- 05
Integration, security and performance review, release-candidate prep.
- 06
Dedicated QA and full E2E regression.
- 07
Production deploy and smoke tests.
Two features grew past the original plan mid-build: a full appointment/test-drive booking system with database-level double-booking prevention, and admin/showroom analytics dashboards. Both were added only after being logged as explicit client requests and independently reviewed and approved — not silent scope creep.
A Modular Monolith, Not a Microservices Head Start
The architecture layers UI, business logic, and data access on top of Supabase and PostgreSQL — clean boundaries left open for a future migration to a dedicated backend, but nothing built prematurely for that future. No Redis, no message queues, no microservices.
Database-Enforced Authorization
A Postgres trigger blocks showroom self-approval, and a BEFORE UPDATE trigger blocks customers from tampering with their own appointment status or schedule — hardened twice after a gap surfaced in review.
Double-Booking Prevention
A range-overlap exclusion constraint at the database layer prevents appointment double-booking, rather than relying on application-level checks alone.
55 Migrations to Production
The schema evolved through 55 migrations applied to the production database by launch, tracked alongside every feature that depended on it.
What Shipped
Authentication
Registration, login/logout, password reset, session handling, and role-based access for customer, showroom, and admin.
Showrooms
Registration, profile management, admin approval workflow, and a public showroom directory with detail pages.
Vehicles
Add/edit/soft-delete, image uploads, specifications, pricing, status, listing, and SEO-friendly detail pages.
Marketplace Discovery
Homepage, vehicle search/filter/sort/pagination, SEO-friendly URLs, sitemap, and structured data (JSON-LD).
Finance Calculator
Loan amount, interest, term, and monthly payment, plus a full "Apply for Financing" flow with insurance and tracker options.
Appointment Booking
Test-drive scheduling with conflict-free time slots, rescheduling, and multi-vehicle bookings — added mid-build on client request.
Inquiries
A vehicle inquiry form to showrooms, currently email-based; a WhatsApp Business API redirect was scoped but not yet implemented.
Admin Dashboard
Showroom and vehicle moderation, user management, brand/model/type catalog CRUD, and analytics/reports for admins and showrooms.
A Quality Bar the Timeline Didn't Get to Skip
Every PR went through independent code review before merge, and review caught real, fixable issues pre-production — including an unauthorized service-role data path in an owner-search feature, and two rounds of hardening on a database trigger that let customers self-confirm or reschedule their own appointments.
What This Sprint Confirmed
A Written Constitution Holds the Line
An agent-enforced constitution kept quality gates from eroding under time pressure — code review and security review caught real authorization bugs, not hypothetical ones, before they reached production.
A Living Tracker Beats Commit History
A progress tracker updated after nearly every PR made real status knowable at any point — commit history alone doesn't say whether a feature is tested, reviewed, or production-verified.
Release Gates Are the Easiest Thing to Under-Run
Both remain open here, so closing out security/performance sign-off and full production re-verification is the clearest next step.
Scope Changes Worked Because They Were Logged
Mid-build additions — appointment booking, analytics — worked because they were logged, justified against the requirements doc, and independently reviewed, not because they were skipped.
What's Next for the Platform
The application is live in production on Vercel, backed by a production Supabase project with 55 database migrations applied. Homepage, vehicle listings, vehicle detail, showroom directory, and admin were all smoke-tested successfully post-deploy. In the interest of accuracy: deployment happened, but the project's own formal release gate was not fully closed out at last check — authentication, the finance calculator, inquiries, and login were not yet re-verified against production, and the tracker records status as "live, partially verified — not yet a formal release-gate pass." Nine items remain open, most notably: no live WhatsApp Business API integration (inquiries currently go by email), no production Google OAuth or SMTP, placeholder legal pages, and a Next.js routing quirk that returns HTTP 200 instead of a proper 404 on some routes.
Let's Talk About Your MVP Timeline.
Have a validated idea and a real deadline? Let's figure out what a disciplined, AI-accelerated build actually looks like for your product.