The 5 Types of Software You Can Build with AI

TL;DR — Not every idea belongs in an app store. Most products you actually need fall into exactly five technical formats: a local tool, a web app, a native app, a background service, or a hardware project. Recognizing the right format saves you months of misguided development and determines whether you get started in half an hour with a hosted AI builder or combine a coding agent with Supabase and Vercel. For solo entrepreneurs in the DACH region (Germany, Austria, Switzerland), a web app is usually the right first step — the rest are less common, but sometimes the only option.

The Problem: You know what you want, but not how

Most people who try their hand at AI builders don't get stuck on the code. They get stuck in the confusion about where to start. They know roughly what they want to improve — an unreliable spreadsheet, a process that needs explaining from scratch every quarter, information that is live somewhere but never reaches its destination. But whether that translates into a script, a website, or a small device is written in the stars.

This is exactly where the real work begins: describing the desired change in a way that dictates the technical format — before a single model writes a single line of code. A widely discussed YouTube video illustrates this with two projects: an Amsterdam ferry tracker that intercepts the legally required AIS radio signals of ships using a Raspberry Pi, an antenna, and a receiver for around 200 euros in total, just to finally arrive at the pier on time; and a home maintenance app built for exactly one apartment — its appliances, its plants, its garden — that automatically generates the maintenance tasks for the week.

Neither of these is "fancy" software. They are small, specialized, and fit perfectly into one person's life, just as no mass-market app ever could. That is the core of Personal Software — and exactly why you need a map of the five formats.

Getting Started: Five questions before the first line of code

Before you choose a tool, answer these five questions. They determine the format more than any model choice:

• What change do you want? Not "an app," but: What must measurably feel different for you?
• Where does the signal come from? Is the information in the real world (radio, sensor, camera), in a file, in an API — or is it just in your head?
• Where should the result appear? On a phone, on a desktop monitor, on a display at the kitchen table, or not visible at all?
• Who is allowed to see and edit? Just you? A partner? A team? This determines whether you need logins and permissions.
• What happens if it fails? Annoying but harmless — or truly safety-critical? This massively scales your effort.

These questions practically provide the answer: A project that receives a physical signal and displays the result locally becomes a hardware project. A project where two people need to keep the same list in sync on two phones is a web app with a shared database.

The five formats at a glance

1. The local tool: The easiest route

A local tool runs on a single computer and works with files or a small local database (usually SQLite). It is the absolute simplest route for anything that only you use — a document organizer, a private research tool, a utility that renames and sorts a thousand photos. It needs no website, no login, no host. You basically tell the coding agent: "Set yourself up on my laptop and build this" — and you're done.

When to choose it: When the information remains private, lives on one machine, and no other human will ever need access. In this case, any cloud infrastructure is pure overhead.

2. The web app: Your default for Personal Software

The web app opens via a link, runs in the browser, and can be saved to the phone's home screen. It is the recommended default for most personal projects unless you have a specific reason to make it more complex. A single version runs on a laptop, iPhone, and Android. You can share it with partners or colleagues without going through an app store or getting an Apple "Developer Account."

The typical architecture for such an app is simple: a shared Supabase backend (Postgres database + login + file storage), the web app in front, and Vercel as the host, which gives you preview links before you overwrite the live version. This exact combination — web app + shared database + host — makes the home maintenance example possible: Two people see the same up-to-date list on two different phones.

Important for the database decision: Hosted builders like Lovable will later ask if the data should reside in their own managed cloud backend or in Supabase. The proprietary cloud is the shortest path; Supabase requires slightly more setup but keeps the database and auth in a widely used Postgres standard — which saves your portability. The rule of thumb: Change the interface early, not the data. Migrating an app's data years later is far more difficult than putting a new frontend on it.

3. The native app: Only if the phone needs more

This is what most people understand by "app" — Apple has trained the word for years. But it costs more effort. You only need it if your product relies on a deep phone function: reliable push notifications, Bluetooth, background location, NFC, or pure app store distribution. Otherwise, don't jump into the deep end.

The practical path is a coding agent with Expo: One project becomes an iOS and Android app, and a build service handles most of the signing and packaging. You still need Apple and Google developer accounts and must pass their reviews — which is a real, somewhat tedious process. Therefore, the rule applies: Prove your idea first as a private web app, unless the phone's capability is inseparable from your idea. You don't want to pay the app store "tax" just to find out if your partner even likes the maintenance list.

4. The background service: Software without a screen

A background service might have no UI at all. It wakes up — on a schedule or triggered by an event —, does its job, and sends the result somewhere. It checks a public dataset every morning, processes a file as soon as it arrives, or sends an alert when a sensor exceeds a threshold. At its core, it's a transformation step: taking data from a source and delivering it to a destination. Such services often don't need a "product feel," but they do need clean trigger logic and a place for the result to land (email, chat, database).

5. The hardware project: Software as close to the world as possible

Here, the software lives as close to the physical world as possible: the AIS ferry receiver, a display on the kitchen table, a camera, a factory sensor. The choice of the small computer depends on the task:

