It started with a tweet. A Polish traffic‑safety journalist (https://x.com/_zboral) wrote that if someone in IT really wanted to, they could topple the local driving‑school industry in a week by launching a free website with driving‑test questions. The data is public, he said, and linked to the government portal hosting the official question set. Someone replied that AI could do it in a minute. “I doubt it,” he answered.
I like challenges like that. So I replied with a simple: “hold my beer“.
Three hours later, the first version of GotowiDoJazdy.pl was live.
Not perfect. No images yet. No category filters. No language variants. But it worked, and that was the point: a real, public, usable product, launched fast, using only free tools.
Source data: https://www.gov.pl/web/infrastruktura/prawo-jazdy
Tools:
What made it possible wasn’t a magical prompt or secret hack. It was knowing what to do, where to click, and which keys to paste.
The Myth of “Free Tools”
Everyone loves to say, “You can build this for free.” And yes, you can — in theory. But “free tools” often come with an invisible price: you must already know how to connect them, what settings actually matter, and how to avoid the sharp edges.
The real cost isn’t the code. The code is cheap. The cost is knowing the moves.
This project was a perfect example. The tools were free and widely available: Next.js, Supabase, Vercel, GitHub, Cloudflare (DNS, cache, R2), Google Analytics. None of that is exotic. The difference was speed, not because of a magic stack, but because I already knew the exact sequence of steps to go from idea to production.
The First 20 minutes: Data + Database
I downloaded the government files locally and asked Codex to design a database schema for the Excel file. I didn’t even open the spreadsheet. That’s not bravado — it’s experience. I’ve seen enough data models to know roughly what will work, and I can validate it later by inspecting the live tables.
Supabase was the obvious choice. It’s free at small scale, gives you Postgres, and doesn’t slow you down with infrastructure setup. I wanted the database to exist before I wrote a single line of UI.
This was the first hint of the “experience gap”: a junior developer might open the Excel file and spend time analyzing columns before creating anything. I knew I could iterate faster by creating a schema, importing a sample, and validating by querying.
Next 30 minutes: App + Deployment
I created a GitHub repo and linked it to Vercel — two clicks if you already know where to go. I’ve done this so many times that I don’t think about it anymore, which is exactly the point.
Then I asked for the first app version:
- Next.js frontend
- simple free quiz flow
- Supabase database
- Vercel deployment
The first generated UI was fine but visually weak. So I switched tools and worked with Claude 4.5 in Windsurf to get a better design. The change was immediate: same app, but suddenly it looked like something you’d trust. That polish matters, even for a fast prototype.
After that, I pushed the first version to production and went for a winter bike ride. That’s not a flex; it’s how fast it really was.
Hour Two: The Hidden Work
The next hour was the part nobody tweets about — configuration, infrastructure and sanity checks.
I bought a domain, pointed it through Cloudflare, and set up Google Analytics and Google Workspace email. All of this was “just a few clicks,” but only because I already knew what those clicks had to be. That knowledge is the real differentiator.
Then came the inevitable: I hadn’t checked the data structure before telling AI to use it.
That meant I only discovered later that there was no filtering by license category and that many questions referenced images that weren’t present.
So I asked Codex to extend the app: category filters, image support, and a better flow for loading new questions. I also introduced language variants later (English, German, Ukrainian), because the Excel file already contained translations.
At this point, AI was still moving fast, but the quality of the app depended on how well I could spot problems.
The Media Problem (8 GB vs 100 MB)
Vercel gives you 100 MB of static storage. The images and videos were over 8 GB. That doesn’t fit.
I asked Claude for storage options: S3, BunnyCDN, Cloudflare R2. The conclusion was clear: R2 was the cheapest and simplest.
So I set up an R2 bucket, connected a domain, and copied the files with rclone. That took minutes — because I had done similar things before. Again: the tools are “free,” but the speed is experience.
The Security Reality Check
Because AI wrote most of the first version, I did a quick audit.
I asked another model to verify:
- no API keys were exposed
- no private files were committed
- no obvious security issues
It flagged one issue. And I found another: the quiz was validated server‑side, but the correct answers were being sent to the frontend with the question payload. That meant anyone could open dev tools and see the answers.
I fixed it immediately: correct answers stayed on the server, and the frontend only received what it needed. AI had missed it. This is important: speed is great, but oversight still matters.
I also changed the UX. Instead of reloading the entire page for each new set of questions, I introduced an API‑based shuffle flow. Claude rewrote more of the app than expected, but the user experience improved a lot.
The Missing Files Audit
About 10% of the images were missing, so I wrote a quick script to detect which ones and for which questions. We need to ask government why it is missing.
Licensing was another challenge. Government materials are often public domain, but the gov.pl site includes a general license note. It wasn’t clear whether that applies to these specific assets, so I asked for clarification.
So I emailed the ministry to ask. Until I get a response, images are hidden to avoid legal ambiguity.
The Real Lesson
This was a three‑hour build, but not because the tools were magical. The tools are free and available to anyone. The reason it was fast is that I already knew:
- which platforms to use
- how to connect them
- what settings are critical
- where problems would appear
- what to check before going public
That knowledge is the difference between “I can build it for free” and “I can build it in three hours.”
Final Thought
If you want to build fast, the stack isn’t the secret. The secret is the sequence: what to do first, what to ignore, and which small decisions prevent big problems later. AI can write code quickly, but it won’t know your next move unless you do. That’s why it pays to practice, build for fun, and explore new tools and solutions — you never know when you’ll stumble onto an interesting project and want to deliver it in three hours.
The project is live. It isn’t perfect. But it exists — and that’s the best proof that speed is mostly about knowing what to click.