Beyond the Basics: What You Can Actually Build
Real applications you can build in a single session using plain English. No coding needed.
The meal planner tutorial shows you the process. This section shows you the potential. These are real applications you can build in Bolt.new, Lovable, or Replit in a single session, using nothing but natural language descriptions. No code. No framework knowledge. No computer science degree required.
Each project below is a starting point. The prompt gets you a working version in minutes. The next two sections are the bit nobody else will tell you, and the bit that will save you starting over: how to think before you build, and how to grow what you have built without breaking it.
Before You Start, a Hard-Won Lesson
The first time I used a vibe-coding tool like Bolt, I had so much fun building the front end of an app, choosing colours, adding panels, polishing the look, that I never stopped to think about the data underneath. By the time I went back to clean it up, the database was a tangled mess of half-baked tables and inefficient queries that had grown to fit whatever the last UI change wanted. I threw most of it away and started again. That is a costly mistake to make a second time.
The discipline that prevents it is one developers have been practising for decades. Think about the layers before you build.
- Data. What is being stored, and what does each piece look like? How does one piece relate to another? A meal planner needs Recipe, Ingredient, and Plan, with sensible relationships between them. A reading log needs Book, Author, and Note. Sketch this on the back of an envelope before you write a prompt.
- Logic. What rules apply? When you delete a recipe, what happens to the meal plans that reference it? When the user adds an ingredient that already exists, do you create a duplicate or merge it? Decide ahead of time, even if your first answer is "ignore the problem for v1".
- Interface. Only after the first two are clear, ask the AI to build the UI. The interface is the easiest layer to change later. The data layer underneath is the hardest.
You do not need to be technical to do this. You need to slow down for ten minutes before you start and tell the AI what each layer looks like. Even a rough "I want a Recipe with name, ingredients, prep time, and tags" gives the AI enough to build a clean foundation. Without that, it guesses, and the guesses are usually wrong by the third feature you add.
Start Small. Add Features.
Each project below is one prompt that produces a working starting point. None of them is a finished product on the first run. The pattern that produces good output is:
- Run the prompt and see what comes back. It will not be perfect. It does not need to be.
- Pick the one thing that is most wrong, or the one feature that is most missing, and ask for that one change. Not a list of ten. One.
- Wait for it to update, look at the result, then pick the next change.
This is the same iterative habit good software developers have been using for thirty years. The reason it works is that small changes are easy to verify. Large changes break in places you did not notice and cannot debug. The discipline of one change at a time, looked at carefully, then the next, is more important than which model you use or which platform you pay for.
Project 1: A Personal Knowledge Base With Semantic Search
What it does: A web app where you paste in articles, notes, book highlights, meeting notes, or any text. It indexes everything and lets you search not just by keywords but by meaning. Ask "what did I read about negotiation tactics?" and it finds relevant passages even if the word "negotiation" never appears in them.
Why it matters: This is the kind of tool that used to require a developer, a vector database, and an understanding of embeddings. Now you describe it and it gets built.
What to iterate on: Ask it to add categories, to sort search results by relevance, to add a "random entry" button for rediscovery, or to generate a summary of all entries matching a search.
Project 2: A Meeting Cost Calculator
What it does: You enter the number of attendees, their approximate salary bands, and the meeting duration. It calculates the real cost of the meeting in real time and compares it to alternatives. "This one-hour meeting with eight people cost your organisation $1,200. A well-written email would have cost $45 in time."
Why it matters: Everyone complains about pointless meetings. This tool makes the cost visceral and concrete. It is also a genuinely useful tool for managers.
Project 3: A Decision Matrix Tool
What it does: You define a decision (e.g. "which city should we move to?"), add your options (Melbourne, Brisbane, Perth), define your criteria (cost of living, job market, climate, lifestyle, proximity to family), weight the criteria by importance, then score each option against each criterion. The tool calculates weighted scores and shows you a clear winner with a visual breakdown of why.
Why it matters: This is how management consultants make decisions. The framework is well-known but tedious to build in a spreadsheet. As an app, it is interactive, visual, and shareable.
Project 4: An Interview Preparation Coach
What it does: You paste in a job description and your resume. The app analyses both and generates: the five most likely interview questions, suggested answer frameworks tailored to your experience, potential weaknesses an interviewer might probe, and three questions you should ask them. You can then practise answers and the app times you.
Why it matters: This combines document analysis with practical output in a way that is immediately useful for anyone job searching. It also demonstrates that vibe-coded apps can do real text analysis, not just forms and calculators.
Project 5: A Neighbourhood Research Dashboard
What it does: You enter a suburb or postcode. The app shows a dashboard with panels for demographics, property prices, transport links, lifestyle ratings, and nearby amenities. Everything on one screen, designed for someone evaluating whether to move there.
Why it matters: This information exists across dozens of websites. Nobody has assembled it into one dashboard. This is the kind of tool that real estate agents pay thousands for, and you can build a version of it in an afternoon.
What to iterate on: Once the UI works with sample data, you can ask Bolt to connect it to real APIs -- the Australian Bureau of Statistics, Domain property data, or Google Places. That is a more advanced step but the point is: the interface and logic are already built.
Project 6: A Book Club Discussion Generator
What it does: You enter a book title and author. The app generates: a brief summary suitable for members who did not finish the book, ten discussion questions ranked from accessible to provocative, three "this connects to real life" angles, and a suggested discussion structure with timing.
Why it matters: Every book club, reading group, or discussion circle needs this. The person who runs the group spends an hour preparing questions that could be generated in seconds. And the AI-generated questions are often better because they are designed to provoke disagreement, which is what makes a good discussion.
What These Projects Teach You
If you build even one of these, you will understand something that most people do not yet grasp: the barrier between having an idea and having a working application has effectively disappeared.
You do not need to learn to code. You do not need to hire a developer. You do not need a budget. You need a clear description of what you want, the willingness to iterate when the first version is not quite right, and about two hours.
The meal planner tutorial earlier in this guide teaches you the process. These projects show you where it leads.