• Raspberry Pi — a small general-purpose computer, ideal when a receiver or an antenna needs a continuously running decoder.
• ESP32 — perfect when the task is almost exclusively "reading a sensor" or "switching a device."
• Home Assistant — the fastest entry point if the devices already exist in the house and you just want to unify them in one place.

The key leverage: The closer you are to the existing sensors of a standard smart home, the less you have to build yourself and the more you can simply wire off-the-shelf components. And because modern coding agents can now read photos of circuit boards and components, identify connections, explain pins, and verify your setup, the boundary between software and hardware person is more permeable than ever.

The two routes: Hosted Builder vs. Coding Agent

Once the format is set, tool decisions become almost trivial. You essentially have two families:

The hosted builder (Lovable, Replit, Bolt) is the fastest path for the very first web app: You describe the software, the builder creates the project, shows you a preview, and gives you a publish button. You don't install a programming language, you don't start a server, you don't even need to understand the command line — yet you have something runnable. If the project requires more than a web interface (Python scripting, an always-on server, scheduled jobs, a mobile build), Replit is the stronger candidate because it packs more of the infrastructure into a service. Bolt is another great option for a fast full-stack web app.

The coding agent is the next level — and yet still not just for experts: Codex or Claude Code see your project files, modify them, start the app locally, read errors, and try again. Add to this GitHub Desktop for visual version control, Supabase for the shared database, and Vercel for the publishing step. The big advantage: You can swap one component without swapping everything. The model can change while the database stays. The host can change while the code stays. The interface can change without moving the data — it's just a different window into the same room.

Model ≠ Coding Agent ≠ Builder — and why that matters

People compare these three as if they were the same product. They are not. The layering is clear:

• The model is the pure thinking and coding capability layer.
• The coding agent gives the model access to a folder, commands, previews, and tools.
• The hosted builder packages agent + environment + publish button into one product.

From this layering comes great freedom: Model and work environment don't have to come from the same company. You can run an open model like GLM 5.2/5.3 through a supported coding tool stack. For the very first build: Choose one environment, not three. True freedom doesn't come from letting three models argue over every button, but from the fact that you own the project files, the data, and the decisions — and you know what the model is doing.

Keeping the model on track: Four small files

The most common mistake when building with AI isn't code, but hidden decisions. The model suddenly chooses a familiar database without explaining, adds a paid service, or makes the app public. The solution isn't a magical prompt narrative — but a role change: The model acts as a building partner that discloses its decisions. In practice, this means keeping four small text files next to the project that any model can read:

• project.md — who the software is for, what happens today, what should happen instead (before/after), where it needs to run, and what information remains private.
• decisions.md — every time the model makes a choice affecting costs, data, access, deployment, or portability, it logs the options, the recommendation, and the reasoning — especially if the decision was made together with you.
• scenarios.md — the real situations the software must handle (e.g., "Add a device via a phone photo, find the matching manual, generate the next maintenance task"). These real cases are your test cases.
• agent.md / claude.md — the brief instruction file for the respective coding agent. It only dictates how the current tool behaves; the permanent truths remain in the first three files.

# agent.md
You act as a building partner who must disclose decisions.
If a choice affects costs, data, privacy, portability, deployment,
or maintenance: explain it in plain English.
- Provide 2-3 realistic options.
- Recommendation: pick one for this project and justify it.
- State what becomes easier / harder to change later.
- Ask before doing anything public, expensive, or destructive.
- No secrets in code, screenshots, or chats.

# project.md (Example)
Goal: Maintenance app for exactly one apartment.
Before: Reminders on Post-its, no shared picture.
After: Both partners see the same list on two phones.
Runtime: In the browser, private, only 2 logins.
Private: Serial numbers, photos, manual links.

Security: Private over public, control in the backend

The security rules sound like a lot, but they are simple:

• Private by default. Only make the app public if you truly need public access — and then use a managed login system. Don't invent password storage yourself when it already exists.
• Secrets stay out. API keys and passwords belong in the secret settings of your host (e.g., Vercel), not in visible code, screenshots, chat transcripts, or GitHub.
• Access control in the backend, not in the UI. "Hiding a button" is not permission control. The fact that your household cannot read another household's data is enforced in the database. Supabase is strong for this — and this is exactly the most common, severe mistake when two households use the same product.
• Prove backup + recovery. If the data is important: create a backup and test the recovery. For payments, children's information, medical, or legal data: have the software audited before use.
• Don't start with sensitive data. Start with the simple stuff and move into more secure apps as your risk profile grows.

Testing: No "done" without a real handshake

You don't need testing vocabulary at the beginning. You need the situations that affect you in writing — and then test them on the device where it will actually run, and see if it works. In the house example, this means: Can I take a photo of an appliance and create the right card? Does the model number persist? Does my partner see the same list? What happens if the photo is unreadable? Test the unhappy paths too.

