Vibe coding project ideas: 12 builds by difficulty, each with a first prompt

Build a single-page web app. No backend, no login.
User: a freelancer who quotes a day rate without counting unbilled days.
Screen: one form (target yearly net income, tax rate in percent, yearly costs, billable days) and one result card with the day rate needed.
Data: none stored.
Formula: needed revenue = net income / (1 - tax rate) + costs. Day rate = needed revenue / billable days. Show the formula under the result.
Do not build: accounts, charts, currency conversion, PDF export.
Done when: net income 60000, tax 25, costs 8000, 200 billable days shows 440 per day. Empty or zero fields show a message, never NaN or Infinity.

Keep the form values after a page reload using browser storage, no account. Add a Reset button. If the stored data is missing or corrupt, fall back to the defaults instead of showing a blank page. Do not change the formula.

Build a single-page web app. No backend, no login.
User: someone who wants to know what each plugged-in device costs per year.
Screen: an editable table (device name, watts, hours per day) plus one field for price per kWh. Each row shows its yearly cost; a total sits at the bottom, sorted most expensive first.
Formula: yearly cost = watts / 1000 * hours per day * 365 * price per kWh.
Data: keep rows in memory only.
Do not build: smart-plug connections, accounts, charts, device databases.
Done when: one device of 100 W for 10 hours a day at a price of 0.30 shows 109.50 per year.

Accept both 0.30 and 0,30 as the same number. Reject negative numbers and blanks with a message beside the field. Add five tests for the cost function, including zero watts and 24 hours. Show me the test output.

Build a single-page web app. No backend, no login.
User: someone with a short, unplanned window to exercise.
Screen: a minutes field, equipment checkboxes (none, dumbbells, band), and a Build session button that shows an ordered list with minutes per exercise.
Data: a list I will paste (name, minutes, equipment needed). Do not add exercises of your own.
Rule: only use exercises whose equipment is ticked or none.
Do not build: accounts, history, timers, video, progress charts.
Done when: 22 minutes with no equipment gives a list whose minutes sum to between 21 and 23.

Write the session builder as one pure function with tests for 5, 22 and 60 minutes, and for no equipment. If no valid session exists, show a message instead of an empty list. Show the test output.

Build a single-page browser game. No backend, no login, no sound.
User: someone who does push-ups and wants a reason to count them.
Screen: a monster with a health bar, a number input for reps, an Attack button, a log of the last five attacks.
Rules: damage equals reps. Monster 1 has 25 HP, monster 2 has 40 HP, monster 3 has 60 HP. A defeated monster is replaced by the next.
Do not build: accounts, leaderboards, shops, animations beyond the health bar.
Done when: 10 reps leaves monster 1 at 15 of 25, then 15 more defeats it and monster 2 appears at 40 of 40.

Move the rules into one module with no interface code: state in, action in, new state out. Add tests for the Done-when example and for reps of zero. The interface may only call that module. Save and restore progress in browser storage.

Build a mobile-friendly web app for one person documenting a rented flat on move-in day.
User: a tenant holding the keys, phone in hand.
Screen: a list of rooms; each room shows fixed prompts (every wall, each window frame, inside the oven) where I add a photo and an optional note.
Data: one table items (id, room, label, note, photo_path, created_at set by the database default) and one storage bucket for photos.
Do not build: sharing, signatures, PDF export, accounts.
Done when: I add 3 photos in 2 rooms, reload, and see all of them with timestamps from the database. A print view lists every item.

Enable Row Level Security on the table and the bucket. In plain words, list what a stranger holding only the public key can read, write and delete, then prove it with real requests using that key. If the answer is everything, stop and tell me what we need (probably sign-in) instead of loosening the policies.

Build a web page with one text box and an Ask button.
User: a teammate with a question about our handbook.
Data: markdown files in /handbook, which I will add.
Behavior: find the passages relevant to the question; ask the model to answer only from them and quote the passage used. If no passage supports an answer, return exactly: Not in the handbook.
Do not build: chat history, accounts, file upload, Slack, streaming.
Done when: of 10 questions I give you, 5 answerable ones return an answer with a quote and 5 unanswerable ones return exactly Not in the handbook.
Use a placeholder for the model key and tell me where it lives.

