DEV Community: Rahul Devaskar

Make any quiz with AI in 30 seconds — and the three attempts it took to ship it

Rahul Devaskar — Wed, 20 May 2026 12:32:24 +0000

The sleepover

It was a Saturday afternoon. My son had friends coming over for a sleepover that night, and he wanted to host a quiz. I had said I'd help him build one. I had also told my partner I'd finish something else by 5pm.

The two promises were not compatible. (A typical excuse, I know.)

I sat down at the laptop and thought: just ask the AI. I opened ChatGPT and typed:

Create a 10 question quiz for 8 year old kids with a Minecraft theme. Only expert Minecraft players should get 100%. Make it tough.

Twenty seconds later I had a quiz. My son was reading the questions over my shoulder, suspicious.

"But but but but daddy — how will the AI know what I want?"

He was eight, and he was already asking the question every product manager eventually asks: who is in charge of the requirements here?

I showed him the prompt. I changed "Minecraft" to "Pokemon" and re-ran it. He watched a new quiz appear. He didn't say anything, but he tilted his head in the way he does when he's reconsidering whether something is magic.

That was the moment I thought: this should be a feature in Quizzy.

The cost wall

The naive version is two afternoons of work. Slap a form on a page, send the user's input to an LLM, render the result.

The problem is the bill.

If I put my OpenAI key behind every user, I am paying for every quiz on Quizzy.earth. The economics of a free product where every action calls a paid API are bad in a predictable way: the more successful you are, the more it costs you. There's no version of "this took off" that isn't also "I am broke."

Quizzy doesn't charge for this. I don't want it to. So the question wasn't how do I add AI? — it was how do I add AI in a way where the user's AI does the work?

That turned out to be the hard part. I tried three things.

Attempt 1: The BYO-AI form

The first idea was the obvious one. Build a small form: topic, difficulty, language. Press a button. The app composes a prompt you can copy.

You paste that prompt into whichever AI you already use. ChatGPT, Claude, Gemini, whatever. The AI spits out JSON. You paste the JSON back into Quizzy. The app parses it into a quiz.

In theory: elegant. The user pays for their own tokens. I pay for nothing. Everyone wins.

In practice: I was the only person on Earth who could use it.

The first problem was that most people don't know what JSON is. I had built a flow that required users to understand a serialisation format, and most of them weren't going to. I figured I could explain that part.

The second problem was the one I didn't see coming, and my son was the one who found it.

I handed him the laptop to try it. He typed his topic into Quizzy, copied the generated prompt, pasted it into ChatGPT — and the moment the AI started typing, he selected the half-written response and pasted it back into Quizzy. He didn't wait for the stream to finish. Why would he? On every other app he uses, when text appears, it's done. He pasted half a JSON object, hit create quiz, and got an error.

He looked up at me. What did I do wrong?

He hadn't done anything wrong. The product had. If an eight-year-old can't build a quiz with this thing in under a minute, the product has failed — that was the rule I'd written down for Quizzy on day one, and I'd just watched it break in front of me. Even a kid should be able to build a quiz without friction.

I had built a feature for developers and shipped it to families.

Attempt 2: The magical disappear

The next idea was genuinely fun to think about.

What if the AI itself sent the quiz back to me?

The flow in my head:

The user gets a prompt with a unique ID baked into it.
They paste it into their AI.
The AI generates the quiz and POSTs the JSON to /api/generate-quiz along with that ID.
My backend stores it in Redis under that ID.
The frontend has been polling (or sitting on a websocket) the whole time. The moment the ID lights up, the quiz appears.

The user does nothing. They paste a prompt, they watch their AI think for a few seconds, they look back at Quizzy and the quiz is just there. No copy. No paste. No JSON.

This would have been magic.

It didn't work because, as it turns out, most AI agents won't POST to an arbitrary URL. Some block it outright. Some require a tool the user hasn't enabled. Some quietly refuse. The version of this that works in 2026 is not the version of this that works for a stranger using whichever AI they happen to have open.

Maybe one day. Not yet.

Attempt 3: The URL smuggle

If POST is forbidden, what about GET?

Most AI agents will "browse" or "search" a URL when asked. So what if the prompt told the AI to construct a URL where the entire generated quiz lived in the query string, and then to visit it? My server would parse the quiz out of the query params, stash it in Redis, same as before.

I built this one. It almost worked.

It died for two unromantic reasons. The first is that browsers and proxies cap URL lengths somewhere between 2k and 8k characters. A ten-question quiz with four options each blows past that without breaking a sweat. The second is that the AI's built-in browser tools have their own opinions about what counts as a legal URL, and a 6k-character query string was not one of them. The requests never landed. The DNS resolved to nowhere useful. I was smuggling air.

So: I couldn't hide JSON. I couldn't avoid the copy-paste. And on mobile — where most of Quizzy's traffic actually lives — every paste also means switching apps. Open Quizzy, copy prompt, swipe to ChatGPT, paste, wait, copy response, swipe back, paste again. App-switching on a phone is its own friction tax, and unlike the others, this one I couldn't engineer my way out of in this version. The user's AI is in a different app from mine, and the path between them runs through the OS.

So the remaining question was a smaller one: with all of that fixed in place, could the existing flow at least stop being a UX punishment?

What I actually shipped

The thing I keep reminding myself when I build for people who aren't developers: users don't want your product. They want the thing your product gives them. Every step you can absorb so they don't have to think about it is the product.

I couldn't remove the copy-paste step. But I could make it forgive almost anything.

Two changes did most of the work:

JSONL instead of JSON. Instead of asking the AI for one big JSON array, I ask it to emit one JSON object per line. Now if a user pastes a partial stream — three lines out of ten — I get a three-question quiz instead of an error. Their copy is imperfect; the parse is graceful. The quiz that appears is a little shorter than they expected, not a red banner.

jsonrepair for everything else. Users don't just paste the JSON. They paste the AI's whole response — including "Sure! Here's your quiz:" at the top and "Let me know if you want me to tweak anything!" at the bottom. The jsonrepair package is forgiving in exactly the ways an LLM's output is messy. It strips chatter, closes unclosed brackets, repairs trailing commas, fixes single quotes. It turns "almost JSON" into JSON.

Together: the flow still has a paste step, but the paste step almost never fails. The user sees a quiz appear. They don't see the parser stitching their messy paste back into shape.

It is not the magical disappearing-prompt flow I wanted in attempt two. But it ships, it costs me nothing per quiz, and it works for grandparents pasting from ChatGPT on a Sunday morning.

The thread

Every dead end I hit was a version of the same instinct: let the user's tools do the work. That instinct was right. The trick wasn't backing away from it — it was accepting that the rough edges of "the user's tools" (partial pastes, friendly preambles, half-streamed responses) were my problem to absorb, not theirs.

Good UX, in this case, looked less like a clever pipeline and more like a tolerant parser. The clever architecture would have been more satisfying to build. It also wouldn't have shipped.

Try it — and tell me how you'd do it

It's live at quizzy.earth. Open it, pick a topic, generate the prompt, paste it into your favourite AI, paste the response back. Thirty seconds, no account, your tokens.

If you've solved "great UX on someone else's API budget" in a way I haven't tried — I'd love to hear it. Especially that magical disappearing version. I still think there's a way to make it work.

I built a quiz app with my 8-year-old to fix homework — and accidentally a family ritual

Rahul Devaskar — Thu, 14 May 2026 10:02:32 +0000

The homework problem

It started in December 2025.

My son was about to start Year 3, and Year 3 in Australia means NAPLAN — the standardised test that suddenly turns "reading at bedtime" into "structured practice." I had a stack of worksheets, a pile of flashcards, and a kid who had zero interest in any of it.

The problem wasn't that he couldn't do the questions. He could. The problem was that being asked the questions felt like a chore. The format was the friction. A worksheet says: here is work. A timer on a phone says: here is a game.

So one evening I sat down with him and we made a deal: I'll build a thing that turns your homework into a quiz game, and you tell me what makes it fun.

That deal is what eventually became quizzy.earth.

What an 8-year-old taught me about UX

Here is the thing nobody tells you about designing for kids: they have zero patience for your onboarding flow.

I tried existing tools first. They all had the same shape:

Sign up
Verify your email
Create an account name
Click through a tutorial
Now you can make a question

By step 2 my son had wandered off to find his ipad.

