How to build a personal app without coding

What happens when someone recommends a book?

Picture the moment you'll add it. You're talking to a friend and have your phone out. You know the title, but perhaps not the author. You'd like to save “Jo recommended this after our conversation about cities” before you lose the thought.

That tells you more about the app than a long feature list would. The title needs to be quick to enter. The author should be optional. The recommendation belongs somewhere you'll see it later. A required rating makes no sense for a book you haven't read.

Do the same exercise for your own idea: describe one ordinary use from beginning to end. You can draw the screen on paper if it helps. The builder can work out the code, but this part depends on knowing your routine.

Give the builder that situation

In Kaddy, start from the homepage's claim flow, create an app, and open its build conversation. Here's a request you can adapt:

Make a personal reading list I can use on my phone. I want to save a recommendation during a conversation, so only the title should be required. Also save an optional author, who recommended it, and why I want to read it. Use the statuses want to read, reading, and finished. Show the recommendation below each title. Let me add, edit, delete, search, and filter books by status. Leave ratings and reading goals out for now.

This describes the information and explains one important choice: why the form should be short. That explanation gives the builder something to work from when deciding the layout.

Expect a first draft. The request is a starting point for a build, and you may need to clarify the result before using it.

Use the screen before polishing it

Add three fictional books, leaving the author blank on one and writing a long recommendation on another. Can you finish the form without filling in information you don't have? Can you still read the long note on a narrow screen?

Then change a title, mark a book finished, and refresh. Open the app again from your phone. The saved values should still be there. Delete the third book and check that the other two remain.

If a step fails, tell the builder what you did and what happened: “I changed one book to finished, but it still appears under want to read after a refresh.” That gives it a problem to investigate. “The filter is broken” leaves much more to guess.

Make the next request smaller

Once the basics work, you can be more particular. Maybe the recommendation is hidden behind a tap, even though it was the reason for making the app. Try: “Show the recommendation under the title in the list, including long notes. Keep my existing books.”

Check the result before asking for the next change. If you change the form, filters, and layout together, it's harder to tell which request caused a problem.

Kaddy lets you review proposed changes and return to an earlier published app version. That can recover a screen you preferred. It doesn't undo edits to your book records, so check those separately rather than treating version history as a data undo button.

Let a few real recommendations come in

The next useful feature usually becomes obvious after some use. You might need to find everything one friend recommended. Or you might notice that you always add books from the same screen and never open the elaborate dashboard.

A request such as “let me tap Jo's name to see her other recommendations” comes from a real need. It's easier to judge than adding features because a reading app is supposed to have them.

In Kaddy, keep these requests in the build conversation. The regular app conversation is for discussing the books and your plans; it has its own memory. If the reading list itself is what you want to make, the reading tracker guide goes further into lending, unfinished books, and finding a recommendation months later.