Vibe Coding Ideas

A good vibe coding project is small, has one main screen, stores a little data and is useful to you on day one. Below are ideas grouped by size and risk, plus a method for cutting any idea down until it ships. These are starting points, not launches: nobody has posted one here yet. Checked 31 October 2026.

How to choose

Pick the idea by the cost of being wrong, not by how impressive it sounds. A tool you use yourself that loses a note is an annoyance. An app that charges strangers and loses an order is a problem. Start at the low end of the table and move up once you have shipped something.

App builders target different jobs. Bolt's own help centre lists marketing sites, portfolios, online stores, dashboards, internal tools and presentations as use cases. Lovable describes itself as a platform for full-stack web apps with backend, database and sign-in. Both fit the small and medium rows. For the tool differences see Lovable, Bolt and our list of the best vibe coding tools.

Small ideas (a weekend)

Tools for yourself. They teach you the loop of prompt, preview, fix.

• A habit or workout tracker with one page and a streak count.
• A reading list with status (to read, reading, done) and a notes field.
• A recipe box where you paste a recipe and tag it.
• A personal budget view that reads numbers you type in. Keep it manual, so no bank access is needed.
• A packing list generator that takes a trip type and a number of days.
• A study flashcard deck with a simple review order.
• A one-page link-in-bio site.
• A meeting notes template that exports to text.

What they have in common: one user, no payments, nothing that harms anyone if it fails. Good practice for a first project.

Medium ideas (a week or two)

Small groups, sign-in, shared data. This is where access rules matter. A common weakness in generated apps is that one user can read another user's data, so test with two accounts.

• A club or team sign-up sheet with slots and a waitlist.
• A shared household chore board with who did what.
• A small business booking page where customers pick a time. Start with email confirmations only.
• An internal request tracker for a small team: title, status, owner.
• A simple CRM for a one-person business: contacts, last contact date, next step.
• A class or community directory with profiles and a search box.
• A feedback board where people post and upvote ideas.
• A portfolio site with a contact form, with the form checked for spam.

Larger ideas (plan before you prompt)

These can work but carry cost if they go wrong. If you build one, write the rules first and have the result reviewed.

• An online shop. Payments, refunds and tax rules are not a place for guesses.
• A marketplace. Two kinds of users, disputes and trust.
• Anything with health, legal or financial advice. Wrong output has real consequences.
• Anything that stores children's data.
• A tool that sends email or messages at scale. Deliverability and consent apply.

For a project like these, read secure a vibe-coded app first, and consider vibe code rescue services if you reach a point where the app works but you do not trust it.

Ideas that suit coding agents more than app builders

If you are comfortable in a terminal, an agent such as Claude Code or Cursor fits work that app builders handle poorly:

• A command-line tool that renames or sorts your files.
• A script that pulls data from an API into a spreadsheet.
• A small browser extension for one site you use.
• A static site generator for your notes.
• Tests and docs for a repository you already have.

The difference between the two styles is covered in vibe coding vs agentic coding.

Make any idea smaller

Most vibe coding projects stall because the idea is too big. Use this cut:

1. Name the one user and the one job. "A tracker for my team's leave days" beats "an HR platform".
2. List the three things the user must be able to do. Anything else is a later version.
3. Decide what data it stores. If the answer is "personal data", slow down.
4. Cut the sign-in if only you use it, or keep it and nothing more.
5. Write the brief in five sentences and paste it as your first prompt.
6. Ship the ugly version. Share it with one person before you polish it.

A Bolt tip from its original README applies to any builder: be specific about frameworks and libraries up front, scaffold the basics first and then add features, and batch simple instructions into one message to save credits. Both Bolt and Lovable bill by usage, so small steps cost less to repeat.

Check the size against the plan

Tools price differently, and the free tiers are small.

Figures are from each vendor's pricing page as of 31 October 2026. Run one small task on the free plan and see what it used before you plan a big one.

What to do with the result

When it works, you have three useful moves:

• Keep it private and use it. That is a fine outcome.
• Share it with a few people and watch what they do.
• Launch it here. Read how launches work, then follow launch your project.

If you used a particular builder, the pages for built with Lovable and built with Bolt explain what to say about it.

A word on honesty

Do not describe a weekend prototype as a product. If it stores people's data, say what it stores. If you do not know how it handles sign-in, find out before you invite anyone. People forgive a rough tool that says what it is. They do not forgive a polished one that leaks their email.