Ucopiloto: Connecting Drivers and Repair Shops
Smart Automotive Management App
App that connects drivers and repair shops intelligently, simplifying bookings, quotes and tracking of automotive services, from scratch to commercial launch.
Ucopiloto represents the construction, from scratch to commercial launch, of an app connecting drivers and repair shops, operated end to end by a single engineer, from product to infrastructure.
Strategic Vision
Ucopiloto was created to solve a problem that's simple to state and hard to operate well: finding a trustworthy repair shop, booking a service and tracking everything without relying on phone calls and spreadsheets. Click Software House's proposal was to digitize that journey end to end.
What needed to work from day one
- Booking automotive services in a few taps, from the driver's side
- Managing demand, quotes and vehicle history, from the repair shop's side
- Keeping all three products (app, web and admin) always in sync
Context and Product Construction
As the sole engineer on the project, I worked across every front: data modeling, APIs, the mobile app, the web panel, admin and infrastructure. The strategy was to treat booking and quoting as the system's transactional core — the part that couldn't fail — and only then expand into supporting features like vehicle history and notifications.
API
Booking, quoting and vehicle history rules.
Web + Admin (Next.js)
Operational management for repair shops and a consolidated business view.
Mobile (React Native)
The driver's experience, from booking to tracking.
Low-fidelity prototype of the booking screen
Architecture and Technical Decisions
Even without an infrastructure team, Ucopiloto had to behave like a serious production system: multiple services, each isolated in its own container, with stable API contracts across app, web panel and admin. The architecture was designed so that any part of the system could fail, restart and recover on its own, without manual intervention.
Domain isolated by module
NestJS organizes the API into modules (booking, quoting, vehicles, notifications), each with its own rules and testability.
Consistent, typed data
PostgreSQL with relational modeling for bookings and quotes, accessed via Prisma to reduce type errors in production.
Self-healing containers
Each service runs in its own Docker container, with a restart policy and healthcheck: one failure doesn't bring down the whole system.
No noticeable-downtime deploys
Versioned images and automated deploys let the API be updated in production without interrupting in-progress bookings.
Single API contract
The mobile app, web panel and admin all consume the same REST API, eliminating business-rule drift between platforms.
Backups and async jobs
Backup routines and notification tasks run as jobs separate from the API, without competing for resources with real-time requests.
The whole stack was chosen so that a single engineer could keep the API, database, jobs and observability in production — all containerized and isolated from each other — at 99.9% uptime, even without a dedicated infrastructure team.
Execution and Integration
Execution covered the full flow: driver and repair shop onboarding, booking, quoting, service tracking and history. The mobile app, web panel and admin always talked to the same API.
Implementation principles
- A single API contract for app, web and admin
- Booking validations centralized in the backend
- Componentization to reduce rework across screens
- Basic monitoring from the very first deploy
Driver dashboard: daily profit, revenue and mileage
Vehicle management: fueling, maintenance and expenses
Real-time nearby repair shop search
Deploy and Operations
As the sole DevOps owner, I containerized the whole application with Docker: the API, database, background jobs and reverse proxy run as independent services, each with its own restart policy and healthcheck. That guarantees reproducible environments and simplifies deploys and rollbacks, without relying on manual server access for every update.
Solo operation required discipline around:
- Deploy automation to reduce human error and allow rollback in minutes
- Per-container healthcheck and automatic restart, isolating failures by service
- Minimum viable observability from the start: structured logs and basic alerting
- PostgreSQL backup routines tested and scheduled as their own jobs
- Lean documentation to speed up future decisions without relying on memory
That care translated into 99.9% uptime even without a dedicated infrastructure team — the system's robustness comes from service isolation and automation, not team size.
Security, Observability and Technical Decisions
Even maintained by a single engineer, Ucopiloto was built with the security and observability practices expected of a production system — to fail safely and recover on its own.
Security
- Token auth (JWT) and typed API contracts (TypeScript), eliminating whole classes of bugs
- Rate limiting and input validation at the API edge
- Secrets per environment and TLS; each service isolated in its container
Observability
- Per-container healthcheck + restart policy: self-healing with no manual intervention
- Structured logs and uptime monitoring (99.9%)
- Async jobs (backup, notification) separate from the API, not competing for real-time resources
Decisions & trade-offs
- Modular monolith in NestJS instead of microservices: one engineer keeps it all, with domain isolated per module
- Prisma to eliminate type errors in production, giving up faster but riskier hand-written SQL
- Versioned deploys with no noticeable downtime, instead of the simplicity of a manual deploy
Project Impact
Ucopiloto established a reliable foundation to connect drivers and repair shops, with over 200 active users, 99.9% uptime and a 35% reduction in scheduling time compared to the previous manual process.
Beyond the technical result, the project validated that a single engineer, with the right architectural choices, can sustain a multi-platform product in production with quality and stability.
Trade-offs and what I'd do differently
What I chose not to build
- Kubernetes: with solo DevOps and a single production environment, Docker Compose with a simple deploy delivered the same reliability with far less surface area to operate alone.
- A custom analytics dashboard: I used Grafana over the metrics already collected instead of building a dedicated admin screen, to keep scope tight for the 5-month launch window.
What I'd do differently today
I'd introduce automated E2E tests before the first production release, not after. The 5-month timeline and solo operation pushed test coverage to after launch, which worked, but left the first phase more dependent on manual smoke tests than I'd like.
Key Challenges Faced
Connecting the two sides of a fragmented market, drivers and repair shops, required more than good screens: it required operational reliability from the very first booking.
Syncing bookings and quotes in real time across app, web panel and admin
Ensuring high uptime while operating as a solo DevOps, with no dedicated infrastructure team
Reducing scheduling time without sacrificing the integrity of vehicle and service data
Structural Technical Indicators
- 200+ active users in production
- 99.9% uptime
- -35% in scheduling time
- Containerized infrastructure with Docker
- End-to-end solo DevOps operation