Possibly the Biggest Solo AI-Built Project in Czechia

When I tell people I built Kvalty.cz — the largest independent driving school comparator in the Czech Republic — solo, with AI as my co-pilot, the first reaction is usually skepticism. Fair enough. Let me show you the numbers.

The Numbers

237,624 lines of custom TypeScript code (not counting 448K auto-generated)
1,555 TypeScript files across a Turborepo monorepo
3,528 commits over 15 months of active development
163 database tables, 168 tRPC procedures, 8,506 translation keys
4 apps + 17 shared packages in a single monorepo
Team size: 1

This is a production system with 4 applications (web, academy, admin, API), a Hono/tRPC backend, a 163-table PostgreSQL database with PostGIS, BullMQ job queues, Better Auth with RBAC, CrowdSec WAF, and a fleet of 20 parallel Claude Code agents that autonomously validated every driving school in the country.

The Four Apps

Let me break down what each app actually does, because “4 apps” is easy to gloss over.

Web — the public-facing comparator at kvalty.cz. This is what users see: driving school search by location, side-by-side price comparison, detailed school profiles with ratings and reviews, region and city pages, and the transparent ranking system. Server-side rendered with Next.js, fully localized in Czech and English, optimized for Core Web Vitals.

Academy — a driving test preparation platform. Practice tests for the theoretical exam, question banks categorized by topic, timed mock exams that simulate real test conditions. This is the growth engine — students come for test prep, discover the school comparator, and convert.

Admin — the school management dashboard. Driving schools can claim their profiles, update pricing, respond to reviews, upload photos, and manage their listing. It’s also where I manage the platform: user administration, content moderation, school verification workflows, data quality checks, and analytics.

API — the Hono/tRPC backend that serves all three frontend apps. 168 type-safe procedures handling everything from geographic search to pricing updates to authentication flows. End-to-end type safety from the Drizzle ORM schema all the way to the React components — change a database column type and TypeScript screams at every callsite that needs updating.

The 200-Point Ranking Algorithm

Every school on Kvalty gets a transparent quality score out of 200 points. I won’t give away the exact weights — that’s the competitive moat — but I can tell you what factors feed into it:

Price transparency — does the school publish clear, complete pricing? Or do you have to call them to find out what a B license costs?
Google Maps rating — weighted by review count. A 4.8 with 12 reviews isn’t the same as a 4.8 with 340.
Course variety — how many license categories they offer, whether they have automatic transmission options, refresher courses, intensive programs.
Website quality — is the site functional, informative, and maintained? Or is it a broken WordPress template from 2012?
Response time — how quickly the school responds to inquiries (measured through the platform).
Data completeness — schools that fill out their full profile rank higher than those with bare minimum info.
Review sentiment — not just the star count but what people actually write about.

The whole point is transparency. Users can see why a school scores what it does. No pay-to-play, no hidden boosting. Schools that want to rank higher have a clear path: publish your prices, maintain your profile, treat your students well. That’s it.

PostGIS Geographic Search

“Find driving schools near me” sounds simple until you try to implement it for the Czech Republic.

The core is Haversine distance calculation via PostGIS. User shares their location (or types a city name), we query schools within a configurable radius using ST_DWithin on geography columns, sorted by distance. Standard stuff.

What wasn’t standard: Czech diacritic-insensitive search. When a user types “Pribram” they expect to find schools in “Příbram.” When they type “Ceske Budejovice” they mean “České Budějovice.” Czechs routinely drop diacritics when typing quickly — especially on phones.

The solution: PostgreSQL’s unaccent extension combined with trigram indexes (pg_trgm). Every searchable text field has a generated column with the unaccented version, indexed with GIN trigram indexes. Search queries get unaccented on the fly. The result: “Ceske Budejovice,” “České Budějovice,” “české budějovice,” and even “cesk budej” all find the right city. Fuzzy enough to be forgiving, precise enough to not return garbage.

Region boundary handling was another headache. Schools near the border of two regions should appear in searches for both. A school 2 km outside Prague in Středočeský kraj (Central Bohemia) should still show up when someone searches “driving schools in Prague.” PostGIS made this tractable — geographic queries don’t care about administrative boundaries.

How It Compares

To put 237K lines of custom TypeScript in perspective:

Bigger than Vue.js (~150K lines) — by 158%
Almost 3× Express.js (~80K lines) — by 296%
Almost 5× Create React App (~50K lines)
Architecture sophistication: 163 DB tables, end-to-end type safety from Drizzle schema to React components, PostGIS geographic search, Czech diacritic-insensitive search, a 200-point transparent ranking algorithm, and a complete driving test simulation platform

Behind those lines: geographic search with Haversine distance calculations, multi-tenant authentication, real-time event-driven webhooks, 90+ translation namespaces across two languages, and a complete admin dashboard for school management.

