# I Built an Autonomous Vehicle Analytics Platform (Solo) — Here's What I Learned
And why I'm open-sourcing it all.
The Origin Story
It started simple: What if one person could build a real-time analytics platform for autonomous vehicles?
Not the software for driving them. But something that watches them, learns from them, and makes sense of all that sensor data streaming in. Something that could scale from tracking one vehicle to fifty.
Three months ago, I decided to find out.
Today, I'm launching VehicleMetrics — the full codebase, architecture diagrams, deployment guides, and everything — on GitHub. And I want to tell you why this matters, even if you don't care about autonomous vehicles.
Because the lesson isn't about AVs. It's about building production systems solo.
The Challenge
Here's what I wanted to prove:
- One developer (me)
- One vehicle (to start with, or simulated data)
- One month for a proof-of-concept
- Production-ready architecture that could scale to 50+ vehicles
No shortcuts. No "we'll refactor later." Real infrastructure, real security, real DevOps.
The catch? I had to use AWS, Kubernetes, Terraform, PostgreSQL, Redis, React, FastAPI, and a CI/CD pipeline. All while working solo.
Most people would say that's insane.
I said, "let's build."
What We Built
VehicleMetrics is a 3-tier cloud-native system designed to ingest, process, and analyze vehicle sensor data in real-time.
The Architecture (The Part Everyone Asks About)
┌─────────────────────────────────────────────────────────────┐
│ PRESENTATION TIER │
│ React + TypeScript + Grafana Dashboards │
│ (Real-time Analytics UI) │
└─────────────────┬───────────────────────────────────────────┘
│ HTTPS / WebSocket
┌─────────────────▼───────────────────────────────────────────┐
│ APPLICATION TIER │
│ FastAPI Microservices on EKS (Kubernetes) │
│ • Ingestion Service • Analytics Service │
│ • Auth Service • Aggregation Service │
└─────────────────┬───────────────────────────────────────────┘
│ VPC / Private Subnets
┌─────────────────▼───────────────────────────────────────────┐
│ DATA TIER │
│ • PostgreSQL + TimescaleDB (Time-Series Data) │
│ • Redis (Caching & Real-Time Streams) │
│ • S3 (Data Lake for Raw Sensor Data) │
│ • Kinesis (Real-Time Data Pipeline) │
└─────────────────────────────────────────────────────────────┘
It's the kind of architecture you'd build at a startup with 5 engineers. Except one person built it.
Why? Because boring architecture wins. Nothing custom. Nothing clever. All battle-tested, industry-standard tools that have proven themselves a million times over.
The Tech Stack (No Surprises Here)
| Layer | Tech | Why |
|---|---|---|
| Compute | AWS EKS (Kubernetes) | Industry standard for container orchestration |
| Infrastructure | Terraform | IAC done right. Version control everything. |
| Backend | FastAPI + Python 3.11 | Fast, modern, great for microservices |
| Frontend | React + TypeScript | Type safety. Component-driven. Community support. |
| Database | PostgreSQL 14 + TimescaleDB | ACID compliance + time-series specialization |
| Cache | Redis 7 | Blazingly fast. Proven. Boring. |
| Data Pipeline | AWS Kinesis + Lambda | Stream processing at scale |
| Monitoring | Prometheus + Grafana | Observability you can understand |
| CI/CD | GitHub Actions | Right here where the code lives |
Every choice was made for the same reason: When things break at 2 AM, I need to fix them alone. So I chose tools I could understand, debug, and reason about.
The Timeline (How I Actually Did This)
Phase 1: Proof of Concept (Month 1)
- Week 1: Architecture & AWS Setup
- Week 2: Infrastructure (EKS, RDS, S3 configured)
- Week 3: Core API (FastAPI ingestion service)
- Week 4: Dashboard (React + real data visualization)
Phase 2: Production (Months 2-6)
- Multi-vehicle support
- Advanced analytics
- Alert system
- Performance optimization
Phase 3: Intelligence (Months 7-12)
- AI/ML integration (GPT-4, Claude, Llama)
- Predictive analytics
- Anomaly detection
- Custom model training
What Shocked Me
1. The 80/20 Rule is Real
80% of the work was the infrastructure and plumbing. The actual "vehicle analytics" code? Maybe 20%.
This means: invest in architecture first. The business logic is easy. Getting it to scale is the hard part.
2. Documentation > Code
I spent as much time writing deployment guides as I did writing code. And you know what? That's the right ratio.
Future me (and future maintainers) will thank me.
3. You Don't Need a Team
You need:
- Clear constraints (1 month, 1 vehicle)
- Battle-tested tools (no experiments)
- Ruthless scope management
- Good documentation
- Boring choices
You DON'T need:
- Meetings
- Design reviews
- Consensus
- Enterprise process
Solo developers move fast.
Why Open Source?
Three reasons:
Teach — This is a real, production-ready system. Use it to learn how real architectures work.
Prove — Solo developers can build enterprise systems. You don't need a team for this.
Build — Take this, fork it, modify it, scale it. Make something better. I genuinely want to see what you build with this.
What's Included
Everything is on GitHub at beltagyy/vehicle-metrics:
✅ Complete source code (backend, frontend, infrastructure)
✅ Terraform templates for full AWS deployment
✅ Kubernetes manifests (development and production)
✅ Docker Compose for local development
✅ API reference (complete endpoint documentation)
✅ Security guide (including ISO 21434 compliance notes)
✅ Operations manual (what to do when things break)
✅ 17 Phase 1 GitHub issues (ready to start working)
✅ MIT License (do what you want with it)
Clone it. Deploy it. Learn from it. Improve it.
The Real Lesson
This project isn't really about autonomous vehicles.
It's about proving that good engineering beats team size.
One person with:
- Clear goals
- Boring tools
- Good documentation
- Real constraints
...can build something that actually scales.
Most teams fail because they optimize for process instead of output. I succeeded because I optimized for speed and clarity.
What's Next?
- For me: Building Phase 2 (multi-vehicle support) and adding AI/ML capabilities
- For you: Check out the repo, read the ARCHITECTURE.md, deploy it locally with Docker Compose
Questions? Issues? Improvements?
Hit me up on GitHub (@beltagyy) or in the issues. I built this to be learned from, modified, and improved.
TL;DR
- Built a production-grade autonomous vehicle analytics platform solo
- Used AWS, Kubernetes, FastAPI, React, PostgreSQL, Redis, and good engineering practices
- Open-sourced everything at github.com/beltagyy/vehicle-metrics
- Proof that solo developers can build enterprise systems with boring, proven tools
- Phase 1 done. Phase 2 coming soon.
Come build with me. 🚀
GitHub: beltagyy/vehicle-metrics
Author: Mohamed ElBeltagy (@beltagyy)
License: MIT
Top comments (0)