Back to the course pageFree starter kit

What Could You Actually Build With AI?

Free · 12 min read · no account needed

Not how — that's the course. Just what's possible, and what each build actually involves. Every example below is a real build from inside Praxaria AI, exactly as it happens there. None of the people who built these write code.

1. A reading planner that re-plans itself

Enter the book, the page count and the deadline; it works out the pages per day. Life gets in the way? Move the date once, and the whole plan adjusts.

What it took:

  • Inputs: book, page count, deadline, days already spent.
  • The one rule that shaped it: the deadline had to be an input, not baked into the output — so the plan can change without a rebuild.
  • The test: move the deadline twice, on purpose, and check the plan stays sane.
  • The failure path: what happens if the page count is missing? Ask again — never invent.

A build this size takes an evening. The skill it proves is the one most people never practice: deciding which part of a tool has to give when life changes, before building it.

2. A band setlist generator with taste

Rules in: total under 45 minutes, no two slow songs back to back, always end on the closer. One click: the setlist, every rule honored. The course then does something most courses don't — it checks whether the tool quietly broke its own rules.

What it took:

  • Inputs: the song list, the rules, the occasion.
  • The rules, written down: every rule as one sentence, in the same words every time — "no two slow songs back to back," not "generally avoid slow stretches."
  • The test: feed the output back against the rules and see if it passes. A tool with taste is a tool that checks itself.
  • The failure path: not enough songs for the slot? It says so instead of padding.

This is the build where people discover that writing the rules precisely is most of the work. The tool came together in an afternoon; getting the three rules to a form the machine could actually enforce took the morning.

3. A family care site with five people in it

One private page per person, one shared page for the schedule — who visits when, what to check, what to bring. Five people, one place, no group-chat chaos.

What it took:

  • Inputs: each person's needs, the weekly visiting rhythm, the family's shared notes.
  • The boundaries: what's shared, what's private, who can change the schedule — decided before anything was built.
  • The test: two people updating the schedule at once, on purpose. What does the system do?
  • The failure path: a conflict between two entries gets flagged, not silently resolved.

The hard part was never the page. It was the boundaries — and solving them is what made five people with different habits actually use it. Projects like this one teach the seam the course calls systems, not tools.

4. A morning check that runs itself

A small process reads the moisture log on a small farm, flags anything out of range and drafts the message. When a reading is missing, it stops and says so — instead of inventing one. The stopping is the hard part. The course teaches exactly that.

What it took:

  • Inputs: the daily moisture log, the acceptable range, the recipient of the draft.
  • The rules: flag anything outside the range, in one line, with the reading attached.
  • The test: a reading deliberately missing, then a deliberately absurd one — 200 on a scale to 40.
  • The failure path: missing reading → stop and say so. Absurd reading → flag as suspect, don't forward.

Most of the effort went into the failure paths — what happens when a sensor reads nothing, when two readings contradict. A process you can trust is one that knows what it doesn't know — and says so. That principle is the difference between a demo and something you'd run on a real farm.

5. A weekly event digest that writes itself

Someone signs up; the list updates; a short draft announcement appears — built from the real entries, never invented ones. Sent by a person, written by the machine.

What it took:

  • Inputs: the live signup list, the announcement format, the send day.
  • The rules: draft from real entries only; keep it to the week's changes; nothing marketing-flavored.
  • The test: one deliberately weird signup — empty name, duplicate entry — to see how the draft handles it.
  • The failure path: a malformed entry is held for review, never guessed through.

The machine drafts from real entries only, and a person presses send. That division of labor — machine assembles, human decides — is the pattern behind almost every automation that people still trust a year later.

The parts every build is made of

Five very different builds. Look underneath, and it's the same six parts every time:

  1. The inputs — what goes in, and where it comes from.
  2. The goal — what "working" means, written down first.
  3. The rules — what the tool must and must never do, stated precisely.
  4. The output — what comes out, in the exact shape it'll be used.
  5. The checks — how you'll tell a correct result from a plausible one.
  6. The failure path — what happens when something is missing.

People who don't build assume step 1 is the hard part. It isn't. Steps 3 and 6 are — and both are judgment, not coding. That's why non-coders build these things: the material is decisions, and the course teaches you to make them in the right order.

Try one this week

The reading planner, in five steps, using the six parts above:

  1. Write the goal in one line: "a plan I can still hit after a bad week."
  2. List the inputs: book title, total pages, deadline, pages already read.
  3. State the rules: daily pages must be even, never above [your own ceiling], plan restarts from today.
  4. Ask AI for the plan — then deliberately move the deadline and check it adjusts.
  5. Break it on purpose: enter zero pages, a past deadline, a 5,000-page book. What does it do with each?

If step 5 surprises you — that's the course. Building is step 4. Building something you can trust is step 5, and that's the part nobody gets from a prompt pack.


None of these is a demo reel. This is the ordinary size of what the course's method produces: stated goals, small builds, honest tests.

If you didn't know AI could do that — that's the gap. Praxaria AI exists to close it.

Ready for the complete method?

Keep learning with Praxaria AI: a practical, self-paced program for building useful AI tools, workflows and agents, supported by projects, workbooks and build guides.