And the most important sentence: There is no substitute for a human saying: This actually works. You cannot simply ask Lovable, Codex, or Claude Code to "test if everything works" and then trust it. The model delivers a result, not a guarantee.

Your first hour — how I get started

If you want to get started right now:

1. Write down the one thing you've wanted to build for years.
2. Describe what it looks like today and what it should look like instead.
3. Identify the signal or information that makes it possible.
4. Determine where the result appears (which screen, why) and who is allowed to see it.
5. Ask: What would be bad if it fails?

Then go back and choose your build format. For the very first, private web app with minimal setup: Lovable — using the managed cloud, unless you know data portability is more important to you (then Supabase from day 1). If you want more control, open Codex or Claude Code. If a sensor is involved: Raspberry Pi, Home Assistant, or ESP32 — and let the coding agent work on the wiring.

Conclusion: The format is half the battle

The layer most people miss is not the model and not the builder — it is the crucial question before the first line of code: Which of the five formats does your desire fall into? Once the format is set, the tool decisions are almost self-evident, the security questions are clear, and the first build is possible in hours instead of months. The era of Personal Software no longer belongs just to technologists who live near products — but to people who live near their own problems. And they are often the ones who know best what they are missing.

FAQ

Do I really need a web app for Personal Software?

Not automatically — but in most cases, the web app is the fastest, cheapest, and most portable starting point because one version runs on both laptops and phones and can be shared without an app store. Choose a local tool if the data can remain privately on one machine, and only opt for a native app if you truly need deep phone functions like push notifications, Bluetooth, background location, or NFC. If you are unsure: Start with the web app and prove the idea before diving into app store processes and their associated costs.

What is the difference between a Coding Agent and a Hosted Builder?

The coding agent (e.g., Codex, Claude Code) works within your own project files, sees errors, starts the app locally, and changes code, whereas the hosted builder (Lovable, Replit, Bolt) bundles the environment, database, auth, and publishing into a single service. The practical consequence: With the agent, every component remains replaceable — the model, the host, and the interface can change independently while the data stays put. With the hosted builder, you get the shortest path from description to interface but pay with more platform lock-in.

How do I stop the model from forcing surprising decisions on me?

You change its role: The model acts as a building partner that must disclose its decisions, rather than hiding them silently in the code. Specifically, you maintain four small files — project.md (goal, before/after, privacy), decisions.md (every choice with cost/data/deploy implications + reasoning), scenarios.md (your real test cases), and agent.md/claude.md (behavioral rules for the current tool) — and expect the model to name two or three options for every consequential choice, recommend one, and ask before taking any public, expensive, or destructive action.

Is a native app worth it for an internal tool?

For an internal tool, it is overkill in the vast majority of cases because app store reviews, Apple and Google developer accounts, and signing processes create real friction that you shouldn't need. A web app in the browser or an internal Expo build for your own family covers the same use cases without the store friction. Choose a native app only if your product is functionally tied to a deep phone capability that cannot be compromised — otherwise, the web app delivers the same function at a fraction of the effort.

How do I ensure two households can't see each other's data in an app?

Access control belongs in the backend, not in the interface — a hidden button is not a real restriction. Enforce the boundary in the database (with Supabase, via Row-Level Security or equivalent mechanisms) so that a login can only read or edit the records of its own household, and add this boundary as one of the cases in your scenarios.md tests. Furthermore, avoid confusing the error of "this looks finished" with "this is secure": Actively verify that a second household cannot see the first's data before rolling the product out to multiple parties.

Can I run an open model like GLM inside a coding tool?

Yes — the model and the work environment do not have to come from the same company, and this is one of the greatest freedoms in today's AI tooling. You can operate an open model like GLM 5.2 or 5.3 via an API key inside a supported coding tool stack, maintaining control over the environment, data, and deployment at the same time. However, for the very first build, I recommend choosing a single environment instead of cramming multiple models into one project — the real freedom comes from owning the files and data, not from deploying three agents simultaneously.

Sources

• Video systematically breaking down the five forms of software: "Nobody Laid Out The Five Kinds Of Software You Can Make. So I Did." — https://www.youtube.com/watch?v=joRXo6x7Pgk
• Lovable (hosted AI builder for web apps): https://lovable.dev
• Replit (builder with stronger infrastructure): https://replit.com
• Bolt (fast full-stack web apps): https://bolt.new
• Supabase (Postgres + Auth + Storage): https://supabase.com
• Vercel (Hosting & Preview links): https://vercel.com
• GitHub Desktop (visual version control): https://desktop.github.com
• Raspberry Pi (small general-purpose computer): https://www.raspberrypi.com
• ESP32 (single-sensor device): https://www.espressif.com
• Home Assistant (central connection for existing home devices): https://www.home-assistant.io
• Expo (one project → iOS + Android): https://expo.dev
• Codex (Coding Agent): https://openai.com/index/introducing-codex/
• Claude Code (Coding Agent): https://www.anthropic.com/claude-code
• GLM 5.2 / 5.3 (open models by Z.ai): https://z.ai
• SQLite (local database): https://sqlite.org