A Year Ago, I Couldn't Build a Website

A year ago, I couldn’t build a website. I’m an Android developer — Kotlin, Jetpack Compose, that’s my world.

Today I operate the largest driving school comparator in the Czech Republic. And possibly the biggest project in the country built with AI assistance.

I built all of it after work. No team. Just me, AI, and the determination to ship.

The Trigger

It started with a conversation. A friend was looking for a driving school in Prague and asked me for a recommendation. I didn’t have one. So I told them to Google it.

Try Googling “autoškola Praha” sometime. You’ll find a handful of SEO-optimized schools on the first page, a couple of outdated directories with broken links, and absolutely no way to compare prices, pass rates, or reviews in one place. The information exists — buried in PDFs on municipal websites, scattered across individual school homepages (many of which look like they were built in 2005), and locked behind phone calls. Every driving school in the Czech Republic has an IČO number and is registered with the transport authority. The data is technically public. But nobody had aggregated it into anything useful.

I’m the kind of person who sees that and can’t let it go. There’s a gap. It’s obvious. Somebody should fix it. And when “somebody” doesn’t show up for long enough, I become somebody.

The Beginning

When I started, I spent weeks studying documentation and searching for the “ideal architecture.” Then it hit me — if I tried to understand everything upfront, I’d never start.

So I switched to vibe coding. Instead of memorizing syntax, I started describing to AI what I wanted to build — and refined it on the fly.

Fair enough — “vibe coding” sounds flippant. But here’s what it actually meant in practice: I knew what I wanted the system to do. I knew how software architecture works — I’d been building Android apps professionally for years. I just didn’t know the specific incantations of the web ecosystem. React hooks instead of Compose remember blocks. CSS instead of XML layouts. getServerSideProps instead of ViewModel lifecycle. The concepts transferred. The syntax didn’t.

Android to Web: What Transferred, What Didn’t

Let me be specific about the mental model shift, because I think it’s useful for any native developer considering the web.

What transferred directly: State management concepts. In Jetpack Compose, you think in terms of state hoisting, unidirectional data flow, and recomposition. React is the same philosophy with different syntax. useState is mutableStateOf. useEffect is LaunchedEffect. useMemo is derivedStateOf. Once I understood the mapping, I could describe component behavior to AI and immediately know if the output was structurally correct, even if I couldn’t write it from memory.

Dependency injection patterns. Android has Hilt/Dagger. Web has… well, everything from React Context to module-level singletons. The principle is identical — decouple creation from usage. I could describe the dependency graph I wanted, and AI would wire it up in the web-appropriate way.

What absolutely didn’t transfer: Server-side rendering. Android doesn’t have SSR. There’s no equivalent concept. The idea that a component renders on the server first, ships HTML to the client, then “hydrates” into an interactive app — that broke my brain for a solid two weeks. I kept writing components that assumed client-side state was available on first render. Claude would generate correct SSR-compatible code, and I’d “fix” it by adding client-side dependencies that broke hydration. It took a while to internalize.

CSS. Android has constraint layouts, linear layouts, and a relatively predictable box model. CSS is a different universe. Flexbox makes sense once you understand it, but the cascade, specificity, and the 47 different ways to center a div? I still sometimes describe what I want visually and let AI figure out the CSS. No shame.

Routing. Android has a navigation graph — explicit, typed, declarative. Next.js has file-based routing, which is elegant until you need dynamic segments, catch-all routes, parallel routes, and intercepting routes. The App Router was released around when I started, and even experienced web devs were confused by it.

The Learning Curve

Here’s an honest timeline of what the first months looked like.

Weeks 1-2: Couldn’t even get Next.js running locally with the configuration I wanted. Kept confusing Pages Router and App Router docs. Set up a PostgreSQL database on Cloud SQL, and spent an entire evening debugging connection strings because I didn’t understand that Cloud Run uses Unix sockets, not TCP, for Cloud SQL connections.

Week 3-4: First working page — a list of driving schools pulled from the database. It was ugly. The data model was wrong (I had courses as a JSON blob inside the school record instead of a separate table). But it rendered. That felt enormous.

Month 2: Authentication. This nearly killed the project. I tried NextAuth, then rolled my own JWT implementation (bad idea), then went back to NextAuth with Directus as the backend. Getting OAuth working with Google and email/password simultaneously took a full week. The session management between the Next.js app and Directus was held together with duct tape.

Month 3: First working prototype with search, filtering, and school detail pages. I showed it to a few friends. Their first feedback: “The data is cool but the design looks like a government website.” Fair. I spent the next two weeks on UI.

