To develop a cloud application is to ship software that runs on rented infrastructure instead of a machine in your closet. The interesting part is not the term — almost every modern app is “cloud” something. The interesting part is the part nobody warns you about: the moment the word “cloud” stops meaning “anywhere” and starts meaning “five separate services with five separate bills, a region selector, an IAM role, a load balancer, and a Friday-night invoice spike.”
This guide is for the founder, indie hacker, agency lead, or junior platform engineer who is about to develop a cloud application for the first or the fifth time and wants the version of the path that doesn’t turn into a second job. It is opinionated. It is not a “what is cloud” explainer, because the Cloud Native Computing Foundation has already done that with very pretty diagrams.
I have shipped cloud applications in three different decades of “modern best practice.” I have also been the person who got paged at 11pm because the staging environment pointed at a production database and somebody clicked the wrong dropdown. The advice below is the distillation of what actually worked, not what looked clean on a whiteboard.
Table of contents
- The question that decides the entire project
- The mental model that keeps the bill honest
- The minimal stack that survives contact with users
- The five-decision build, in order
- What to skip on day one
- The day you outgrow this advice
- A worked example, end to end
- A quick mental checklist before you ship
- FAQ
The question that decides the entire project
Before you pick a region, a runtime, a managed database, a CI tool, a secret manager, a queue, a cache, a CDN, an object store, a log aggregator, an APM, a status page, and a feature flag service — answer one question, out loud, to a person you trust:
Who is going to operate this thing at 2am when it is down?
Not “who can be paged.” Who is going to actually look at the screen, understand what they are looking at, and act on it without making it worse. If the honest answer is “nobody — I am a solo founder and the dog is asleep,” then your cloud architecture is not the same problem as the AWS Solutions Architect exam. Most of what is sold to you as “best practice for the cloud” exists to handle workloads that someone is paid to babysit 24/7. Most of what you need is something that works when you push to it and lets you sleep.
This one question collapses the entire menu of decisions. Serverless functions instead of long-running containers, because nothing is “down at 2am” if the platform runs the runtime for you. Managed databases with automatic backups, because the alternative is a cron job you forgot about. A deployment platform that gives you logs, env vars, and a domain without requiring you to learn three new YAML dialects.
The right answer for “who is going to operate this at 2am” is: the cloud platform, mostly.
The mental model that keeps the bill honest
Every cloud app is, underneath the dashboards, four things:
- A place where code runs.
- A place where data lives.
- A place where users come in.
- A way to get logs when something breaks.
The order matters, and so does the ratio. Most cloud app tutorials start with #3 (the URL, the domain, the CDN, the load balancer) and pretend the first two are details. They are not details. They are the entire bill. If you start with the wrong shape in #1 or #2, the cleverest CDN in the world will not save you.
Here is the rule I use, and the rule I have watched several well-funded teams learn the hard way: if you cannot explain the monthly cost of your cloud app in a one-sentence formula involving CPU hours, gigabytes, and requests, you do not yet understand your architecture well enough to add anything to it. The phrase “managed database” is not a substitute for knowing how many rows, how many indexes, and how often you query them. “Serverless” is not a substitute for knowing how many cold starts you can afford and what the function memory size actually is.
If you cannot fit your cost on a sticky note, the cost will fit itself onto a Stripe charge that surprises you.
The minimal stack that survives contact with users
I will give you the stack I would use if you walked up to me and said “I need to develop a cloud application, I have three days, and I want it to be the last stack I migrate off of.” It is not the only stack that works. It is the one with the fewest moving parts and the most room to grow without re-platforming.
The runtime tier. A managed platform that runs your code in containers or serverless functions and handles the rest. RunxBuild is the obvious fit for this guide because it gives you a single deploy command for a static site, an API, a database, a background worker, and an agent runtime, all on the same dashboard. The point is not the brand — the point is that you want one pane of glass for “where the code runs,” not seven.
The data tier. A managed Postgres. Not because Postgres is fashionable. Because it is the database that is most likely to be available, most likely to be understood by the next person you hire, and most likely to keep working when you grow from one region to two. The managed part matters: it means backups, point-in-time recovery, and connection pooling happen without you writing a cron job.
The static asset tier. A content delivery network, which most managed platforms include for free. This is where the marketing site, the docs site, and the front-end bundle live. Keep it separate from your API, even if the URL is the same.
The observability tier. Logs and request logs, which most platforms give you. You do not need Datadog on day one. You need to be able to grep a request and see what went wrong.
The secret-management tier. A single environment variable UI on the platform. Do not stand up HashiCorp Vault for a five-person team. Do not commit .env to git. The variable UI is enough.
That is the entire stack. If someone is trying to sell you nine things on top of that for your first cloud app, the nine things are real but they are not for you yet.
The five-decision build, in order
If you have answered the 2am question and you have a sticky-note budget, the build itself fits into five decisions, and the order is the order.
Decision 1: Pick the runtime shape
Two viable shapes, and they map to how much time you have and how much you want to learn.
Serverless functions. FastAPI, Express, Hono, or any small framework wrapped in a function. Cold starts, function memory limits, per-invocation billing. Great for low-traffic APIs, agent runtimes, and event-driven work. Bad for long-running connections (WebSockets, large file uploads, anything that needs to hold a connection for minutes).
Containers. A Dockerfile plus a managed container platform. A bit more work to set up. A lot more flexibility: any language, any framework, any port, any process. The right default once you have traffic and you know what your app actually does.
For a first cloud app, start with serverless. Move to containers the day serverless stops fitting — usually because you need a long-running process, a custom port, or a runtime the platform doesn’t have a serverless tier for. The migration is “add a Dockerfile” in almost every modern platform. It is not a rewrite.
Decision 2: Pick the database — and commit to it
Pick Postgres. Not MySQL. Not MongoDB. Not “we’ll start with SQLite and migrate later.” Postgres.
Postgres wins for a few boring reasons that matter at 2am: it is the database your future engineer has used before, it has the best tooling for migrations (drizzle, prisma, sqlalchemy, kysely, sqlx), it is the default for every managed platform including RunxBuild, and it has row-level features (RLS, partial indexes, generated columns) that you will want around month three. SQLite is fine for prototypes that are honestly prototypes and not pretending to be a product.
Run the database as a managed service. You should not be SSHing into a Postgres box to recover a WAL archive. You should be clicking a button in a dashboard to restore from yesterday’s snapshot.
Decision 3: Wire the environment
The single biggest source of “works on my machine” bugs in cloud apps is environment variables. Build a single config object on application boot that reads from process.env, fails loudly when a required variable is missing, and never lets a secret land in a log line.
If you want one piece of advice that will save you a week: do not have a .env.example that lies. Whatever you put in it has to be every variable the app needs to start. If you have an env var that the app reads at runtime but is not in the example file, the example file is wrong. Update it. The cost of updating .env.example is two minutes. The cost of discovering a missing env var at 2am because a junior dev cloned your repo is an hour.
Decision 4: Build the deploy loop
The deploy loop is the thing that takes code on your laptop and puts it on a URL. It has three parts: build, push, deploy. Each of those should be a single command.
The right loop for a one-person team:
git pushto your main branch.- The platform pulls the repo, builds the image or bundles the functions, runs your migrations, and swaps the live traffic over.
- You check the deploy logs in the dashboard, and if something looks off, you click a button to roll back to the previous deploy.
That is the whole loop. Anything that requires you to ssh into a box to restart a service is too much loop. Anything that requires you to remember which environment you’re in is too much loop. Anything that takes more than five minutes from git push to live URL is too much loop for the team you actually have.
Decision 5: Set the budget alert before you need it
The last decision is the one nobody makes and everybody regrets. Pick a monthly dollar number, set a billing alert at 50% of it, and put the alert in a channel you actually read. Email is fine. Slack is better. SMS is best. The point is: when the bill hits $150 on a $300 budget, you find out from the system, not from a panic on day 31.
This is the only cloud-app advice that comes from personal experience rather than the docs. Every founder I have watched get surprised by a bill had this one thing in common: no alert, no number in their head, no idea what the bill was supposed to be.
What to skip on day one
There is a long list of things the cloud wants to sell you. Most of them are not wrong; they are just not for you yet.
Skip Kubernetes. It is a real answer for a real team. It is not the answer for a team that does not have a dedicated platform engineer. Managed containers, serverless functions, and PaaS runtimes give you 90% of the benefit with 5% of the operational cost. If you have a platform engineer, ignore this section. If you don’t, hear me: there is no faster way to become a Kubernetes admin against your will than to develop a cloud application with Kubernetes on day one.
Skip a separate observability stack on day one. Use the logs your platform gives you. They are not as pretty as Datadog. They are also not a separate bill. Move to a real observability stack when you can name three specific questions your current logs cannot answer.
Skip multi-region on day one. One region. Pick the one closest to your users. Most managed platforms replicate your data within the region automatically. Multi-region is for the day your users complain about latency in a geography your single region can’t reach — which for most apps is never.
Skip microservices. One service. If you find yourself writing two services, write them in the same repo and use routing inside the same process until you can’t. The complexity of a microservice is not the technology; it is the operational cost of having two deploy pipelines, two sets of logs, two things to monitor at 2am.
Skip the feature flag service. Most apps don’t need it on day one. A simple environment variable with a feature flag, deployed through your normal pipeline, does the same job for a fraction of the complexity.
The day you outgrow this advice
You will. Every piece of advice here has a shelf life. The day you outgrow it will look like one of these:
- You have a single API that takes more than 30 seconds to respond. Move long-running work to a background worker.
- You have a single database that takes more than 10 seconds to back up. Move to a read replica, or a more sophisticated backup strategy.
- You have a single deploy that breaks something 5% of the time. Add a staging environment.
- You have a single team that wants to deploy independently. Split the service.
- You have a single user who wants lower latency in a different country. Add a second region.
Each of those is a real problem that exists at a specific scale, and the answer to each is the next thing in the menu — not the previous thing plus another nine items. The trap most teams fall into is adopting the next-stage answer before they have the next-stage problem.
A worked example, end to end
Here is what “develop a cloud application” looks like if you follow this advice, in the time it takes to make coffee.
A FastAPI app, three endpoints (/, /health, /items), talking to a Postgres database, deployed on RunxBuild.
.
├── app/
│ ├── main.py
│ └── db.py
├── pyproject.toml
├── requirements.txt
└── README.mdapp/main.py — three lines of code I actually wrote and shipped, in slightly more polished form:
from fastapi import FastAPI
from app.db import get_connection
app = FastAPI()
@app.get("/")
def read_root():
return {"status": "ok"}
@app.get("/health")
def health():
with get_connection() as conn:
with conn.cursor() as cur:
cur.execute("SELECT 1")
cur.fetchone()
return {"db": "ok"}
@app.get("/items")
def items():
with get_connection() as conn:
with conn.cursor() as cur:
cur.execute("SELECT id, name FROM items")
return cur.fetchall()app/db.py reads DATABASE_URL from the environment and uses psycopg. The URL format is postgresql://user:password@host:5432/dbname — the default port is 5432 if you don’t specify one. The platform injects this variable for you when you attach a managed database to a service. You do not hardcode it. You do not log it.
pyproject.toml is two lines that matter:
[project]
requires-python = ">=3.11"
[tool.runxbuild]
build = "pip install -r requirements.txt"
start = "uvicorn app.main:app --host 0.0.0.0 --port $PORT"That is the whole thing. git push, the platform builds it, the platform runs the migrations because we said so in the deploy config, the platform attaches a managed Postgres from the same dashboard, the platform gives the service a URL. Total time: less than the coffee.
The point is not that this is the best cloud app you can build. The point is that this is the smallest cloud app you can build, and “smallest that works” is the right default.
A quick mental checklist before you ship
Before you push to production, you should be able to answer yes to every one of these:
- Is there a single URL someone can hit to see the app work? (The “hello world” endpoint.)
- Is there a second URL that proves the database is connected? (The
/healthendpoint.) - Are environment variables documented in a single file that matches what the app actually reads?
- Can you redeploy in under five minutes from a fresh
git clone? - Is there a budget alert set at 50% of the monthly dollar number in your head?
- Is there a way to roll back to the previous deploy in one click?
- Is there a way to see the logs of the last failing request, with the request ID, in under thirty seconds?
If any of these is “no,” that is the work for the rest of the week. Not Kubernetes. Not microservices. Not a separate observability stack. The unsexy work that is the difference between a cloud app that runs and a cloud app that runs and you can keep running.
Frequently asked questions
What is the easiest cloud platform to develop a cloud application on for a solo founder?
The honest answer is “whichever one you will not abandon in three months.” For a solo founder with no platform team, the right answer is a managed PaaS that handles the runtime, the database, the deploy, the logs, and the domain in one place. RunxBuild, Vercel, Render, Railway, and Fly.io all fit that description. The differences matter at scale, not at the “build the first version” stage. Pick the one whose docs make sense to you and ship.
How much does it cost to develop and run a cloud application for the first year?
For a side project or a small SaaS, the realistic range is $0 to $50 a month. Most managed platforms have a free tier that covers a personal project, a starter tier around $5 to $15 a month that covers a real product with low traffic, and usage-based pricing above that. The bill that surprises people is almost always the database, the egress, or the AI inference — not the compute. Set a budget alert on day one.
Do I need to learn Docker to develop a cloud application?
You need to be able to read a Dockerfile. You do not need to be able to write one from scratch. Every modern PaaS has a default Dockerfile you can extend, and many of them (including RunxBuild) have build presets that generate one for you. The day Docker becomes a real skill is the day you need a custom runtime, a custom system library, or a non-trivial build step. For a first cloud app, copy the example, change one line, ship.
How is a cloud application different from a web application?
A web application runs on a web server. A cloud application runs on rented infrastructure that is managed by a third party. The user experience is the same. The operational reality is different: in a cloud app, you do not own the server, you do not patch the OS, you do not replace the disk, and you do not design the network. You write the code, push it, and the platform handles the rest. The trade is that you have less control and a smaller mental model, which is the right trade for most teams.
When should I move from a single cloud app to a multi-service architecture?
When you have a service that needs to scale differently from the rest of the app (a long-running worker that needs more memory, a public API that needs to scale with traffic), or when two teams need to deploy independently of each other. The signal is operational, not architectural. If you can describe the scaling or team reason in one sentence, you have the reason. If you can’t, you are over-engineering.
Is a cloud application the same as a SaaS?
No. SaaS is a business model (software as a subscription service). A cloud application is a deployment model. A SaaS runs on cloud infrastructure, but a cloud app can also be a free tool, a personal project, or an internal company tool. People mix these up because most cloud apps in the wild are SaaS products. The deployment model and the business model are independent.
What is the difference between a cloud application and a serverless application?
A serverless application is a cloud application that uses a serverless runtime (functions, edge workers, managed containers with no always-on server). A cloud application can be serverless, or it can use containers, virtual machines, or bare metal. “Serverless” is a deployment shape; “cloud” is the broader category. Most new cloud applications start serverless because it is the cheapest shape to start with and the easiest to grow out of.
How this fits the rest of the stack
Building a cloud application is also a cost exercise — the runtime, the database, the storage, the bandwidth, the build minutes, and the workers each show up as a separate line item, and the team’s mental model for the project cost is the sum of those numbers. The RunxBuild hosting calculator is the right place to model that — pick the service size, the database tier, the storage, the bandwidth, the build frequency, and the worker count, and the calculator shows what the full-stack application costs at the team’s actual usage rather than what the free tier hides.
Useful related references: