Why does this matter to you as a PM?
You don't need to code to prototype anymore.
That's not a hot take. You've heard it a hundred times.
But there's a difference between knowing that, and having actually done it.
Building something real, even something small and silly, changes how you talk to your engineers, how you design software, and how you think about trade-offs.
Having built a small, simple prototype gives you a basic foundation. That foundation is what lets you ask better questions, and work better with your engineering team.
The overall process
Building an app comes down to five things.
→ Know what you want to build
→ Write it down as requirements
→ Turn that into code, saved somewhere real (a repo)
→ Test it, at every stage, not just at the end
→ Deploy it somewhere publicly accessible
Step 1: What to build
I run a free workshop teaching non-technical PMs how APIs work. For the hands-on part, I needed something attendees could poke at without breaking anything real.
I looked for an existing sandbox first. The usual one people point beginners to (Swagger's Petstore demo) works, but it's generic.
Nobody remembers a fake pet store.
It also didn't have the flexibility I needed, and I couldn't build reliable exercises and quiz questions on top of it.
So I decided to build my own app and my own APIs. A food delivery app, because everyone already understands how food delivery works: an order, a driver, a status that changes.
At first I had a doubt: am I overkilling this? Building a custom app for a one-hour workshop, is it really worth it?
But a bit of research told me I could build something simple in an hour. So I went ahead, and I'm glad I did.
Step 2: Write the requirements
I opened up Claude and wrote, in plain language, what I wanted the app to do.
My app needed:
→ A front-end storefront, plus a Swagger page specifically for testing the APIs
→ Orders, drivers, and restaurants, with real-feeling data attendees could query
→ The four standard actions (create, read, update, delete an order)
→ Data that lives in memory, not a real database, so I could reset everything back to a clean playground before each session
→ A set of "seeded" orders that are locked, read-only, so people can look but not accidentally wreck the demo
→ One API key, so everyone unlocks the same version
→ A map, so attendees could see a driver's location update and watch the app call a completely different company's service to draw it
→ A taco theme, because why not, branded as Maria's Tacos, in my own brand colors
That's the whole spec.
The trade-off I made on purpose
Here's what saying yes to that "data lives in memory" line actually looks like, once it's a running app:
Browser to storefront to your API to the Swagger playground, with one branch out to OpenStreetMap for the map tiles.
The trade-off worth calling out: no database.
Everything the app knows (orders, drivers, restaurants) lives in memory. That means:
→ It's fast, and there's nothing to configure or pay for
→ One restart, or one click on my reset endpoint, wipes it completely clean
→ If Render restarts the service for any reason, all the data disappears with it
For a real product, that's a dealbreaker. You'd lose customer orders.
For a workshop sandbox that resets between every session anyway, it's actually the right call, not a shortcut I settled for.
This is the same decision you make constantly as a PM, just with different stakes.
Do you build the durable, correct version, or the version that's good enough for what this actually needs to do right now?
Here, the disposable version was the better engineering choice.
Step 3: Claude and GitHub
I handed those requirements to Claude and it wrote the actual code: a small MariasTacos app with a built-in Swagger playground where you can test every endpoint in the browser.
For the map, Claude wired in OpenStreetMap, an open source mapping service. A driver's coordinates from my own API get drawn as a pin on a real map.
That one addition became one of the best teaching moments in the whole workshop.
Did I review the code? No. I don't have that coding knowledge.
I know that for the best app performance, you always want to review code. But for what I'm doing, the potentially verbose code AI writes is more than good enough.
I didn't touch GitHub during the building part. Once the code was ready, I created a new repo in my GitHub, dragged the files in, and hit commit. No terminal needed. Really simple.
Step 4: Test every version
And as any PM knows, testing matters just as much as development.
It's not enough to have the code. You need to make sure it does what it's supposed to do: functionally, in the way you'd expect.
But also when something unexpected happens, and under load (I had to think about a class of up to 30 people).
Every time Claude changed the code, I checked it before trusting it:
→ Ran the app and clicked through every endpoint myself
→ Checked that the locked orders actually stayed locked
→ Confirmed the reset button really did reset everything
→ Tried to break it: wrong inputs, missing fields, requests without the API key
Step 5: Deploy
Now that I had the code in my repo, I needed to deploy it somewhere so it could actually run as an app.
Render was my choice: easy to set up, with a free tier.
Though I ended up paying 9 euros a month, so the app would start fast for the first participant and not crash under a small load.
→ Go to render.com, sign up, and choose "New Web Service"
→ Connect it to your GitHub repo
→ Deploy
You get a public link. Mine is the storefront at taco-api-bta4.onrender.com, with the Swagger playground at taco-api-bta4.onrender.com/docs.
