People still treat “no money” like a wall. In 2026 it is mostly an excuse. You can build a product on open source software, a small VPS, an AI API when you need one, and cheap object storage. You do not need a seed round to put a price on a page.
Pieter Levels put the stack in one line in July 2026: free open source software, a VPS, an AI API, and R2 or S3. That is the shopping list. The hard part is not buying those pieces. The hard part is a real offer and the first people who pay.
Indiecity is for one person or a team under twenty. You are not competing with funded roadmaps. The real gap is no price, no ask, and no buyer. This guide is how you start when the bank account is thin and the stack still has to ship.
What “no money” actually means
It does not mean every bill is zero forever. It means you refuse burn that does not buy a customer. No office. No agency. No five paid tools for jobs a free library or a weekend script can do. A small monthly server and metered API usage are normal. Pretending infrastructure is free at any scale is how people get surprised invoices.
It also means you do not wait for capital to learn. Levels’s bootstrap list from February 2026 is the order: pick a problem you feel, ship something ugly, charge from day one, use boring tech, host on a cheap VPS, do support yourself. Keep burn near zero so you never need permission to continue.
Funding is optional. A payment from a stranger is not. If you cannot take money, you do not have a SaaS yet. You have a project.
The only stack you need
Levels’s July list is short on purpose. Complexity is a business for other people. Your job is a product someone will pay for.
- Open source software you can run and change without a monthly seat tax
- One VPS (or a tiny set of them) that serves the app and the database
- An AI API only for the steps that need a model
- R2 or S3 for uploads, exports, and static files
- A way to take payment the same day someone says yes
That is enough for a first version. You can swap brands later. A prettier diagram will not fix nobody paid.
Write the offer before you rent the server
A free stack does not save a fuzzy product. Fill this sentence first: “I charge [price] so [who] can get [outcome] without [pain].” If those blanks are empty, the VPS will host nothing useful. Validate the idea before you treat code as the work. Talk about their last mess, not your feature list. Then ask ten people to pay.
Prefer a problem you already pay time or money to fix. Prefer a buyer you can name without a CRM. Prefer an outcome you can deliver this week even if part of it is manual. Software can catch up. An empty inbox does not care about your deploy.
Build with tools that do not bill you for existing
In 2026, AI will write a lot of the boring code. That is fine. Tereza Tizkova wrote that you can vibecode your own tool instead of renting someone else’s. Use that speed. Do not use it to rebuild a suite nobody asked for.
Pick languages and databases you can debug at 1 a.m. alone. Levels keeps pointing at boring stacks for a reason: frameworks and cloud products sell you complexity. DHH’s note on merchants of complexity is the same fight from another angle. If a tool needs a specialist team you do not have, it is the wrong tool for week one.
No-code is allowed if it gets a paid outcome faster. Code vs no-code is a speed choice, not a moral rule. The rule is the same: charge for the outcome, not for the stack argument.
Host on a VPS, not a fantasy cloud
A first SaaS is a website, a database, and some background jobs. That fits on one small virtual server. Levels’s rule is host on a cheap VPS, not a hyperscaler maze, when you do not need clusters for early traffic. Hetzner, DigitalOcean, and peers all sell that shape. Pick one region, one box, backups you actually restore once, and a domain pointed at it.
You will spend more time on SSH keys and deploys than on a multi-region plan. That is the point. Time on the product and on buyers beats time on a bill you cannot read. When the box is too small, upgrade the box. Do not redesign the company.
Pay for AI only where the product needs it
An AI API bills by the call. Use it for the feature the customer pays for: generate the draft, classify the ticket, rewrite the email. Do not wire a model into every button because demos look smart. Cap spend. Log usage. Prefer the cheapest model that still does the job.
If the whole product is “wrap a model and charge,” price above your token cost with room for support and bad months. If the model is a helper inside a workflow people already pay for, keep the helper thin until paid usage proves which calls matter.
Put files on R2 or S3
User uploads, exports, and images do not need to live forever on the VPS disk. Object storage is the boring place for them. Cloudflare R2’s free tier includes a monthly storage allowance and free egress on their terms. S3 is the older default. Levels names both for a reason: you need a bucket, not a media platform.
Start on the free tier. Set lifecycle rules so junk does not pile up. Keep secrets out of public buckets. When a customer pays for heavy storage, the bill is a feature cost, not a surprise.
Charge early. Free is not a strategy.
Levels’s third rule is charge money from day one. Free users teach you about free users. Paying users teach you what is broken in the path that matters.
Put a price on the page. Take the card the same day with a link, checkout, or invoice. A waitlist is for when you cannot deliver. If you can deliver by hand, charge for the hand. Graham’s line still works in 2026: you go get users. You do not wait for the feed to notice a launch. If you already shipped and nobody paid, write people before you rebuild.
You can't wait for users to come to you. You have to go out and get them.
That essay is from 2013. Shipping got cheaper. Inboxes got noisier. The manual work did not go away.
Customers cost attention, not a media budget
Levels said in June 2026 that everyone can build apps with AI, and almost nobody has an audience, ad cash, or a free path to attention. A few days later he wrote about indie meetups full of AI factories with no money and no traffic. The stack was never the hard part.
So you do not buy ads on day one. You write thirty names. You send ten human notes. You sit in the forum or Slack where the buyer already vents. You ask for the money on a short call. The first ten paying customers without ads is the playbook. A thin server does not change it.
Hey [name]. You mentioned [pain in their words]. I built a thin tool that does [outcome] for [who]. It is [price]. I can start you this week (even if part of it is still manual). Want 15 minutes, or should I leave you alone?
Honest beats polished. People will pay for a result on an ugly page. They will not pay for a perfect stack with no ask.
A two-week plan with almost no burn
- Day 1. Write the offer sentence with a price. List 30 names. Open a payment path.
- Day 2. Rent the smallest VPS you can operate. Deploy a thin version or a manual intake form.
- Day 2. Create the R2 or S3 bucket if you take files. Wire the AI API only if the paid outcome needs it.
- Days 3 to 7. Send two personal messages a day. Book short calls. Charge on the call when the outcome is clear.
- Day 7. Fix only what blocked payment or delivery. Do not add a dashboard for fun.
- Days 8 to 14. Send the next ten names. Ask every paid customer for one intro. Keep a cap on API spend.
- Day 14. Count paying customers and real costs. If revenue covers the server and the API, keep going. If nobody paid after real asks, change the offer or the buyer, not the cloud vendor.
Track four columns: sent, replied, booked, paid. Add a fifth for the words they used for the pain. Those words replace your homepage headline.
What to stop spending on
- Paid SaaS for jobs a free tool or a script can do this month
- Ads before you can say who pays and which sentence worked
- Agencies, freelancers, and “launch packages” when you have not asked ten people yourself
- Enterprise cloud features you cannot name a customer for
- A free plan that fills the inbox with people who will never pay
- A redesign of the stack after every Twitter thread
How you know it is working
Someone pays. The VPS stays up. People write in when something breaks. That is useful. API spend stays under what that customer paid. Those signals beat vanity metrics. Stars on a repo, waitlist size, and “cool stack” comments do not pay the server.
If twenty named people will not take a short call, the offer or the buyer is wrong. A cheaper host will not fix that. Go back to the sentence with the price and the pain.
Then you have a business, not a funded story
Starting a SaaS with no money in 2026 is not a stunt. It is open source, a small server, metered AI when you need it, object storage, and a price you say out loud. Levels’s list removes the excuse that you need a raise. Getting paid removes the fantasy that the stack is the business.
When the first people pay and the name is yours, write the story. When the product is real, put it on the map. You can join Indiecity while you ship. Community helps you stay honest. It does not replace the invoice.
Rent the small box. Ship the thin thing. Charge this week.
FAQ
Questions people get stuck on
Can I really start a SaaS with no money in 2026?
You can start without funding, an office, or a paid stack of SaaS tools. You still need a card for a small VPS and for API usage if your product calls a model. [Pieter Levels wrote in July 2026](https://levels.io/build-business-free-open-source-vps-ai-r2-s3) that the pieces are free open source software, a VPS, an AI API, and R2 or S3. That is a thin bill, not a raise.
What stack do I need on day one?
Boring software you can run yourself, a cheap virtual server, object storage for files, and an AI API only if the product needs one. Skip multi-cloud setups, managed everything, and paid tools you can replace with a script. The product is the outcome someone pays for, not the architecture diagram.
Do I need AWS or a big cloud account?
No. [Levels’s bootstrap list](https://levels.io/how-to-build-bootstrapped-startup-without-funding) is blunt: host on a cheap VPS, not AWS, when you do not need Kubernetes for a thousand users. A single small server runs most first SaaS products. Move when load or compliance forces you, not when a tutorial does.
When should I charge if I have almost no product?
As soon as you can deliver the outcome, even by hand. Levels’s rule is charge from day one. Free users give you support tickets. [Paul Graham’s “do things that don’t scale”](https://www.paulgraham.com/ds.html) still holds: recruit buyers one by one and do the work manually until you know what to automate.
What if I cannot pay for a VPS this month?
Deliver manually first. A form, a sheet, email, and a payment link can be the product while you save for the server. Do not wait for a perfect host to ask someone to pay. The server is infrastructure. The offer is the business.
How do I get customers with no ad budget?
Write to people you can name. Sit in the rooms where buyers already complain. [Getting your first 10 paying customers without ads](/stories/first-10-paying-customers-without-ads) is the same job whether the stack cost little or a lot. Ads wait until you know which sentence makes a stranger pay.
Is free hosting and free AI enough forever?
No. Free tiers for object storage and AI credits help you start. Usage grows with real customers. That is fine: revenue should arrive before the bill hurts. Cap API spend, watch storage, and raise price or automate when the same step costs you more than it earns.
Should I raise money so I can build faster?
Only if you want investors, dilution, and a different company shape. [Levels’s February 2026 list](https://levels.io/how-to-build-bootstrapped-startup-without-funding) keeps burn near zero so you never need a raise. For one person or a small team, ramen profitable with a paid offer beats a deck with no revenue. [Bootstrap vs raising](/stories/bootstrap-vs-raising-under-20) is that choice in full.
What should I not buy while cash is tight?
Agency builds, brand packages, unused SaaS seats, ads before a tested pitch, and cloud complexity you cannot operate alone. Buy the VPS, the domain if you need one, and the API calls the product requires. Everything else waits until someone pays.
