From Idea to "If She Stopped": Building a Full-Stack App With Kiro in Under 12 Hours
I used Kiro to build a full-stack simulation app — React, Node/Express, and a Python Flask stats API — in under 12 hours. Here's the tech stack, the API design, and what actually surprised me about spec-driven development across three services.
From Idea to "If She Stopped": Building a Full-Stack App With Kiro in Under 12 Hours
I went into this expecting Kiro to help me write code faster. I didn't expect it to handle three separate services — a React frontend, a Node/Express backend, and a Python Flask stats API — coordinating with each other, in about 12 hours, start to finish.
Here's what building If She Stopped with Kiro actually looked like — the idea, the stack, what Kiro got right, and what surprised me.
The idea
If She Stopped is a simulation app that visualizes the invisible labor women carry — as mothers, partners, caregivers, professionals, and more. Users select roles and responsibilities, run a simulation, and see the ripple effect of what would happen if she stopped doing them.
It's not a small single-page app — it's a real multi-service system, which is exactly why I assumed it would be the hard test case for an AI-assisted build.
Tech stack
| Layer | Tech |
|---|---|
| Frontend | React 19, Vite, Tailwind CSS |
| Backend | Node.js, Express, MongoDB, Mongoose |
| Stats API | Python, Flask, PyMongo |
| Auth | JWT + bcrypt |
Three services, two different languages, one shared MongoDB database.
Project structure
1
2
3
4
5
6
7
8
9
10
11
12
13
if-she-stops/
├── frontend/ # React app (Vite)
│ └── src/
│ ├── components/ # UI components
│ ├── App.jsx # Main app logic
│ ├── data.js # Roles, tasks, insights data
│ └── api.js # API client
├── backend/ # Express REST API
│ ├── routes/ # auth, simulate, user
│ ├── models/ # User, SimulationLog
│ └── server.js
└── python/ # Flask stats microservice
└── app.pyWhat the app actually does
- Role selection (Mother, Partner, Caregiver, Professional, and more)
- Task/responsibility simulation with impact messages
- Streak tracking and badges
- Reflection journal
- Daily challenges
- Shareable simulation cards
- Stats dashboard (top roles, top tasks, daily trends)
- User authentication
API design
Node.js backend (
/api)| Method | Route | Description |
|---|---|---|
| POST | /auth/register | Register a new user |
| POST | /auth/login | Login |
| POST | /simulate | Log a simulation |
| GET | /user/profile | Get user profile |
Python stats API (
/api/stats)| Method | Route | Description |
|---|---|---|
| GET | /overview | Total sims, users, avg tasks |
| GET | /top-roles | Most selected roles |
| GET | /top-tasks | Most selected tasks |
| GET | /daily | Simulations per day (last 7 days) |
| GET | /impact-distribution | Task count distribution |
Splitting the app this way — a Node API for user-facing actions (auth, simulate, profile) and a separate Flask API purely for stats/analytics — meant the two backends never needed to touch each other's logic. They just read from the same MongoDB data independently.
What Kiro handled well
React frontend. Component structure, the role-selection UI, simulation logic — all came together cleanly. This was the smoothest part of the entire build.
Flask stats API. The five stats endpoints above, including the PyMongo aggregation for things like top roles and daily trends, came together with very little back-and-forth from me.
Node/Express backend. Auth (JWT + bcrypt), simulation logging, MongoDB models via Mongoose — this also went smoothly. I expected this layer to need the most manual intervention, since it connects everything else, and it didn't.
What actually surprised me
Going in, I assumed a spec-driven AI tool would be fine for a single service but would struggle to keep three services — in two different languages, with different responsibilities — consistent with each other. That didn't happen. The frontend's API calls, the Node backend's routes, and the Flask API's endpoints all lined up with very little manual reconciling.
That's the real surprise: it's not that Kiro wrote good code in isolation — it's that spec-driven development held up across service boundaries, which is usually where AI-assisted builds start to fall apart.
The build, roughly
- Started from the idea and a rough spec of what the app needed to do
- Kiro scaffolded the project structure across
frontend/,backend/, andpython/ - Built out the React UI and simulation flow
- Built the Express API — auth, simulation logging, user profile routes
- Built the Flask stats microservice on the same MongoDB data
- Wired environment variables and got all three services talking to each other locally
Total time: somewhere between half a day and a full day — close to 12 hours.
Running it locally
Prerequisites: Node.js 18+, Python 3.10+, MongoDB running locally on port 27017
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Backend
cd backend
npm install
npm run dev
# Runs on http://localhost:5000
# Frontend
cd frontend
npm install
npm run dev
# Runs on http://localhost:5173
# Python Stats API
cd python
pip install -r requirements.txt
python app.py
# Runs on http://localhost:5001My work in git:
https://github.com/dharshinishri2217/Kiro-AIDLC
What I'd tell someone trying this
If you're evaluating Kiro for a multi-service project, don't assume you need to keep the scope small to get good results. The place I expected the most friction — coordinating separate services in different languages — was the place I hit the least.
Have you built a multi-service app with Kiro? Curious whether others saw the same thing, or hit friction I didn't.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article