How to Build a Todo App Without Code, Step by Step Guide
To build a todo app without code, describe what a task contains, how one gets added in under three seconds, and where the list lives when you switch devices. Zugo generates the app from that description, checks it opens in a sandbox, and publishes it live. A single screen build costs 6 credits.
There are hundreds of todo apps already, and most people who build their own do it because every existing one is opinionated about a workflow that is not theirs. That is a good reason. "It would look nicer" is not.
Why build a todo app when so many exist?
Three honest reasons, and one that is not.
The first is fit. Todoist, Things and TickTick are excellent and they each assume a method: projects and labels, or areas and someday, or a matrix. If your work does not fit the assumed shape, you spend your day translating between your head and the app.
The second is that your list needs a field nobody offers. A freelancer wanting an "invoice raised" flag on a task, a researcher wanting a source link, a parent wanting a child's name attached: small additions that no general app will add for you.
The third is that it should live inside something else you are building, sharing a login and a database with the rest of your tool. That is where a custom build stops competing with commercial apps and starts doing something they cannot.
The weak reason is aesthetics. A polished app you built in an evening will still lose to Things on the details that took that team years, and if you switch for looks alone you will drift back within a month.
What data does a todo app actually need?
Less than you think, and this is the discipline that decides whether the app survives its first week.
- Task. Title, done or not, due date, project, priority, notes. That is the whole thing.
- Project or list. Name, colour, and whether it is archived.
Everything else is a feature disguised as a field. Subtasks, tags, recurrence, dependencies, estimated time: each one adds friction to the add-a-task action, which is the only action that matters. Add them later, individually, after you notice the absence rather than predicting it.
Two behaviours deserve stating in the prompt. What happens to a completed task, and it should be hidden rather than deleted, because "what did I do last week" is one of the two questions a todo list answers. And whether an overdue task moves to today or stays on its original date, which is a personality question with no correct answer, so make it deliberately.
What should the build prompt say?
Describe the add-a-task interaction precisely. Everything else in the app is downstream of that one field.
A personal todo app.
Task: title, done flag, due date (optional), project, priority
(none / high), notes (optional).
Projects: name, colour, archive flag.
Main screen: a single text input at the top that adds a task on Enter
without opening a dialog. Below it, today and overdue tasks in one list,
each with a checkbox and the project colour as a dot.
Completed tasks stay visible, greyed and struck through, until the day ends.
Second screen: all tasks grouped by project, with a filter for done.
Third screen: a week ahead view, tasks grouped by day.
An overdue task stays on its original date and is marked overdue in red.
Keyboard: Enter adds, arrow keys move, space toggles done.
Calm palette, large tap targets, works well on a phone.
The sentence about adding on Enter without a dialog does more than any other line. A builder will otherwise give you an "Add task" button that opens a modal with six fields, which is the exact friction that kills the habit. General prompt structure is covered in how to build an app with AI.
Should tasks live in the browser or in a database?
A generated app can store tasks in the browser by default. That is genuinely fine for a single-device list you would not mourn, and wrong the moment you check the list on a phone.
| Requirement | Browser only | With a database connected |
|---|---|---|
| Add on a laptop, see it on a phone | No | Yes |
| List survives clearing site data | No | Yes |
| A shared list for two people | Not possible | Real accounts |
| A year of completed tasks you can search | Limited | A query away |
| Email digest of today's tasks | Not possible | Available with Resend |
Connecting Supabase gives the app Postgres storage and logins under your own account. After connecting it, run the test that matters: add a task on your phone, open the app on a laptop, confirm it is there. If it is not, that is the bug to fix before you use the app for anything real.
What does a todo app cost in credits?
Zugo charges per action rather than per seat. One screen is 6 credits, a multi screen app bills as a platform at 12 credits for the first three pages plus 3 for each page beyond, and each edit is 3 credits.
| Build | Screens | Credits |
|---|---|---|
| Single screen list with projects | 1 | 6 |
| Today, projects, week ahead | 3 | 12 |
| The above plus a completed archive and settings | 5 | 18 |
| One edit, such as adding a tags field | n/a | 3 |
Hi-Fi mode doubles the basic numbers, at 12 for a build and 6 for an edit. A personal list rarely justifies it. Free comes with 5 credits, which is below one build, so it is a look around. Pro is $25 a month for 200 credits, which is roughly 16 platform builds or 33 quick ones. Business is $99 a month. The pricing guide has the full picture.
Because edits are cheap, the productive pattern is one careful build and many small changes: "hide the priority field", "sort today's list by project", "make the checkbox bigger on mobile". Each is 3 credits and takes less thought than planning it in advance would have.
Which features should version one leave out?
Recurrence, and this is the one people argue about. "Every Tuesday" is describable and it is also the feature that most often comes back slightly wrong: skipped weeks, the completed instance behaving oddly, the next occurrence appearing at the wrong time. Add it as a deliberate second round with its own testing, not as a line in the first prompt.
Leave out subtasks too. A task that needs subtasks is usually a project, and the app already has projects. Adding a second hierarchy doubles the interface for a case one existing concept covers.
Also leave out any form of scoring, streaks or productivity charts. If tracking a repeated action is what you actually want, that is a different app, and a habit tracker models it properly with check-ins rather than tasks. A todo list that gamifies itself becomes a list you feel bad about opening.
What will an AI builder not do for a todo app?
Four limits, and in this category most of them live on the phone rather than in the app.
No native mobile notifications. A web app added to a home screen behaves like an app in most respects, but reliable scheduled push at 08:00 on every phone is not what a generated web build gives you. Email through Resend is the workable substitute.
Limited offline use. Adding a task usually needs a connection once the data lives in a hosted database. For a list you use on the underground, that is a real constraint.
No calendar or email integrations. Turning a starred email into a task, or seeing your meetings beside your list, needs connectors that are not part of the toolkit.
Complex logic arrives through edits. Dependencies, recurring rules with exceptions, and shared assignment across a team are all reachable by describing one rule at a time and testing it. Zugo does not replace a development team on a product that has to scale beyond a small group.
What is worth building first?
One screen, one input, a checkbox, and a database behind it. That is 6 credits and an evening, and after a week of real use you will know which two fields are missing, which is knowledge no planning session produces.
Then make exactly those two changes, at 3 credits each, and stop. The todo apps people keep using are the ones that stayed small. Describe your list in a paragraph at zugo.dev, and resist adding the third field until the app has earned it.