The five kinds of software you can build with AI (and which one to start with)

Many people have a clear idea of the tool they wish existed in their life – a smarter house tracker, a better schedule, a screen that finally tells the truth about the bus or ferry. What’s missing isn’t the idea. It’s knowing what kind of software to build and which AI tools can turn that idea into something real.

Instead of memorizing complex tech stacks, you only need to recognize a handful of simple “shapes” that most software fits into. Once you know the shape, the rest of the decisions get much easier – especially now that AI coding tools can do most of the heavy lifting for you.

The era of personal software

We’ve entered a new phase where tiny, highly specific tools can be more valuable than big, polished apps. Think of:

• A private screen that shows when the next ferry will actually arrive, based on live ship signals instead of a broken timetable.
• A home maintenance app that knows only your house – your appliances, your plants, your yard, your repair history – and quietly generates the right jobs each week.

These aren’t startup ideas. They’re personal tools. They don’t need millions of users, an app store listing, or investor funding. They just need to work for you (and maybe a couple of people you share them with).

AI has made it possible for non‑technical people to build this kind of personal software. The key is to start from your wish – what you want to be different in your life – and then give that wish the simplest possible software shape.

The five shapes of software you can build

Almost every idea you have will fall into one of five shapes. Once you recognize which one you’re dealing with, you can pick tools and services without getting overwhelmed.

1. Local tool

What it is: Software that runs on a single computer and stores data on that same machine. No logins, no cloud, no accounts.

Good for:

• A document organizer on your laptop
• A private research notebook
• A utility that renames, sorts, or tags your photos
• Any tool that only you will ever use

Why choose this: It’s the simplest possible option. You don’t need a server, a host, or a user system. A coding agent (like Claude Code or Codeex) can set up a tiny local database such as SQLite and you’re done.

2. Web app

What it is: An app that opens in a browser from a link, but feels like a real app. You can add it to your phone’s home screen and use it on laptops, tablets, and phones.

Good for:

• A shared house maintenance tracker
• A small tool you want to share with a spouse, friend, or team
• Most personal software ideas that don’t depend on deep phone features

Why choose this: One version works everywhere. You avoid app store approvals, developer accounts, and a lot of complexity. For most people, this is the best default choice.

3. Native phone app

What it is: A traditional app installed from the App Store or Google Play, written specifically for phones.

Good for:

• Apps that need reliable push notifications
• Apps that use Bluetooth, background location, NFC, or other deep phone features
• Public consumer apps you want to distribute widely

Why choose this: Only if your idea truly depends on phone‑only features or public app store distribution. Otherwise, it’s usually better to prove your idea as a web app first, then move to native only if you must.

4. Background service

What it is: Software that may not have a visible screen at all. It wakes up on a schedule or when something happens, does a job, and sends the result somewhere else.

Good for:

• Checking a public record every morning and sending you a summary
• Processing files as soon as they arrive in a folder
• Sending alerts when a sensor crosses a threshold

Why choose this: When the value is in automation, not in a fancy interface. It’s about moving data from one place to another reliably.

5. Hardware project

What it is: Software that runs close to the physical world – on small devices, sensors, or boards.

Good for:

• A ferry‑time display that listens to ship radio signals (AIS)
• A custom home display, button, or sensor
• A local camera or factory sensor that must run on‑site

Common building blocks:

• Raspberry Pi – a tiny general‑purpose computer that can run a small database, a local web page, and background jobs.
• ESP32 – great when you mostly need to read one sensor or control one device.
• Home Assistant – ideal if you already have smart devices and just want one place to connect and automate them.

This shape is perfect when your software needs to touch the real world: radios, cameras, thermostats, lights, or custom sensors.

How to turn a wish into a software shape

Before you pick tools, you want to describe your idea in plain language. Ask yourself:

• What do I want to be different? (Before vs. after.)
• Where does the information come from? Photos, labels, manuals, sensors, public feeds, etc.
• Who needs to see or change it? Just you, your household, your team, or the public?
• Where should the result appear? Phone, laptop, tablet, a small screen in your house?
• What happens if it fails? Mild annoyance, missed ferry, or something serious like money, kids, or medical info?

For example, the house maintenance app might look like this:

• Desired change: “We always know what the house needs, when it needs it, and how to do it.”
• Inputs: Appliance labels, manuals, photos, service dates, plant info, repair history.
• Users: Two people sharing the same records.
• Output: A shared list on both phones.
• Risk: Inconvenience if wrong, but not life‑threatening.

That description already points to a private web app with a shared database, photo storage, and simple logins.

The easiest starting point for non‑technical builders

If you’re not a developer, the best place to start for a web app is a hosted AI builder. These tools let you describe what you want, then they generate the code, show you a preview, and give you a publish button.

Good options in this category:

• Lovable – a great default for a clean web app with the shortest path from idea to working interface.
• Replit – better when you need more than a web interface (scripts, servers, scheduled jobs).
• Bolt – another full‑stack web app builder that handles interface, database, auth, and hosting together.

