Start by writing one sentence that says what the app does for one specific person, then build the smallest web version of that sentence and put it on a real URL within a fortnight. Not a mobile app, not a business plan, not a logo. A web app, because it needs no app store review, runs on every device, and can be shipped from a laptop to a live address in an afternoon. Choose a boring stack you can find answers for, keep the first version to one screen and one database table, and let the second version be decided by what the first one taught you. Everything else in the standard twelve-step guides is either premature or a consequence of doing this first.
Most guides on this question are written for someone commissioning an app from an agency, so they lead with market research and wireframes. This one is for the person who intends to build it, or at least to understand what they are paying for, and it treats the app as a thing that has to run somewhere from day one.
Table of contents
- Step one: the sentence, and why it is not a business plan
- Step two: web first, and the honest reasons
- Step three: a boring stack you can search for
- Step four: one screen, one table, one deploy
- What it costs to run, in real numbers
- What comes after the first three users
- How this fits the rest of the stack
- FAQ
Step one: the sentence, and why it is not a business plan
Before any tool, write: this app lets a specific kind of person do one specific thing. A dog walker log walks and send the owner a photo. A landlord track which tenants have paid this month. A running club publish the week’s routes. If the sentence needs the word and, it is two apps, and the second one waits.
The sentence is not a business plan and it does not need validation from a survey. Its job is to decide what the first screen shows and what the first database table stores, and to stop feature creep before the first line of code. Every good app you use started as a version of this that did one thing acceptably, and every abandoned app on your phone started as a plan to do six.
Step two: web first, and the honest reasons
The word app pulls people towards the app stores, and for a first version that is the expensive door. A native mobile app needs two codebases or a cross-platform framework, a developer account, a review process, and an update cycle measured in days. A web app needs a URL.
- It runs on every phone, tablet and laptop with a browser, today.
- You can change it and the change is live in a minute, without a review queue.
- It can be added to a home screen and behave like an installed app for most purposes.
- Payments, logins and notifications all work on the web without a store taking a cut.
- When you do need a store presence, the web app is the backend the native app will talk to, so nothing is wasted.
The exceptions are real but narrow: apps that need the camera or sensors continuously, that must work offline for hours, or whose users will only find them in a store. If your sentence is one of those, build the web backend first anyway, because the native client will need it.
Step three: a boring stack you can search for
The stack is the set of languages and tools, and the right one is the one with the most answers on the internet for the errors you will hit. Novelty is a cost. A dependable default for a first web app:
- Frontend: a framework with a large community. React through Next.js is the most-searched option; Vue through Nuxt and Svelte through SvelteKit are also fine. Pick one and do not revisit the choice.
- Backend: the same framework’s server side, or a small Node, Python or Go service if the app needs a separate API. For a first version, the framework’s built-in server routes are enough.
- Database: Postgres. One table to begin with. Not a spreadsheet, not a file, because the moment two users exist you need concurrent writes and the moment you need a report you need a query.
- Auth: whatever the framework’s ecosystem recommends, with email sign-in only. Social logins are a later feature.
- Hosting: a platform that deploys from a Git repository and gives you a URL, environment variables and logs. Not a server you administer.
If you are not going to write the code yourself, the same list is what you hand to the person who will, and it is what stops them proposing an architecture that needs a team to run.
Step four: one screen, one table, one deploy
The first version is the sentence, implemented. For the dog walker, that is a form that records a walk with a photo, a list of past walks, and a link the owner can open. That is one table, one upload, and two pages. It is not user roles, not billing, not a dashboard with charts.
The sequence that gets there in a fortnight, part time:
- Create the project with the framework’s starter command and put it in a Git repository on day one.
- Deploy the empty project to a live URL on day one as well, so deployment is never a scary final step. From then on, every push updates the site.
- Add the database and the one table. Write the form that inserts a row and the page that lists the rows.
- Add sign-in, so that rows belong to a user.
- Add the one integration the sentence needs: the photo upload, the payment, the email. One.
- Give the URL to three real people who match the sentence and watch them use it without helping.
Deploying on day one is the step people skip and the one that matters most. An app that exists only on a laptop is a project; an app at a URL is a product with a feedback loop, even at version zero.
What it costs to run, in real numbers
The hosting bill for a first version is small and it is worth knowing the shape, because the shape is what changes as the app grows. A web service on a modest plan, a managed Postgres instance on a similar plan, and some storage for uploads. On RunxBuild that is a Dev plan at $4 a month for the service and the same again for the database, with a Free tier that covers the first fifteen days of each month if you want to test before paying anything. Bandwidth for a small app sits inside the included allowance.
The number matters less than the fact that it is a number. An app on a laptop costs nothing and is worth nothing. An app on an eight-dollar-a-month stack with a real URL, a real database with backups, and logs you can read when something breaks is the cheapest experiment you will ever run, and it scales by moving to a larger plan rather than by rebuilding.
What comes after the first three users
The three people will tell you the sentence was slightly wrong, and that is the point. Version two is the correction. It is usually smaller than you expect: a field they needed, a step they did not, a page that should have been the home page. Ship it the same week.
The things that were deliberately left out come back in order of evidence: billing when someone asks to pay, a native app when the web version has users who want it on the store, roles when a second kind of person appears. Each of those is a real project and each is much easier with a working product, a database of real data, and a deployment path that has already run fifty times.
How this fits the rest of the stack
Knowing what the first version costs to run is part of knowing where to start, because it tells you the experiment is affordable. The RunxBuild hosting calculator puts a web service, a managed Postgres database and storage for uploads on one screen with the plan prices, so the total for a one-screen, one-table app is visible before the first line of code. When the project is ready, deploying from the GitHub repository is the day-one step that turns it from a folder into a URL.
Useful related references:
- How to Check Your IP Address in Ubuntu (And Which One You Actually Want)
- Git Pull All Branches: Why the Command You Want Does Not Exist
- Home Assistant Dockerfile: Why You Probably Want Compose Instead
- Services on RunxBuild
FAQ
I want to create an app but I cannot code. Where do I start?
Write the one-sentence description first, then decide whether to learn enough to build a web version with a mainstream framework, use a no-code builder for the prototype, or hire a developer. In every case the sentence, the web-first decision and a boring stack are what you hand over, and they keep the scope and the cost under control.
Should my first app be a mobile app or a web app?
A web app, unless it depends on continuous camera or sensor access, long offline use, or store discovery. A web app runs on every device, deploys in minutes without review, and becomes the backend for a native client later, so nothing is wasted.
What stack should a beginner use to build an app?
A mainstream frontend framework with a server side (Next.js, Nuxt or SvelteKit), Postgres as the database, the ecosystem’s recommended auth library with email sign-in, and a hosting platform that deploys from Git. The best stack is the one with the most search results for the errors you will hit.
How much does it cost to run a first app?
A small web service and a managed Postgres database each on a $4 Dev plan, plus a little storage, comes to well under $10 a month on RunxBuild, with a Free tier covering the first fifteen days of each month. Costs grow by moving to larger plans, not by rebuilding.
How long should the first version take?
A fortnight of part-time work for one screen and one table, if you deploy on day one and keep the scope to the sentence. Most of the time is spent on the one integration the app needs, such as uploads or payments, which is why there should be only one.