How I Shipped Chroni with OpenSaaS—and Where AI Hurt

Chroni did not start as a side-project exercise. It started because becoming a parent changed the way I thought about preparedness.

The first version of the problem was mundane: diapers, plasters, water, and all the things I wanted available without a last-minute search.

Then came the pandemic, blackouts, heat waves, expiring supplies, and a growing personal system for checking and rotating stock.

Official preparedness handbooks existed, but in Europe the useful material often lived in country-specific PDFs. The advice was not organised around a family trying to prepare, maintain supplies, and know what to do under pressure.

That bothered me enough to build a product.

Chroni became a browser-based preparedness application with emergency guides and quizzes, inventory and emergency-bag templates, a family plan, and English, German, and Polish versions.

The application came together with heavy AI assistance on Open SaaS and Wasp. It reached production in weeks rather than months.

This is not a claim that any product manager can ship a responsible SaaS by choosing the same tools.

It is an account of where leverage came from, where it did not, and which parts of product work became more important when code became easier to produce.

The stack choice was a scope decision

My day job as a product manager at PepsiCo involves Power BI dashboards, data pipelines, and large Excel files.

I can read and change code, but I was not looking to assemble and operate every layer of a web application from scratch.

Before comparing tools, I wrote down the product boundary I needed:

• browser-first SaaS;
• authentication and user management;
• subscription infrastructure;
• one coherent full-stack project rather than a hand-built frontend, backend, and auth integration;
• email and scheduled work for reminders and expiry tracking;
• code I could inspect and own;
• a structure an AI coding agent could navigate;
• enough direct control that the project would teach me how to operate an agent, not only how to prompt a hosted builder.

This was less a technology scorecard than a statement about what I refused to spend the project on.

Authentication, billing webhooks, admin tooling, and background jobs are real product work. They were not the reason Chroni should exist.

Open SaaS provided those foundations on top of Wasp. Its current feature overview includes preconfigured authentication, payments, an admin dashboard, email, jobs, and deployment options.

The exact feature set will change, so anyone choosing it should inspect the current documentation rather than treating my 2026 starting point as a permanent promise.

What mattered to me was ownership with constraints. I could begin inside a coherent application instead of asking an agent to invent the architecture as it went.

I started with documents because ambiguity was the expensive part

I did not begin by asking Claude Code to build an emergency app. I began with problem statements, product decisions, requirements, flows, and constraints.

The documents were not a waterfall attempt to predict the whole product. They were a way to expose disagreements before an agent could turn them into code at machine speed.

For each area, I tried to establish:

• what the user was trying to do;
• which states and roles existed;
• what information had to persist;
• which country or language differences mattered;
• which behaviour was out of scope;
• what would make the work acceptable;
• which questions still needed a human decision.

Then I used the agent to explore options, challenge gaps, and implement bounded parts. I reviewed the result and changed the specification when the conversation revealed a weak decision.

A good specification did not guarantee good code. It made a bad result easier to identify.

“The user can manage inventory” leaves the agent to decide what management means.

A model of quantities, expiry, storage locations, emergency bags, reminders, shared household access, and country-specific templates creates a much more inspectable task.

The AI-assisted workflow guide goes deeper into that operating model: bounded tasks, explicit authority, evidence, review, and rollback rather than a long prompt followed by hope.

The difficult domain work was not code

Once the application shell worked, I expected feature development to be the hard part. The emergency content became the real system-design problem.

Chroni’s content is based on official preparedness recommendations. I collected handbooks from agencies including Germany’s BBK and Poland’s RCB, then extracted inventory guidance, emergency scenarios, and actions.

The sources did not form one clean dataset. They were written for different national systems, hazards, households, and policy contexts.

Even apparently simple guidance such as water storage could differ. A global “best practice” would erase useful local context; reproducing every document separately would leave the family to reconcile it.

I had to decide what was genuinely shared, what remained country-specific, how to record provenance, and how one concept should behave across guides, inventory templates, quizzes, and languages.

That changed the domain model. Content stopped being copy placed into screens. It became structured product data with source, jurisdiction, translation, update, and reuse consequences.

The work also made one limit clear: an emergency-preparedness product must not create authority it does not have. Harmonisation cannot turn a product editor into an emergency agency.

Country-specific official instructions still need to remain identifiable, especially where conditions or public systems differ.

System Design for Product Managers explains the adjacent discipline: preserving boundaries, ownership, failure paths, and change consequences before a convenient interface hides them.

Why Wasp’s structure helped the agent

AI coding tools work with the context they can recover. In an improvised codebase, the agent has to infer where server operations belong, how auth is enforced, how data reaches the client, and which convention is real.

