What You Can Actually Build

Before you pick a tool, it helps to know what you are even allowed to want. "An app" means about six different things, and they differ enormously in how hard they are to make and to give to people.

The main kinds

A website. Pages of information — a shop front, a portfolio, a guide. People visit a link. This is the easiest thing to make and to publish, by a wide margin.

A web app. A website that does something: a calculator, a to-do list, a dashboard. Still opened with a link, no installing. From a builder's point of view it is a website with more logic, which is why it is the best place to start if you want something interactive.

A phone app. The kind you install from the App Store or Google Play. Can use the camera, notifications, GPS. Also, honestly, the hardest first project — because publishing means developer accounts, paid yearly fees on at least one platform, app review by a company that can say no, and a separate build for iPhone and Android.

A desktop app. Installs on a Mac, Windows or Linux machine and runs from the dock or start menu. Can reach files on that computer. Publishing is easier than phone apps — no review board — but you do need to build a version per operating system, and users have to trust an unfamiliar installer.

A browser extension. A small tool that lives in the browser toolbar and changes pages you visit. Cheap to make, genuinely useful, and it does go through store review.

A bot or automation. Something that runs on a schedule or reacts to messages — a Discord bot, a script that files your email. No screens to design at all, which some people find a relief.

An API. Software with no face, built for other software to talk to. Worth knowing the word; not a first project.

The one that trips people up

A great many people say "phone app" when what they actually want is a web app that works well on a phone. Those are very different jobs.

A well-built web app on a phone looks and feels close to an installed app, can be added to the home screen, and needs no store, no review, no yearly fee, and no separate iPhone and Android versions. You send someone a link and they are using it.

You genuinely need a real phone app when you need things only the operating system grants: reliable push notifications, background activity, deep camera or sensor access, or working properly with no internet. If you do not need those, the web version gets you to real users faster and cheaper.

What "hard" actually means here

Building is not usually the hard part any more — that is what changed. The hard part is delivery: getting the thing into someone's hands.

Ranked by how much delivery friction you take on:

• Easiest: website, web app. Publish to a URL, share the link, done.
• Middle: browser extension, bot, desktop app. A store or an installer, but no gatekeeper who can reject you outright.
• Hardest: phone apps. Accounts, fees, review, and two platforms.

This is why this course uses web projects for its examples. Not because phone apps do not matter — because you learn every transferable skill faster when publishing takes a minute instead of a fortnight.

Your turn

Take the small idea from the last stage and answer two questions:

• Which kind is it really? Be honest — could it be a web app instead of a phone app?
• Does it need anything only a phone or a desktop can do? Camera, notifications, files on the machine, working offline. If not, build the web version first.

Write down your answer. In the next stage you will pick a tool, and the right tool depends entirely on what you just decided.