With these tools, you don’t need to:

• Install programming languages
• Set up servers
• Learn the command line before seeing something run

For a first personal app, using a builder like Lovable is usually the fastest way to get from “wish” to “working link.”

Where your data lives: Lovable Cloud vs Supabase

When you build a web app with a hosted builder, you’ll quickly face a key decision: where should your data live?

Two common options:

1. Lovable Cloud (or the builder’s own backend)
• Easiest setup
• The builder manages the database and login for you
• Great when you just want something useful working quickly

2. Supabase
• A separate database and auth service built on PostgreSQL
• More setup, but more portable and standard
• Better if you care about accessing your data from other tools later or moving the app elsewhere

If this is your very first app and the stakes are low, using the builder’s own backend is completely reasonable. If you already know the data will matter long‑term, Supabase is worth the extra effort.

Going one level deeper: coding agents and modular tools

Once you want more control, you can move beyond all‑in‑one builders and let a coding agent work directly on your project files.

A common beginner‑friendly stack looks like this:

• Coding agent: Codeex or Claude Code (the AI that writes and edits your code)
• Code storage: GitHub with GitHub Desktop (to save versions and undo mistakes)
• Database & auth: Supabase (shared data, logins, file storage)
• Hosting: Vercel (puts your web app online with preview links)

Here’s how the roles break down:

• The model (e.g., OpenAI, Claude, GLM 5.3) provides reasoning and code-writing ability.
• The coding agent (e.g., Codeex, Claude Code) uses that model and gets access to your files, commands, and previews.
• The hosted builder (e.g., Lovable, Replit, Bolt) packages everything into one environment with a publish button.

You can mix and match: for example, use Claude Code as your agent but plug in a different model via API if the tool supports it. The important thing is that you own your project files and data, so you can change tools later without starting over.

If you’re interested in how to turn AI skills into real leverage, you may also find this breakdown of the only AI skill that actually makes you money helpful as a companion read.

Touching the physical world: sensors, Pi, and smart homes

When your idea depends on the real world – like the ferry example – you need a way to bring physical signals into your software.

Typical pattern for a hardware‑adjacent project:

• A sensor or signal (e.g., AIS ship radio, temperature, motion, moisture)
• A small computer (often a Raspberry Pi) to read and decode the signal
• A tiny local database (like SQLite) to store recent data
• A simple private web page to show the result
• A secure way to reach that page from your phone (e.g., Tailscale, which lets only approved devices in without exposing your Pi to the open internet)

If you already own smart lights, thermostats, or sensors, you can often start with Home Assistant instead of building everything from scratch. For single‑purpose sensors, an ESP32 with ESPHome can be enough.

And if wiring and electronics feel intimidating, remember: you can literally send photos of your boards and connections to a coding agent and ask it to identify pins, check your wiring plan, and help you troubleshoot. The line between “software person” and “hardware person” has never been easier to cross.

When you truly need a native phone app

If your wish absolutely depends on native phone features, you can still lean on AI heavily.

A common setup:

• Expo – lets you write one project that becomes both iOS and Android apps
• Supabase – for database, auth, and storage
• Expo Application Services – for building and signing the app packages

You’ll still need Apple and Google developer accounts if you want to publish in the app stores and pass their reviews. That’s why it’s usually smarter to:

1. Build a private web app first.
2. Use it with your real data and real life.
3. Only move to native if you truly need those extra capabilities.

Make the AI your partner, not your boss

One of the biggest risks for non‑technical builders is letting the AI quietly make important decisions about cost, privacy, or data without telling you. To avoid that, change the AI’s role: it should be a partner that must explain its choices.

A simple way to do this is to keep four small text files in your project that any model can read:

1. project.md
Describe in plain language:
• Who the software is for
• What happens today vs. what should happen instead
• Where it has to run (phone, laptop, home device)
• What information must stay private

2. decisions.md
Every time the AI reaches a choice that affects cost, data, access, deployment, or portability, it should:

• List the options
• Record its recommendation
• Explain why, in plain English

3. scenarios.md
List real situations the software must handle, such as:

• “Add an appliance from a phone photo”
• “Find the correct manual”
• “Create the next maintenance task and show it on both phones”

These become your test cases.

4. Agent instruction file
A short file just for the current tool (for example, claude.md or agent.md) that tells the AI how to behave: explain choices, protect secrets, update the other three files, and ask before doing anything public, costly, or destructive.

In that instruction file, you can say things like:

• “When a decision affects data, cost, privacy, or portability, explain it to me first in plain English.”
• “Give me 2–3 realistic options and your recommendation.”
• “Ask before making anything public or spending money.”
• “Never put API keys or passwords in code, screenshots, or GitHub.”

This approach keeps you in charge, even if you don’t write code yourself.

Understanding the basic building blocks (in plain English)