He wasn't being difficult. He was telling me something true that adults have learned to tolerate: most software treats the act of starting as a tax you pay before the fun begins. For a kid, there is no "before the fun begins." There is just fun, or there isn't.

So the first rule wrote itself: no sign ups. Open the page, type a question, press play. If a Year 3 kid can't make a quiz in under a minute, the product has failed.

The second rule came from watching him try to type. He could read fluently, but typing a multiple-choice question with four options and marking the right one is a lot of fiddly UI. Every dropdown, every modal, every "are you sure?" was a place he would stall. So we ripped them all out. One screen. One question at a time. Big buttons. The kind of UI where you don't have to read the labels to know what to press.

The third rule was the hardest, and I didn't see it until later.

"Can we play the toy quiz again?"

Once the prototype worked for homework, something unexpected happened.

We had family over for dinner. My son — who two weeks earlier hated structured anything — opened the laptop and announced he was going to host a quiz about his soft toys. He'd made it that afternoon. Without telling me.

The first question was "What is the name of the brown and white teddy?" — and four adults around a dinner table started arguing about a teddy bear's name like it was trivia night at the pub.

That was the moment I realised the thing I'd built wasn't a homework tool. It was a tool for shared attention. Homework was just the excuse.

The problem it actually solved had nothing to do with NAPLAN. It was: how do you get a group of people — kids and adults, different ages, different attention spans — to look at the same thing and laugh together for ten minutes?

Most "family games" require somebody to read instructions out loud, deal cards, keep score, and referee disputes. By the time you've set it up, the four-year-old has lost interest. A quiz on a screen, hosted by a kid, sidesteps all of that. The kid is in charge. The adults are players. The screen does the scoring. The friction is gone.

The grandparents problem

The next wedge came from a phone call.

My parents — the grandparents — had been hearing about the dinner quizzes. They wanted to play. But they live overseas, and the "everyone in the same room" format obviously doesn't work over a video call with lag and three time zones.

What they wanted was something different: a quiz they could play alone, at their own pace, when they had a quiet moment.

This was a real shift. The original product was synchronous — one host, many players, one room. What they were asking for was asynchronous — make a quiz, send a link, the other person plays whenever, you see how they did later.

And the delivery channel wasn't an app. It wasn't email. It was WhatsApp. Because that's where the family already was.

This is the part I keep coming back to when I think about building things: users don't show up where you want them to show up. You go to them. The grandparents weren't going to download an app, create an account, or learn a new interface. They were going to tap a link in WhatsApp and play. If you can't meet them there, you don't have a product for them.

So we built that mode too. Same engine, different shape: make a quiz, get a shareable link, send it through whichever group chat your family lives in, and the recipient plays solo. The host gets to see the results. No accounts. No friction.

The thread

If I zoom out, every version of the product has been solving the same underlying problem in different clothes:

Homework: how do I get a kid to engage with content that feels like work?
Dinner table: how do I get a mixed-age group to share attention for ten minutes?
Grandparents over WhatsApp: how do I share a small moment of play with someone who isn't in the room?

The answer in all three cases turned out to be the same: strip the friction until the activity itself is the only thing left.

No accounts. No tutorials. No app store. No "set up your profile." Just: here is a question, here are the answers, press the one you think is right.

It sounds obvious written down. It was not obvious while I was building it. Every time I added a feature, my son would find a way to get stuck on it, and I'd take it back out. He was, without knowing it, the most ruthless product reviewer I've ever worked with.

What I'd tell someone starting a side project

Three things, in order of how badly I wish I'd known them earlier:

1. Find a user who can't be polite to you. Adults will tell you your product is "interesting" and never open it again. An eight-year-old will tell you it's boring and walk away mid-sentence. The second kind of feedback is worth ten times more.

2. The problem you start with is not the problem you end up solving. I started with homework. I ended up with a thing my parents use to send their grandkids quizzes from the other side of the world. The interesting product was hiding inside the obvious one.

3. Friction is the feature. Or rather, the absence of it is. Every screen you remove, every account step you delete, every "are you sure?" you cut — those aren't simplifications. Those are the product.

If you want to try it, it's at quizzy.earth. No sign up. Make a quiz in a minute. Send it to whoever you want to laugh with.

And if you have a kid in Year 3 staring down a stack of worksheets — open it, hand them the keyboard, and see what they make. They'll surprise you.