Next.js • Stripe Terminal • Bilingual • AWS
Huracan Pro Auto Detailing
Bilingual online booking and in-person card payments for a mobile detailer across the DFW metroplex.
- Client
- Huracan Pro, Dallas–Fort Worth
- Role
- Solo build
- When
- Mar 2026 – present
The problem
A mobile detailer covering the Dallas-Fort Worth metroplex needed customers to book online, get reminded, and pay -- sometimes online, sometimes by card at the van. A large share of that customer base speaks Spanish, so an English-only site was leaving work on the table.
Constraints
- —Fully bilingual: English at /, Spanish at /es, including transactional email and SMS
- —Payments both online and in person, on a phone, at the customer's driveway
- —Mobile business -- no fixed location, so scheduling is routing as much as booking
What I built
A Next.js app on AWS Amplify Hosting with a booking engine, customer SMS and email flows, Stripe payments including in-person Terminal, and a staff admin. DynamoDB, Cognito, SES, SNS, S3 and CloudFront sit behind it, all read through the SSR compute role.
Decisions I'd defend
Deliberately no Amplify Gen 2 backend
This app reads existing live DynamoDB tables. Gen 2's defineData would provision its own and silently detach the app from real customer data while the build stayed green. This one is not hypothetical -- the repo's own history contains a Gen 2 app whose amplify/ directory still looks like it belongs. The warning is at the top of the README because a future me would otherwise fall for it.
Single RESOURCE_PREFIX for every resource name
Tests set it to test-, so no test can reach production data. Staging sets it to huracan-pro-staging and the entire app moves together. A boot-time check logs the resolved prefix and warns loudly if a non-production build is pointed at production -- which is the first thing to read when a route 500s after a deploy.
What changed
Bilingual online booking, automated reminders, and card payments at the van, running in production across the DFW metroplex.