The Evolution

The project evolved through three major phases over 15 months of real development (the repo was created in August 2024, but serious work began in January 2025):

Monolithic Next.js app (Aug 2024 – Dec 2025) — 2,284 commits. The original frontend with GraphQL/Apollo and Directus CMS.
Directus extensions (Mar 2025 – Feb 2026) — 475 commits. Custom backend logic: search, ranking, feature engine, email queue, 21 extensions total.
Turborepo monorepo (Dec 2025 – present) — 769 commits and accelerating. Complete stack rewrite: tRPC replaced GraphQL, Drizzle ORM replaced Directus SDK, Better Auth replaced Directus auth, Hono API server replaced custom endpoints.

The stack transformed completely — and the codebase kept growing through each migration. February 2026 alone had 347 commits as the tRPC migration and Drizzle schema work was completed.

Infrastructure

The whole thing runs on a surprisingly modest stack:

Hetzner Cloud — a single VPS for the PostgreSQL database, API server, and BullMQ workers. Nothing fancy — just a capable box in a European data center.
Vercel — hosting the three Next.js frontend apps with edge caching and ISR.
Cloudflare — DNS, CDN, DDoS protection, and CrowdSec WAF integration.
Neon — database branching for preview deployments so every PR gets its own isolated database.
Better Stack — uptime monitoring and log aggregation.

Monthly infrastructure cost? Under €100. That’s for the whole platform — database, API, three frontend apps, monitoring, WAF, the lot. At this stage the bottleneck isn’t compute, it’s my time.

Growth

I won’t share exact numbers — that’s between me and my analytics dashboard — but the trajectory tells the story. Organic traffic has been growing month over month since launch, with the Academy driving the steepest curve. Turns out students searching for “autoškola test” (driving school test) convert well into comparator users.

The first revenue milestone came earlier than expected. Schools started reaching out to claim their profiles within weeks of launch, before I’d even built the self-service onboarding. The market was that underserved.

The Human Cost

Let me be honest about what 15 months of after-work solo development actually looks like.

I have a full-time job as an Android developer at Fortuna Entertainment Group. Kvalty is built in evenings and weekends. That means most of my “development days” start at 7 PM and end at midnight. Weekends are longer stretches — 6 to 10 hours if I’m in the zone.

The burnout came in waves. The worst was during the tRPC migration in January-February 2026, when I was rewriting the entire API layer while keeping the production site running. 347 commits in February. That’s 12 commits per day average. Some of those days I was debugging Drizzle schema issues at 1 AM before a 9 AM standup at my day job.

How do I manage it? Badly, sometimes. But a few things help: I take full weeks off from Kvalty when I feel the motivation dropping. I batch creative work (design, copy) separately from technical work. And I remind myself that the timeline is self-imposed — nobody dies if a feature ships next week instead of tomorrow.

The AI factor is what makes this sustainable at all. Without AI as a force multiplier, this project would require 3-4 developers working full-time. With AI, one developer working part-time can keep up — barely, with some sleep debt, but it works.

The Methodology

I didn’t just throw prompts at ChatGPT and hope for the best. I developed two systems that made this possible:

Vibe Engineering

My 3-phase methodology for building with AI. Every feature goes through Research & Strategy, The Roast (adversarial AI review), and Consensus before implementation. It’s structured, intentional, and adversarial — not “vibe coding.”

The Ralph Method

A production system of 20 parallel Claude Code agents that autonomously crawled, extracted, and validated driving school data. An 826-line custom prompt. Human review before every database commit. This is how I validated 1,700 driving schools across the entire Czech Republic.

Why “Possibly the Biggest”?

I can’t know every project in Czechia. But based on publicly available data about AI-assisted development:

41% of all code is now AI-generated globally (2024)
Most AI-coded projects range from 5–30K lines (Bolt.new, Lovable, v0)
Even Cursor AI projects typically max out at 50–150K lines
Kvalty’s 237K custom lines puts it well beyond what’s been publicly documented

Most AI-generated projects never leave the prototype stage. Kvalty shipped. It serves real users. It processes real data. It makes real revenue.

Why I’m writing this

Yeah, this is partly showing off. But it’s also real evidence that one person with AI and a real methodology can build and ship software in 15 months — 4 apps, 163 database tables, 168 API procedures — that would normally need a team and twice the timeline.

Could someone else have done this without AI, with a team? Sure, with 3-4 engineers and a year. Could someone have done this with AI but without the methodology? Probably not past 50K lines before the codebase collapsed under inconsistency.

One developer who understands architecture. AI that can execute at speed. A methodology that keeps both honest. That’s the combination that made this work.

The numbers in this article are based on git statistics from the Kvalty.cz repositories as of March 13, 2026. The project continues to grow as I build Kvalty Academy and expand the platform.