What You Can Genuinely Build
Pages, Tools and Automations
Start with the categories that reliably work. Landing pages and simple marketing sites: a page that explains something, collects an email, embeds a booking link. Internal tools: a form your team fills in, a dashboard showing numbers you already have, a small tracker that replaces a chaotic spreadsheet. Automations: when a form is submitted, add a row here and send a message there. Data views: take a file of numbers and draw the chart you keep making by hand. These all share a shape. Small amount of data, few users, low consequence if it is briefly wrong. You are usually one of the people using it. That combination is where AI-assisted building is strongest right now.
- Landing pages, waitlists, simple brochure sites with a form
- Internal tools that replace a spreadsheet nobody enjoys maintaining
- Automations that move information between things you already use
- Dashboards over data you already have and understand
Apps With a Database
A step up is a real application. People sign in, they create things, and those things are still there tomorrow. A booking system for your studio, a client portal, a simple marketplace listing, a job board. This is achievable, and it is where most people's ambition actually sits. It is also the first point where you are storing information about other people, which changes the stakes considerably. A broken landing page is embarrassing. A leaked customer list is a different category of problem. Nothing here says do not build it. It says that from the moment a database holds someone else's name, you have taken on a duty. Module five is about meeting that duty, rather than discovering it the hard way.
- Sign-in, saved records and things that persist are well within reach
- The moment you store other people's details, your obligations change
- Use a platform's built-in sign-in rather than inventing your own
- Build it, but read module five before anyone else touches it
Adding an AI Feature Inside Your App
You can also put AI inside the thing you build. Summarise these notes, draft a reply, tag this enquiry, answer questions about your own documents. Wiring this up is genuinely straightforward now: a handful of lines, and a service does the hard part. Two things follow. First, every one of those calls costs money, and your users will make far more of them than you will while testing. Second, the feature can be confidently wrong in a way ordinary software is not. A broken button looks broken, but a wrong summary looks fine. Both of these come up again in modules four and five. For now, know that the capability is available to you, and that it carries a bill and a failure mode.
- Summarising, drafting, classifying and question-answering are all reachable
- Every use costs money per request, not a flat fee — watch this from day one
- Wrong answers arrive looking exactly like right ones
- Great for drafts a human reviews; risky for anything that acts unattended
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.