You don’t need to become a developer, but a few core concepts will help you make good decisions and talk clearly with your AI assistant.

• Interface: What the person sees and touches – screens, buttons, forms, lists.
• Database: Where structured information is stored – things like appliance name, model number, service date, task status.
• Authentication: How the app answers “Who are you?” (logins, accounts).
• Authorization: How the app answers “What are you allowed to see or change?” (permissions, which records belong to which user).
• Host: The computer that keeps your software running and reachable (Lovable, Vercel, Render, a Raspberry Pi, etc.).
• Integration: Anything your app pulls in from outside – weather feeds, calendars, sensors, email services, other AI models.

Not every project needs all of these. A simple local file organizer might need none of them beyond a basic interface. A shared household app will need a database and authentication. A public app will need all of them plus careful authorization rules.

Choosing a simple, sensible database

Instead of asking “Which database is best?”, ask a simpler question: What is the easiest way to get this data to the person who needs it?

Some practical defaults:

• SQLite – perfect for a single‑user tool on your own laptop or on a Raspberry Pi. Your coding agent can set it up for you in one go.
• Supabase – a strong default for independent personal web apps that may grow. It gives you PostgreSQL, auth, storage, and backend services in one place.
• Firebase – a good option if you’re building something mobile‑first or heavily tied to Google services.
• Builder’s own database (e.g., Lovable Cloud) – the fastest path when you just want to see something working.

For more on how to think about AI skills and leverage across tools, you might like this guide on what to do after you’ve learned Claude.

Deployment and security, without the jargon

Deployment simply means: put the working software somewhere it keeps running, and make sure the right people can reach it.

Examples:

• In Lovable, deployment might just be hitting “Publish” and getting a link.
• With Vercel, your coding agent can connect your GitHub project, create preview links for changes, and promote a version to “production” when you’re happy with it.
• On a Raspberry Pi, deployment means keeping the service running at home and using something like Tailscale so only approved devices can connect.

Security should be plain and intentional:

• Keep apps private by default; only make them public when you truly need public access.
• Use managed login systems (Supabase, Firebase, or the builder’s auth) instead of trying to invent your own password storage.
• Store API keys and passwords in your host’s secret settings, not in code, screenshots, or GitHub.
• Enforce access rules in the database (e.g., each household can only see its own records), not just by hiding buttons in the interface.
• If your app will handle payments, children’s data, medical info, or legal records, get it reviewed before relying on it.

For low‑risk projects (like plant reminders or a personal reading tracker), you can keep things simpler. As your projects get closer to money, kids, or health, raise your security standards.

Testing: how you know it actually works

AI tools are much better at building software than they used to be, but you still can’t skip testing. You don’t need fancy testing vocabulary. You just need to try real situations on the real device.

For the house maintenance app, for example, you might test:

• Can I photograph an appliance and create the right record?
• Does the app correctly store the model number and brand?
• Can both people see the same maintenance list on their phones?
• When one person marks a task complete, does it update for the other?
• What happens if the photo is blurry or the label is unreadable?

You can ask your coding agent to write automated tests, but you should still click through the scenarios yourself. There’s no substitute for a human saying, “Yes, this actually works for my life.”

Optional helpers for more advanced builders

Once you’re comfortable with the basics, there are optional tools that can help manage more complex projects and AI workflows:

• OpenBrain – for storing rich, messy personal context (like technician notes, recurring problems, reasons behind choices) in a way AI can use alongside your structured database.
• OpenSkills – to give your coding agents reusable “skills” or methods so they behave consistently across projects (e.g., always explaining choices, always protecting secrets).
• OpenEngine – to move work between different tools, agents, or people without retelling the whole story each time.
• Ringer – a multi‑agent system for advanced builders, where many cheap agents can safely work on the same system under one supervisor.

These are not required to build your first personal app. They’re there for when your projects become bigger, longer‑lived, or involve multiple tools and collaborators.

Your first hour: what to actually do

If you want to get started today, here’s a simple first‑hour plan:

1. Write down one wish. The piece of software you’ve wanted for years because nothing off‑the‑shelf quite fits.
2. Describe the before and after. What happens today vs. what should happen instead.
3. Identify the signal. What information would make it possible? Photos, labels, manuals, calendars, sensors, public feeds?
4. Decide where the result should appear. Phone, laptop, tablet, a small display at home? Who needs to see it?
5. Pick the simplest shape. Local tool, web app, native app, background service, or hardware project.
6. Choose a starting environment. For most people, that’s a hosted AI builder like Lovable for a private web app.

From there, you can let an AI coding agent help you build, but you stay in charge of the decisions, the data, and the direction.

Personal software matters because it can evolve with you. It lives right next to the real‑world problem and the person who cares about it most: you. With today’s AI tools, you no longer need to wait for a company to build what you need. You can start with one wish, give it a simple shape, and let AI help you turn it into something that quietly makes your life better every day.