Show me every place the model key is read. It must be only in server code, in an environment variable without a VITE_ or NEXT_PUBLIC_ prefix. Search the built output for the key value and confirm it is absent. Add a limit of 20 requests per visitor per hour.

Build a small web app for one friend group.
User: someone about to buy a co-op game who wants to know which friends already own it.
Screen: a search box for a game title showing who owns it, and a form to add (your name, game title).
Data: one table owned_games (id, person, title, created_at).
Do not build: accounts, store imports, recommendations, profile pages.
Done when: I add Sam/Portal 2 and Ana/Portal 2, search for Portal 2 and see both names, and delete nothing.

Normalize titles in one function used by both saving and searching: trim, ignore case, strip punctuation. Add a unique constraint on person plus normalized title. Suggest near matches when a search finds nothing. Explain who can add rows today and how a leaked link would be abused.

Build a web page with a text area and a Make notes button.
User: a patient who wants a tidy page after an appointment.
Input: text I paste (what I remember or a transcript).
Output: four headings (What was said, What to do, What to watch for, When to come back), each a short list. Use only what is in the input. If a heading has nothing, write Nothing mentioned.
Do not build: accounts, saving, audio recording, advice, explanations of medical terms.
Done when: a pasted example with no follow-up date shows Nothing mentioned under When to come back.

For every line in the output, show the input sentence it came from; drop any line with no source. Make sure nothing the user pastes is stored, logged or sent anywhere except the single model request, and tell me where that request is made.

Build a web app with email sign-in.
User: a neighbour who wants to borrow a tool, or lend one.
Screens: sign in; my tools (add, remove); browse tools; request a tool for a date range; my requests.
Data: tools, requests (status: pending, accepted, declined, returned), users. A user can edit only their own tools.
Do not build: payments, chat, reviews, a map, notifications.
Done when: with two test accounts, A lists a drill, B requests it, A accepts, B sees accepted, and B cannot edit A’s drill.

Show a lender’s area only, never the street address, until the lender accepts a request. Write a test that signs in as a third user and confirms the address is not returned by the API, not just hidden on screen.

Build a web app with sign-in for one user.
User: a developer who skips the weekly review.
Source: my commits from one connected GitHub account, read-only access.
Job: a function generate_review(user, week_start) that lists the week’s commits grouped by repository and saves an editable draft, plus a page to edit it and answer two fixed questions.
Do not build: other sources, teams, email, sharing.
Done when: I can run generate_review by hand from a button and see this week’s draft. Access tokens are stored only on the server.

Schedule generate_review for Friday 16:00 in the user’s own time zone, using whatever scheduler my host provides. Make it safe to run twice: a second run for the same week must update nothing and create no duplicate. Test it by calling the function twice.

Build a web app where a buyer can reserve a monthly ad slot. Use the payment provider’s test mode and hosted checkout; card details must never touch our code.
User: a small business buying one of 5 slots for next month.
Screens: slot list (free or taken), buyer form (title, URL, email), then hosted checkout.
Data: slots (slot_number, month, status), orders.
Do not build: refunds, invoices, a seller dashboard, accounts.
Done when: a test-mode payment for slot 2 in a given month marks it taken, and the list shows it taken after reload.

Mark a slot as taken only inside the handler for the provider’s payment-confirmed webhook, after verifying its signature, and ignore repeated events with the same id. Add a unique index on slot plus month in the database. Write a test that confirms two payments for the same slot produce one taken slot and one failure.

Build a web app with sign-in for the couple only. Guests need no account.
User: a couple planning a wedding, and their guests.
Screens: the couple creates a page with cost items (name, amount); a public page shows each item as covered or open; a guest can pledge to an item with a name and no payment.
Data: pages, items, pledges.
Do not build: payments, messages, guest accounts, photos.
Done when: I create a page with 3 items, pledge the full amount to one as a guest, and the public page shows that item as covered.

List every API route that changes data and state which of them require the couple to be signed in and own the page. Write tests that call each route directly, with no browser and no session, and confirm every one is refused. A button being hidden is not protection.