From Zero to Qazo: Building a Product with Kiro, AI, AWS & Pulumi
What started as a simple idea turned into Qazo, a fun, multiplayer AWS troubleshooting game built using #kiro, AI, #AWS and #Pulumi. 🎮☁️ Real AWS incidents. Architecture, logs and clues. Make decisions, fix the problem and race your way up the leaderboard. Built to learn, experiment and have some fun along the way. Think AWS. Play Qazo. #Qazo #AWS #Kiro #AI #Pulumi #CloudComputing #AWSCommunity #AWSAmbassador https://qazo.net
Couple of months ago Qazo didn't exist.
There was no product roadmap, no grand startup plan, and definitely no carefully designed architecture diagram.
There was just an idea:
“What if AWS troubleshooting could be turned into a game?”
That was enough.
I opened Kiro, started describing what I had in mind, and began building.
And somewhere between the first prompt and eventually deploying qazo.net , I realised something.
The most valuable thing I was building wasn't Qazo. It was the experience of building Qazo.
That is really what this blog is about.
It Started With a Simple Idea
We sometimes make side projects unnecessarily complicated.
We think we need to invent the next Kubernetes, build the next billion-dollar SaaS company, or solve a problem nobody has managed to solve before.
You don't.
Your idea doesn't have to change the world. It just needs to give you a reason to start building.
Qazo started with a simple thought. I spend a lot of time around AWS architecture, troubleshooting and cloud transformation, and I've always felt there is a big difference between knowing what an AWS service does and knowing what to do when something isn't working.
So I wondered whether troubleshooting could become a multiplayer game.
That was it.
No 50-page requirements document.
No six-month discovery phase.
Just:
“Let's see if I can build this.”
The Goal Wasn't to Build the Next Big Thing
This is important because AI conversations often start with:
“What problem are you solving?”
That's absolutely the right question when you're building a commercial product.
But it doesn't always need to be the reason you build something.
I wasn't trying to solve humanity's biggest problem with Qazo.
I wanted to learn.
I wanted to experience the entire journey from having an idea to putting something on the public internet that another person could actually use.
And that's a very different objective.
Sometimes the product is the project. The return on investment is everything you learn while building it.
That mindset makes starting much easier.
AI Didn't Solve the Problem, It Lowered the Barrier to Starting
I'm not a frontend developer.
Normally, that could have been enough reason to put this idea into the famous folder called:
“Things I'll build one day.”
AI changed that.
Using Kiro, I could describe what I wanted, see something working, test it, change my mind, break it, fix it and keep going.
Welcome to vibe coding. 😄
But I also learned very quickly that:
“AI can write the code” does not mean “AI can make all the decisions.”
You still need to decide what you're building.
You still need to recognise when something doesn't make sense.
You need to think about the user experience, architecture, security, cost and operations.
AI dramatically shortened the distance between idea and working software.
It didn't remove the learning journey.
If anything, it gave me access to a much bigger one.
“It Works on My Laptop.” Great. Now What?
Getting Qazo working locally was only one milestone. From the beginning, I knew I wanted to take it further and run it as a real application on AWS.
And I had a few principles in mind from day one:
Keep it lean. Keep the operational overhead low. Use serverless where it makes sense. And don't pay for infrastructure just because you can build it.
I've spent years designing and reviewing AWS architectures for customers, but there's something quite different about applying those decisions to a product you're building yourself.
Now every architectural choice was mine.
Should this component be serverless? Does this workload actually need a container? What should scale to zero or close to it? Where does persistent state belong? What's the simplest way to handle realtime communication? What am I paying for when nobody is playing Qazo?
The goal wasn't:
“How many AWS services can I fit into an architecture diagram?”
Quite the opposite.
“What is the simplest architecture that gives Qazo what it actually needs?”
That thinking led to a deliberately mixed architecture. Static frontend content could be served cheaply through S3 and CloudFront. DynamoDB on-demand made sense for usage that could be unpredictable. Realtime functionality could use serverless components, while the backend had characteristics where containers on ECS Fargate made sense.
And that's where building your own product becomes such a useful exercise.
You might already understand the services. You might already know the architecture patterns.
But now you have to make the trade-offs yourself — architecture, simplicity, security, scalability, operational effort and cost — all for one real application.
Knowing the building blocks is one thing. Having to choose which ones your own product actually needs is another.
That, for me, was where the project became much more than vibe coding.
Every Architecture Decision Eventually Meets the AWS Bill
I've spent plenty of time helping customers understand and optimise AWS costs.
But cloud FinOps gets surprisingly personal when it's your own AWS bill. 😄
Suddenly even a few dollars deserve an architecture review.
“What value is this component actually giving me?”
That's a much better question than simply asking:
“How do I make AWS cheaper?”
A serverless service that costs almost nothing while nobody is using Qazo behaves very differently from infrastructure that has a fixed hourly cost. An ALB, Fargate task or NAT Gateway needs to justify why it exists. DynamoDB on-demand, S3 and CloudFront have very different consumption profiles.
It becomes an interesting exercise in balancing cost, simplicity, availability, performance and operational effort.
And because it's your application, you can experiment.
Change something. Measure it. Simplify it. Look at the bill again.
Cost optimisation stops being a spreadsheet exercise and becomes part of product engineering.
From localhost to qazo.net
Then there was another milestone I particularly enjoyed.
I bought qazo.net .
There is something satisfying about watching an idea move from:
to:
Of course, buying a domain is the easy bit.
Now the architecture needs DNS, hosted zones, certificates and routing. Route 53 manages the domain, CloudFront serves the frontend, and the API and realtime endpoints have their own paths into the application.
None of these technologies were unfamiliar territory. What was valuable was seeing the complete chain belong to one product I was responsible for.
A user types qazo.net into a browser, and everything behind that simple action is something I designed, deployed and now have to operate.
That's when a side project starts feeling suspiciously like a real product.
If I'm Building It, I'm Building It as Code - Hello, Pulumi
Infrastructure as Code wasn't something I discovered while building Qazo.
It was something I wasn't willing to compromise on.
“If Qazo is going onto AWS, the infrastructure is going into code.”
A big shout-out here to Pulumi, which I used with TypeScript to build the AWS infrastructure.
Networking, compute, routing and the other infrastructure components could now be created and changed through code rather than becoming a collection of console clicks that I'd have to remember six months later.
And this is another reason I like building something end-to-end.
You don't just talk about Infrastructure as Code as a best practice.
You live with it.
Change the architecture. Update the code. Deploy it. Find something you don't like. Change it again.
Architecture stops being a diagram. It becomes something you can version, deploy and improve.
Then I Put AI Inside the Product AI Helped Me Build
This is where things became slightly meta.
AI helped me build Qazo. Then I used AI to help Qazo build Qazos. 😄
Hosts can use an AI-powered generator built with Amazon Bedrock and Claude to create completely new troubleshooting incidents.
You can choose the difficulty, AWS technologies you want to focus on, or areas across the six pillars of the AWS Well-Architected Framework.
But I didn't want the AI to produce this:
“Question 1: What is S3?” “Question 2: What is Lambda?”
That's trivia with an AI sticker on it.
The generated Qazo needed to feel like a production incident. One problem should lead to another. The architecture, symptoms, logs and metrics should support the diagnosis. Wrong answers should be plausible decisions an engineer might genuinely consider.
That introduced another interesting engineering problem.
Using an LLM is easy. Putting an LLM inside a product is different.
Now you have to think about prompt design, structured output, model selection, latency, token consumption, cost, hallucinations, validation and technical accuracy.
Qazo's generation pipeline even performs a separate AI technical review to identify weak, ambiguous or unsafe questions before they become part of the game.
AI didn't remove the engineering.
It created a new kind of engineering.
So, What Is Qazo?
The easiest way I've found to describe it is:
Live Quiz but for AWS troubleshooting.
A host creates a Qazo and shares a six-digit join code. Players open Qazo on any device, enter the code, choose a name and avatar, and they're in.
No player account. No download.
Everyone enters the same AWS production incident and works through it at their own pace.
Instead of asking whether you remember what an AWS service does, Qazo gives you architecture diagrams, logs, metrics, symptoms and clues.
Then it asks the more interesting question:
“What would you do next?”
The built-in scenarios cover areas including networking, security, containers, IAM, databases, serverless, observability, performance, reliability and Well-Architected practices.
There are scenarios involving traffic surges, container deployments, DDoS, Kubernetes, multi-region recovery, event-driven systems and even modern GenAI incidents involving things like RAG and Amazon Bedrock.
One Incident. Multiple ACTs. One Race to Resolution.
One of the ideas I wanted to preserve from the beginning was that Qazo shouldn't feel like a collection of unrelated multiple-choice questions.
A production incident doesn't normally work that way.
You fix one thing.
Something improves.
Then another symptom appears.
You investigate deeper.
So Qazo incidents unfold through multiple ACTs.
Incident → Investigate → Decide → Consequence → New Symptom → Investigate → Resolve
Wrong answers aren't deliberately silly options designed to make the correct answer obvious. They're decisions a real engineer might reasonably consider, and each decision has a consequence.
And because Qazo is multiplayer, everyone is working through that incident at their own pace.
Someone gets ahead.
Someone makes a wrong decision.
Someone overtakes you.
Someone reaches the final ACT.
The live leaderboard and Incident Race show that progression as it happens, with scoring, response-time tie-breaking and eventually a podium.
The goal isn't to remember AWS. It's to think AWS.
The Real Product Was the Learning Journey
Qazo now involves frontend development, containers, serverless components, WebSockets, DynamoDB, CloudFront, Route 53, Bedrock, authentication, DNS, networking, Infrastructure as Code, monitoring, security and cost optimisation.
But the biggest takeaway wasn't learning what each individual technology does.
It was seeing them all become part of one system.
Application development meets architecture. Architecture meets security. Security meets usability. Infrastructure meets cost. AI meets latency. Product decisions meet operational decisions.
When we work in technology, it's easy to encounter these things separately.
Building something forces you to connect them.
And that is why I think this exercise is valuable whether you're new to cloud or have been working with it for years.
The learning is different.
For someone starting out, it might teach what these services actually do.
For someone experienced, it forces you to make the trade-offs yourself.
Knowing the building blocks is one thing. Owning every decision that puts them together is another.
Don't Stop at “It Works”
This is where I think the biggest opportunity is.
Don't finish the exercise when AI gives you a working application.
“Look, AI built my app!”
Great.
Now deploy it.
Give it a domain. Secure it. Put real users on it. Monitor it. Look at the bill. Automate the infrastructure. Break something. Fix it. Optimise it.
Because the real learning isn't simply:
Prompt → App
It's:
Think → Build → Break → Learn → Deploy → Operate → Optimise → Repeat
AI makes it easier to get onto that journey.
It doesn't replace the journey.
And perhaps that's one of the most valuable things about vibe coding for technologists. It gives us the ability to explore areas outside our normal day-to-day role without spending months just getting to the starting line.
Now, Go Build.
Werner Vogels has been telling builders this for years:
“Now, go build.”
Turns out, it's pretty good advice.
Your idea doesn't have to change the world.
You don't need to know everything before you begin.
Just find something interesting enough that you want to see what happens if you build it.
Then take it further than localhost .
That's what I did with Qazo.
And if you'd like to see where that little idea eventually ended up:
Play Qazo at qazo.net
Think AWS. Play Qazo.
Have fun! 🎮
You don't need a brilliant idea to start building, sometimes the idea is simply an excuse to learn everything that comes next
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article