Vibe coding projects for product managers

A project only counts if it can fail

Most build-something-this-weekend lists optimise for finishing. That is the right goal for your first ever build, and the wrong one for your fifth, because a finished habit tracker proves only that the tool works. The projects below are chosen for a harder property: each one can come out wrong in a way you would notice, which is the only condition under which building it teaches you anything about product work rather than about prompting.

The rule that makes this real is small and annoying to follow. Before the first prompt, write down the sentence the finished thing has to make true, and the observation that would prove it false. Then build. If you cannot write that sentence, you have chosen a project that cannot fail, which means it also cannot pay you back.

The ten projects, and what each one proves

Project	The product skill it proves	The check that tells you it worked
A meeting cost calculator for your own leadership team	Turning an argument you keep losing into an artifact	Someone who disagreed with you changes a scheduling decision
A definition-of-done checker holding your team's real checklist	Encoding a team standard precisely enough to be testable	A teammate uses it once without you explaining it first
A pricing calculator for your product's current plans	Understanding your own unit economics well enough to model them	It reproduces last month's actual revenue within a few percent
An interview quote tagger with your real theme taxonomy	Synthesis discipline under a fixed set of labels	Two people tagging the same transcript pick the same top three themes
A public changelog built from your last ten releases	Writing for users instead of for the team	An outsider can say what changed and why it matters to them
A one-question survey with a results view	Designing an instrument that produces a decision	You wrote the decision rule before the data arrived and did not move it after
An onboarding checklist tracking per-user completion	Instrumenting activation rather than describing it	Its numbers agree with what your analytics already report
A competitor feature tracker you feed every Friday	Keeping a research habit alive past the enthusiasm	It still has entries in week four
A prioritization scorer running your team's real framework	Finding out whether the framework survives real inputs	It ranks the current backlog in an order someone argues with
The internal tool your team asks for out loud and never gets	Reading demand correctly	Someone asks you to change it

The last column is the part worth copying even if you build none of these. A check stated in advance turns a weekend project from a demonstration into an experiment.

Why the first one is already a Builders Camp challenge

The meeting cost calculator is not an invented example. Zero to Shipped with Vibe Coding builds its practical challenge around exactly that tool: a PM has 45 minutes, builds a first version that calculates meeting cost from attendee salary bands and duration, and leaves it half-working with four known defects and a leadership presentation on Thursday. You get 60 minutes and someone else's code.

Naming it here is deliberate, because it shows what the finished version of one of these projects honestly looks like. The challenge's four defects are a hardcoded salary dropdown with no custom rate, a total shown in currency but not in person-hours, unstyled default browser output, and a delete handler that takes its index from the page rather than the data, so removing an attendee from the middle of the list leaves a ghost figure in the total. Three of those are visible. The fourth is the one that would have embarrassed her in the meeting.

How do you size one of these to a single weekend?

Cut until there is one screen and one calculation. The competitor tracker is a table and an add form, not a scraper. The changelog is ten entries typed by hand, not an integration with your issue tracker. The survey is one question, not a branching instrument. Every one of these projects has an ambitious version that takes three weeks and teaches you less, because the extra two weeks are spent on plumbing rather than on the judgment the project was chosen to exercise.

Using AI to Build Your First Product formalises this as its opening module: scope the smallest shippable product, then turn it into a build plan with explicit flows and data needs before prompting. Its format is 2 weeks, 12 hours total, 8 of them taught across 4 live sessions of 120 minutes, and the scoping step is the first thing it spends time on rather than the last.

Where these projects stop being safe

Two of the ten want real people's data, and both should be built with invented records. The interview quote tagger is the obvious one: research transcripts contain named customers saying candid things, and a weekend build has no access control, no retention policy and no deletion path. The onboarding tracker is the quieter one, because per-user completion data feels like product telemetry rather than personal data right up until someone asks you to delete a record.

The general form of the rule is worth stating once. A vibe coded project is safe while the worst case is a wasted Saturday. It stops being safe the moment the worst case involves someone else's information, someone else's money, or a permission that decides who sees what.

Which one should you build first?

Pick by what you are currently losing, not by what sounds impressive. If you keep losing the same argument in the same meeting, build the artifact that settles it. If your team disagrees about what done means, build the checker and watch which items people quietly skip. If you suspect your prioritization framework is theatre, run your real backlog through it and see whether the output is defensible.

There is one exception to picking by need. If you have never built anything this way before, build the changelog, because it has no state, no logic and no data model, and it will teach you the loop with nothing else in the way. Then pick by need from the second project on.

Who this is for, and who it is not for

This fits a product manager or founder who has already built one or two small things with AI assistance and wants the next round to earn its weekend. It assumes you can scope, prompt, review and fix without needing the mechanics explained, and it assumes you have real work these projects can attach to.

It is not the right starting point if you have never opened one of these tools. Weekend project ideas with AI tools covers the practice-the-loop version with lower stakes, and side project ideas for product managers covers the portfolio-shaped version aimed at interviews rather than at your current job.

Build the second one with people watching

The projects above are self-directed by design, which is also their weakness: nobody is waiting for the result, so nothing forces triage. A cohort supplies the missing constraint. Zero to Shipped with Vibe Coding runs 1 week with 2 live sessions of 90 minutes and 11 self-paced microlessons, and it sits inside the Vibe Coding Expert Track alongside the longer builds for people who want the full sequence rather than one bootcamp.

See the Zero to Shipped with Vibe Coding bootcamp

For the tool walkthroughs these projects assume, see building a prototype with Lovable and building an MVP with Replit. For the prioritization project specifically, the RICE prioritization framework and the ICE scoring framework are the two formulas most teams are actually running, and the scorer you build will expose which inputs your team has been guessing at.