Shipping an Emergency Preparedness App with OpenSaas

Who

I am a Product Manager working with PepsicCo. My day job is PowerBI dashboards, data pipelines, reports, enormous Excel files, custom retailer data, mappings. I love it, yes. But it doesn’t scratch the itch of building something I want.

Why

This itch started when I became a dad. I realised that comfort and safety is achieved by being prepared to anything. Diapers? Check. Band-aids? Check. Something to drink? Check. But the list of things I had to keep track of started to grow more and more. Pandemic. Blackout. Heat wave. Inventory stockpile got larger. I noticed that some things already expired, so I introduced kanban-like monitoring and stock rotation.

Then I came across handbooks that tell you what to do when things go south. In US there are tools, a whole ecosystem helping organise and plan. In Europe this meant mostly PDFs, buried somewhere on a government website.

As a parent, this bothered me. So I decided to build it myself. That’s how it became Chroni.eu.

What

I spent time thinking about the stack - and you know, there are so many options. This is where being a PM actually helped - I started by speccing things out, without falling in love with ideas and tech.

It was quite clear what I wanted and what I didn’t want:

• SaaS - browser-first + auth with user management + payments;
• full-stack, no frontend-backend-auth stitching - I would go mad before shipping;
• AI-friendly - I “can” read and write code, but heavy AI assistance in building was a non-negotiable (I used Claude Code). I didn’t want to use no-code tools, because I wanted to learn how to operate AI agents with this project.

I looked at some boilerplates, but they “felt” messy, somehow unfit. Then I found OpenSaaS and Wasp.

Wasp describes itself as a full-stack React + Node.js + Prisma framework with superpowers. Well, it is quite accurate, but for me the biggest differentiator was something way simpler: it thinks in products, not in files AND it met all criteria I had.

OpenSaaS took even a step further. Immediately when I started, I had:

• Authentication - email, Google out of the box
• Stripe integration - subscription management, webhook handling done
• Admin dashboard with user management
• Landing page
• Email sending - all configured and ready to be used
• Background jobs - for any thing I might need later (like scheduled reminders or expiration date tracking)

This meant that I didn’t have to build any of that. The only thing I had to do is to replace demo contents with Chroni.eu. This saved me weeks (or even months) of trials and errors.

How

Quite possibly the process I used was quite different from typical. I didn’t start with code - I started with documents. Loads of documents.

Typical PRDs, specs, problem statements etc. I figured that if a vague prompt produces vague response, well-structured requirements might produce something I could actually ship.

So, I followed this workflow: Firstly - I defined what I wanted to build Secondly - I talked with Claude, brainstormed a little, expanded with more context Thirdly - reviewed and iterated

The end result? I had a spec I was agreeing with and I knew was buildable.

But that is just the first part of the work. With the specs done, the next challenge wasn’t code - it was content. I spent a good amount of time gathering knowledge.

I figured that what will make Chroni special is that it’s foundation is official recommendations. This meant that I had to get any official emergency preparedness handbook, read it and extract the essence of: what is needed in terms of inventory, what emergency situations are described there and how to actually act when they happen.

That was the easy part. The fun part was harmonising all this content. BBK (Germany) tells one thing about water storage, RCB (Poland) says something slightly different. I needed to present universal “best” practices while preserving the country-specific nuances. This was critical for the harmonised guides, but also for the inventory templates.

OpenSaaS gave me the foundation on top of which I built:

• emergency guides and quizes
• inventory management with template of over 90 items + emergency bag contents
• family plan
• multi-language support (currently English, German, Polish, with more coming soon)

Which… moves me to the what surprised me

I wasn’t prepared to how fast I could move. From first OpenSaaS git clone to a live product - weeks, not months. I believe this was possible, because:

• AI coding works well with well-structured codebase. This isn’t an insight that is Wasp-specific, but definitely this helped a lot. The structure meant that Claude Code had a clear pattern to follow, and when prompted, it was easier for Claude to build a feature - he understood where the action should go, how to define and how to wire up.
• the mindset of preparing the specs before coding - the coding becomes the easy part

Where… it sucked, where it didn’t

It wasn’t smooth sailing. I totally underestimated content complexity - harmonising dozen of emergency handbooks was a data problem. Then I learned the hard way of AI-generated technical debt. Hardcoded values, placeholders, scaffolds everywhere, TODO comments. Where my discipline didn’t help a lot, structure did (thank you, Wasp).

If you are a PM, a designer, anyone who thinks in products rather than in code, Wasp is worth a look. You can go from idea to deployed SaaS remarkably fast. Not “build a landing page” fast, but “end-to-end app” fast. Wasp’s structure makes AI-assisted development actually work. Heck, even I understood what is what.

Big thanks to Wasp for building OpenSaaS!

PS. You can read my story on OpenSaas blog, too.

Have questions or thoughts? Get in touch - I’d love to hear from you!