Wasp gave the project a visible full-stack structure. Its official site describes a high-level specification layer connecting routes, pages, operations, auth, data models, jobs, and deployment.

That is vendor documentation, not independent evidence that Wasp will make every agent reliable.

In this project, the structure reduced architectural guesswork. When I asked for a feature, the agent could usually find an existing pattern and extend it.

This is the part I mean when I say the framework “thinks in products, not files.” I could reason about an authenticated page, an operation, a scheduled job, and the entities involved without first designing a set of glue conventions.

The constraint also made review possible for me. I was not only watching files appear; I could trace how the feature was declared and wired.

The benefit was not that Claude Code understood the product. It was that the project exposed enough structure for me to notice when it did not.

AI made debt faster too

The build was not smooth.

Generated changes left hardcoded values, placeholders, duplicate scaffolding, phantom routes, and TODO comments. A feature could appear complete in the browser while its states, permissions, or recovery path remained unfinished.

The agent was particularly capable of extending a pattern and particularly dangerous when the pattern itself was provisional.

Early shortcuts became examples for later changes. If I failed to remove one hardcoded assumption, the next implementation could reproduce it consistently across the product.

I learned to inspect more than the visible result:

• search for placeholders, TODOs, and hardcoded product values;
• follow permissions on the server, not only the interface;
• examine empty, error, retry, and unauthorised states;
• check whether generated migrations and seed data match the intended model;
• look for copied logic that should have one owner;
• run the real build and deployment path, not only local development;
• keep a list of deliberate debt rather than trusting memory.

AI increased the value of a Definition of Done because it increased the amount of plausible-looking work I could produce before understanding its operating consequences.

AI Governance for Product Teams covers the wider boundary: evidence, authority, failure cost, human review, and release controls for AI-assisted work.

Deployment exposed what local success had hidden

My first Railway deployment attempts were more difficult than expected. The initial setup bundled work incorrectly, and later builds failed for different reasons.

That was not evidence that the framework or platform could not deploy the application. It was evidence that I had treated deployment as the last command instead of part of the product system.

The approach that became reliable for me used GitHub Actions: changes pushed to the production repository followed a consistent build and deployment path.

It also became a reusable pattern for my other projects. I would still review current Wasp and Railway deployment options before choosing the same route today.

Localisation created another boundary problem. The authentication pages did not support Chroni’s multilingual experience in the way I needed at the time.

My CSS workaround shipped, but it introduced awkward UI states that were hard to repair through agent prompting alone.

The lesson was not “CSS is difficult.” It was that a boilerplate’s least-flexible product surface can become the most expensive part of a differentiated experience.

Auth, payments, email, legal content, and account recovery are not peripheral just because the starter kit supplies them.

What I would preserve in the next build

I would choose the stack from the product boundary again. The template removed categories of infrastructure work and let me spend more attention on the domain only this product had.

I would start with specifications again, but make the following records explicit earlier:

1. a domain glossary with source and jurisdiction rules;
2. an authority map for users, administrators, the agent, and external services;
3. acceptance examples for important states, not only feature descriptions;
4. one production path established before the application grew;
5. a generated-debt review after each meaningful slice;
6. localisation tests on framework-owned surfaces;
7. provenance and review triggers for official guidance.

I would also resist one conclusion that the speed invites: reaching production is not the same as proving the product.

Chroni going live proved that I could assemble and operate this version of the service. It did not, by itself, prove sustained use, commercial demand, or that every preparedness recommendation was appropriate for every household.

Those are separate evidence jobs.

The part only the product builder can own

Open SaaS supplied foundations. Wasp supplied structure. Claude Code supplied implementation capacity.

None could decide how conflicting emergency guidance should be represented, which obligation a family should see, where a country-specific instruction must remain separate, or which shortcut was irresponsible.

Those decisions were the product.

AI-assisted development reduced the distance between a decision and executable software. That made clear thinking more valuable, not less.

The practical advantage for a product manager was not becoming an engineer overnight. It was being able to carry a product decision further into the system, inspect what came back, and learn where my own model was incomplete.

The longer version of my original conversation with the Wasp team is published on the Open SaaS blog.

Sources

• Chroni (the live product described in this case study)
• Open SaaS (official current feature overview; capabilities may change)
• Wasp (official current framework overview; vendor description, not independent performance evidence)
• Open SaaS interview about the build (published 13 April 2026; first-person project account)

Read next

• AI-Assisted Product Workflow: Keep the Decision Chain Intact
• System Design for Product Managers: Make the Boundaries Explicit
• AI Governance for Product Teams: Control Exposure and Authority