Types of Applications
The shapes software takes.
24 kinds of application, roughly in order of how much machinery is involved. Each one unlocks something the simpler ones cannot and charges for it in complexity — so the useful question is never "what is best", it is "what is the least I can build that does this?".
Every type lists ideas of its shape — or jump straight to all 59 application ideas.
Colours mean Static & content Runs in the browser Database-backed Automation AI-powered Mobile & offline Desktop, CLI & extensions Games Hardware & IoT
The one you might not need to build
A spreadsheet, a form, and a group chat, wired together in an afternoon.
Examples
What it is
Off-the-shelf tools arranged into something that does the job — a shared spreadsheet as the database, a form service as the input, a group chat or email as the notification. No code, no repo, no deploy.
Good for
- Testing whether a workflow is real before automating it
- Fewer than ~50 records and fewer than ~10 people
- Anything you would abandon in a month without regret
Trade-offs
- Falls apart at scale — in rows, in users, and in rules
- You cannot shape it; you get the vendor's opinions
- Per-seat pricing that quietly outgrows the cost of building
- Your data lives somewhere you do not fully control
Technologies typically used
A spreadsheet, a form builder, and an automation service to connect them
Very simple static website
Pages of information. Nothing moves, nothing is stored, nothing can break.
Examples
What it is
A handful of pages written once and served as plain files. A visitor's browser downloads them and renders them. There is no server deciding anything, no database, no accounts, and no way for a visitor to change what anyone else sees.
Good for
- Anything whose job is to tell people something
- Surviving a spike of traffic without a thought — files scale for free
- Sites you want to still be up, untouched, in five years
Trade-offs
- No interactivity beyond links and anchors
- Changing content means editing files and redeploying
- Anything that needs to remember something needs a different type
Technologies typically used
A static site generator, hosted free on GitHub Pages, Netlify, or Cloudflare Pages
Static site with a CMS
The same free, unbreakable site — but you can write a post without opening a code editor.
Examples
What it is
A static site plus a Content Management System — an admin screen where you type a post, hit publish, and the site rebuilds itself and redeploys. The visitor still gets plain files; the CMS only changes how those files get written.
Good for
- Anything you will update weekly rather than yearly
- Handing writing over to someone non-technical
- Content with a shape — posts, recipes, case studies, products
Trade-offs
- One more moving part to set up and keep working
- Publishing waits on a rebuild (usually under a minute)
- You have to define the shape of your content up front
Technologies typically used
A static site generator plus a git-based CMS that commits markdown to the repo
Static site that buys its backend
Forms, payments, bookings, and email — rented from services instead of built.
Examples
What it is
A static site that hands off every job needing a server to a company that already solved it: a form service collects submissions, a payment provider takes money on its own hosted page, a scheduling service books time, an email service sends the confirmations.
Good for
- Selling a small number of products or a single service
- Applications, signups, waitlists, and enquiries
- Getting to revenue before getting to architecture
Trade-offs
- A monthly bill per service, and they add up
- Your data is scattered across four vendors' dashboards
- Checkout and forms look like the vendor, not like you
- Joining data across services means exporting CSVs by hand
Technologies typically used
A static site plus a hosted payment link, a form endpoint, and a scheduling widget
Static site with sign-in
Named people can log in and edit — or read something not meant for everyone.
What it is
A static site where identity matters: contributors sign in with Google or a similar provider to edit content, and sometimes visitors sign in to see pages that are not public.
Good for
- An organisation's site or blog with several editors
- Members-only pages, internal handbooks, club resources
- Any content where you need to know who changed what
Trade-offs
- Identity is genuinely the first hard concept on the ladder
- Truly private content needs a server to enforce the check
- Someone now owns access — adding and removing people forever
Technologies typically used
A static site with a git-based CMS behind an OAuth provider
App that runs entirely in the browser
Real software, real interactivity, no server anywhere — the data never leaves the device.
Examples
What it is
A page that is genuinely an application — it calculates, edits, draws, tracks, plays — but does all of it in the visitor's browser. Anything it saves goes into that browser's own local storage. It is still deployed as static files.
Good for
- Tools that transform input into output — converters, calculators, editors
- Single-player use where nobody needs to share state
- Sensitive data you would rather never receive in the first place
Trade-offs
- Clear the browser data and the work is gone
- No sync — the same tool on a phone and a laptop are two separate tools
- Nothing can be shared, collaborated on, or recovered
- Everything you ship is visible to the user, so no secrets
Technologies typically used
A front-end framework or plain JavaScript, storing state in the browser
Command-line tool
No interface at all — just a command that does one thing well.
Examples
What it is
A program you run by typing its name in a terminal. It takes arguments, does work, prints a result. Interface design collapses into choosing a few flags and a sensible output format.
Good for
- Repetitive personal chores — renaming, converting, fetching, summarising
- Anything with no audience but you and possibly your colleagues
- The first version of something that might become a real app later
Trade-offs
- Only reaches people comfortable in a terminal
- Distributing it to others is more annoying than the code was
- No discoverability — nobody finds a feature they were not told about
Technologies typically used
A script in Python or Node, installed globally or run directly
Automation that runs without you
Software with almost no interface — it wakes on a schedule or a trigger and does the work.
Examples
What it is
A job that runs on a timer or in response to an event — a new email, a form submission, a webhook, a file appearing — does something useful, and goes back to sleep. Often there is no screen at all; the output is a message, a row, or a file.
Good for
- Reminders and nudges nobody should have to remember to send
- Moving information between two systems that refuse to talk
- Recurring reports, digests, exports, and backups
Trade-offs
- Silent failure is the default — it stops and nobody notices for a month
- Debugging something that ran at 3am is harder than debugging a click
- Rate limits, expiring tokens, and other people's APIs changing under you
Technologies typically used
A scheduled function or cron job on a small host, plus the APIs it talks to
Web application with a database
Accounts, saved data, many people sharing one source of truth. The workhorse.
Examples
What it is
A real application with a server and a database behind it. People sign in, create and change things, and everyone sees the same state. The server decides what each visitor is allowed to see and do.
Good for
- Anything with users, records, and permissions
- Data with relationships — customers have orders, orders have items
- Workflows where state moves through stages
Trade-offs
- A genuine step up in complexity, and the first with real running costs
- Now you own uptime, backups, migrations, and security
- Data outlives code — a schema mistake haunts you for years
- Deleting is no longer casual; someone's records are in there
Technologies typically used
A web framework, a hosted Postgres database, and an auth provider
API or backend service
No interface at all — it exists so other programs can ask it questions.
Examples
What it is
A service that speaks over the network to other software rather than to a person. Requests come in, answers go out. Its users are a mobile app, a partner's system, or another part of your own product.
Good for
- Backing a mobile app and a web app with one set of rules
- Letting partners or customers integrate with you
- Isolating something expensive or sensitive behind a clean boundary
Trade-offs
- Once someone else depends on it, you cannot freely change it
- Versioning, documentation, and deprecation become your job
- Failures are invisible until a caller complains
Technologies typically used
A small web framework, a database, tokens for authentication, and generated docs
Data pipeline and dashboard
Pull numbers from everywhere, put them in one place, draw the picture.
Examples
What it is
Something that regularly collects data from other systems, cleans and stores it in a shape suited to questions rather than transactions, and renders charts and tables on top.
Good for
- Metrics that live in four tools and need to be seen together
- Recurring reports someone currently assembles by hand
- Making a trend visible enough that people act on it
Trade-offs
- Most of the work is cleaning data, not drawing charts — expect that ratio
- Numbers that disagree with the source system destroy trust instantly
- Dashboards get built, admired for a week, then never opened again
Technologies typically used
Scheduled extract jobs, a database or warehouse, and a charting library
AI-powered application
A model does part of the work — reading, writing, classifying, deciding.
Examples
What it is
An application that calls a language model as part of its actual work: summarising documents, extracting structure from messy text, answering questions over your own material, drafting, tagging, routing.
Good for
- Turning messy human text into structured data
- Questions over a body of documents you own
- Drafting, summarising, and triage where a human still reviews
Trade-offs
- The same input can give different output — nothing is exactly reproducible
- Every request costs money, so usage and bill grow together
- It will be confidently wrong, and testing it needs a whole new approach
- Latency is seconds, not milliseconds, and shapes the whole interface
Technologies typically used
An app calling a model API, often with a vector store for your own documents
Conversational and text-based app
The interface is a chat window, an SMS thread, or an email inbox.
Examples
What it is
Software people use by sending messages to it — a Slack bot, a texting number, a WhatsApp thread, an email address that does something with what you send it. Your code receives a message and replies.
Good for
- Anything used briefly and often, or briefly and rarely
- Audiences who will not install or log into anything
- Survey, check-in, and notify-and-respond loops
Trade-offs
- Almost no layout — everything is words, one message at a time
- Conversation state is fiddly; people reply out of order and days later
- Per-message costs and, for SMS, real registration paperwork
- Platform rules change and can cut off your channel
Technologies typically used
A messaging or SMS provider's webhook into a small server, sometimes with a model behind it
Browser extension
Your software, running inside someone else's website.
Examples
What it is
Code the browser injects into pages you visit — adding a button, hiding clutter, extracting information, blocking things, or reshaping a site that will not change for you.
Good for
- Personal annoyances with a site you use every day
- Pulling data out of a page that has no API or export
- Focus, blocking, and other change-my-own-behaviour tools
Trade-offs
- The host site can change its markup and break you overnight
- Store review is slow and occasionally arbitrary
- Extensions can see a lot, so users are rightly suspicious of permissions
- Chrome, Firefox, and Safari all differ enough to hurt
Technologies typically used
An extension manifest, some JavaScript, and one browser's store listing
Game
A loop, some state, and art. The fun is the spec, and the spec is the hard part.
Examples
What it is
Software whose purpose is the experience of playing it. A loop runs many times a second: read input, advance the world, draw the frame. Small games — puzzles, word games, turn-based things — can be genuinely small.
Good for
- Daily puzzles and word games, which spread by being shared
- Learning state, animation, and input handling by feeling them
- Anything whose value is that people enjoy it
Trade-offs
- Art and sound become the bottleneck faster than code does
- Fun cannot be specified up front — it is found by playtesting
- Balancing and level design are their own long jobs
- Multiplayer multiplies the difficulty rather than adding to it
Technologies typically used
A browser canvas or a small game engine, deployed as static files
Installable web app (PWA)
A website that gets a home-screen icon and keeps working without signal.
Examples
What it is
A web app with a little extra wiring — a manifest and a service worker — so a phone will install it to the home screen, launch it without browser chrome, and keep it usable when the network drops.
Good for
- Turning an existing web app into something phone-shaped
- Internal and small-audience tools that must not wait on store review
- Shipping updates the moment they are ready
Trade-offs
- Limited access to device features compared to a native app
- No app store presence, so no store discovery
- Support and behaviour differ between iOS and Android
- Caching bugs are uniquely confusing — people get stale versions
Technologies typically used
An existing web app plus a manifest, a service worker, and offline-aware storage
Mobile application
In a pocket, with a camera, GPS, and notifications — and an app store in the way.
Examples
What it is
An app installed from the App Store or Play Store, written once with a cross-platform toolkit or twice natively. It can use the phone's sensors and send notifications, and it goes through review before anyone can have it.
Good for
- Anything that needs GPS, camera, or motion in the field
- Habits — daily use that benefits from an icon and a nudge
- Experiences that must feel fast and native
Trade-offs
- Store review, signing, certificates, and annual fees
- Updates ship on the store's schedule, and old versions live forever
- Devices, screen sizes, and OS versions to test across
- Two platforms means roughly double, even with a cross-platform toolkit
Technologies typically used
A cross-platform mobile framework, an API service behind it, and push notifications
Desktop application
Installed on a computer, with real access to files, ports, and the machine itself.
Examples
What it is
Software people download and install on macOS, Windows, or Linux. It can read and write files anywhere the user allows, run in the background, sit in the menu bar, and work with no network at all.
Good for
- Working over large numbers of local files
- Tools that must run offline and keep everything local
- Always-present utilities in the menu bar or system tray
Trade-offs
- Distribution is genuinely hard — signing, notarising, installers
- You must build an update mechanism, or users stay on version 1 forever
- Three operating systems, three sets of conventions and bugs
- Unsigned apps trigger scary warnings that stop most people cold
Technologies typically used
A desktop shell around web technologies, or a native toolkit, plus an update service
App that talks to hardware
Software for devices you did not build — lights, sensors, printers, wearables.
What it is
An application whose job is to control or listen to physical things that already exist: smart bulbs and plugs, Bluetooth sensors, a label printer, a heart-rate strap, a car's diagnostics port.
Good for
- Home automation beyond what the vendor apps allow
- Logging real-world measurements over long periods
- Making devices from different brands cooperate
Trade-offs
- You are at the mercy of each vendor's API, or lack of one
- Cloud-dependent devices break when the vendor's service does
- Bluetooth and local networking are fiddly in ways web work never is
- Testing needs the actual device in the actual room
Technologies typically used
A home automation hub or a small server on a Raspberry Pi, plus each device's protocol
Application that moves money
The moment real money is involved, correctness stops being a preference.
What it is
A web application that charges people — one-off payments, subscriptions, or payouts to sellers — with the state of every account, invoice, refund, and failed charge tracked correctly over time.
Good for
- Subscriptions, one-off sales, and paid memberships
- Marketplaces that take a cut and pay sellers out
- Anything where the ledger has to survive an argument
Trade-offs
- Edge cases everywhere — failed cards, refunds, disputes, proration, tax
- Webhooks arrive twice, out of order, or late, and you must cope
- Sales tax and VAT are a real, jurisdictional problem
- Support becomes part of the product the day you take money
Technologies typically used
A payment provider's hosted checkout, its webhooks, and your own subscription records
Multi-tenant product
Many separate organisations in one application, each certain the others cannot see them.
What it is
One deployed application serving many customer organisations, each with its own users, roles, settings, and strictly separated data. Everyone runs the same code against the same database, partitioned by who they belong to.
Good for
- Selling a tool to businesses rather than to individuals
- Anything needing roles — owner, admin, member, read-only
- Products where each customer wants their own settings and branding
Trade-offs
- One missing tenant check leaks one customer's data to another
- Every query, export, and search must be tenant-aware, forever
- Per-customer configuration multiplies the states you must test
- Onboarding, invitations, and billing become products of their own
Technologies typically used
A web framework with tenancy enforced at the data layer, plus roles and subscription billing
Real-time collaborative app
Several people in the same document at the same time, seeing each other move.
Examples
What it is
An application where changes appear on everyone's screen immediately: shared documents and boards, live dashboards, chat, multiplayer anything. Instead of asking the server for updates, clients hold an open connection and are pushed to.
Good for
- Documents, boards, and canvases used by teams at once
- Live operational views where staleness is dangerous
- Anything where waiting for a refresh breaks the experience
Trade-offs
- Two simultaneous edits to the same thing is a genuinely hard problem
- Reconnection, missed messages, and stale clients need real handling
- Costs scale with connected users, not with page views
- Testing needs several simulated clients, which is its own machinery
Technologies typically used
A web app plus a websocket layer or a hosted realtime service, with a sync library for documents
Mobile app that syncs with a web app
The same data on a phone with no signal and a laptop in an office. The hardest common thing.
Examples
What it is
A mobile app that works fully offline against a local copy of the data, and a web application over the same data, with changes flowing both ways whenever a connection appears — including changes made to the same record in both places.
Good for
- Field staff capturing data away from coverage
- Anything used in the wild and reviewed at a desk
- Apps that must never lose an entry because a signal dropped
Trade-offs
- Conflicts are inevitable and there is no universally correct resolution
- Two schemas to migrate — the server's and every phone's local copy
- Bugs appear only in sequences that are miserable to reproduce
- Old app versions in the field keep syncing against your new server
Technologies typically used
A mobile app over a local database, a sync engine, and an API service with conflict rules
Firmware and embedded software
Code on a chip with no screen, no operating system, and no room for waste.
Examples
What it is
Software running directly on a microcontroller: reading sensors, driving motors and lights, and sometimes reporting over wifi. Memory is measured in kilobytes, there is often no operating system, and the only output may be a blinking LED.
Good for
- Sensing or controlling something physical, cheaply and continuously
- Devices that must run for months on a battery
- Ideas where no off-the-shelf hardware does what you need
Trade-offs
- The feedback loop is slow — flash, watch, unplug, guess, repeat
- Debugging is primitive, and some bugs only appear after days
- Power, heat, radio interference, and physical enclosures all matter
- Updating deployed devices in the field is a project of its own
Technologies typically used
A microcontroller board, its toolchain, and a serial connection for debugging
Nothing matches that. Try fewer words, or clear the filter above.