Month 4-5: Data collection at scale. I wrote scrapers (with Claude’s help) that pulled driving school data from public registries, municipal websites, and individual school pages. Parsing Czech government PDFs for pricing data was a special kind of hell — every municipality formats them differently. Some are scanned images. Some have tables that span multiple pages. We got through it.

Month 6: First real users from organic search. Google started indexing the school pages. I remember the exact day — a Tuesday — when Google Search Console showed 47 clicks. Not 47 thousand. 47. I was unreasonably excited.

The Result: Kvalty.cz

Currently the largest driving school database in the Czech Republic and the first step toward a platform that straightens out the market. The goal is simple: bring transparency where it’s been missing for years, and make visible those who do their work honestly.

Thanks to AI, we managed to tame data that was previously inaccessible:

1,700+ driving schools mapped across every region
15,000+ courses, services, and fees extracted and unified
Pricing hidden in PDFs → now comparable in one click
237,000+ lines of TypeScript across the monorepo
163 database tables powering the platform
Organic growth through SEO, with real reviews coming in monthly

The stack today: Turborepo monorepo with 3 Next.js apps (public comparator, admin dashboard, driving school portal), a Hono/tRPC backend, PostgreSQL with PostGIS for geographic queries, all running on Google Cloud. Every piece of it built with AI assistance.

The Plot Twist

I’m originally an Android developer.

Building a web app on a modern stack (Next.js, PostgreSQL, Cloud Run) would normally mean months of study. Vibe coding opened a shortcut. I hold the vision and architecture, AI handles implementation, UI/UX, and data structure. Not as a “code writing tool.” More like a senior partner who never sleeps.

The code isn’t academically clean, and I don’t understand every line under the hood. But it works for thousands of people, and that matters more to me right now. AI turned out to be a surprisingly good mentor along the way.

Thinking in Products

People ask what “thinking in products” actually means. Here’s a concrete example.

Early on, I had to decide: do I build the search as a full-text search, or a structured filter system? A code-first developer would pick the technically interesting option — maybe Elasticsearch, maybe a fancy vector search. A product-first developer asks: what does the user actually need?

A person choosing a driving school cares about: location (close to home or work), price (within budget), vehicle type (motorcycle? truck?), and maybe language (for foreigners). They don’t need fuzzy full-text search. They need five dropdown filters and a map. So that’s what I built. Took a fraction of the time, serves the use case perfectly, and I can always add full-text later if the data shows demand for it.

Another example: I could have built an elaborate review system with photo uploads, verified purchases, and ML-powered spam detection. Instead, I launched with simple text reviews and manual moderation. It’s not scalable. It doesn’t need to be — I get maybe 15 reviews a week right now. When I get 150 a week, I’ll automate. Not before.

That’s product thinking. Build for the stage you’re at, not the stage you fantasize about.

Milestones That Mattered

100 schools mapped: About 6 weeks in. This was the minimum viable dataset — enough to be useful for someone in Prague, but not yet comprehensive.
500 schools: Month 3. Covered the major cities. This was when I started believing the project was real.
1,000 schools: Month 5. National coverage started being credible. I could search any district and get results.
First organic review from a stranger: Month 7. Someone I’d never met left a review for their driving school in Brno. They found Kvalty through Google. That was the moment the product became real — people were finding it, using it, and contributing data without any prompting from me.
First driving school owner contacting me: Month 8. An owner from Olomouc emailed asking how to update their school’s information. That’s when I knew the platform had visibility. I built the school portal dashboard the following week.

Looking back

If this project taught me anything, it’s that knowing a framework matters less than knowing what to build. Product thinking and the willingness to start before you have all the answers — that’s what actually got this shipped.

I went from npx create-next-app to operating the largest platform of its kind in the Czech Republic in under a year. Working alone, after hours, with AI as my co-builder. The 237,000 lines of TypeScript, the 163 database tables, the 1,700+ schools — none of that existed 14 months ago.

Could a web developer have built this faster? Probably the first few weeks. But I don’t think the gap is as large as people assume. Domain knowledge matters more than framework knowledge. Knowing what to build matters more than knowing how to build it. And AI is very, very good at bridging the “how” once you’re clear on the “what.”

Would I do it again? I’m already planning the next feature. Fourteen months ago I couldn’t build a website. Now I have the biggest platform of its kind in the country. That still doesn’t quite feel real.

Check it out: kvalty.cz