Actually Serverless: Three Products on Cloudflare for $0

Every time I tell someone I work on Cloudflare, they look at me like I am saying something impossible. The free tier in 2026 is larger than any first complete idea you can launch — provided you understand the limits before you hit them.

What I actually built

• A PWA: works offline, has audio and images, installs to the home screen — Pages + Service Worker.
• A Telegram bot: registration and data tracking — Worker + KV for state.
• An admin interface: file uploads and data review — the same Worker, extra routes.

All three run on one account, with no server and no invoice. What I paid was learning time.

Pages or Worker? The first decision

• Pages: you have static files — HTML, CSS, images, audio. Upload a folder and get a working URL in seconds.
• Worker: you need code to answer requests, read from a store, or call an external API (like Telegram).
• Both together: Pages with a _worker.js file at the root — assets are served for you, and your code handles specific routes like /api/.

That third option covers most small projects, and I now start there by default.

What actually hurts: size

Not compute. Compute is generous and you will never notice it. What hurts is asset size: the bigger your images and audio get, the more you have to think about storage and caching. Three practical answers:

1. Compress before uploading: a 4 MB image has no reason to be 4 MB. 100 KB is usually plenty.
2. Load in stages: let the interface appear first, then fetch audio and video when the user asks for them.
3. Keep large files out of the code: anything above the limit belongs elsewhere, with your site linking to it.

Three mistakes I actually made

• Uploaded a single file instead of the whole project: a deployment replaces everything, it does not merge. A partial upload breaks the site instead of updating it.
• Forgot the file containing the code: the site stayed up, but the API the bot depended on disappeared — and the symptoms showed up somewhere completely different.
• Used a short link in a button: links that redirect fail inside in-app browsers. Use the final direct URL.

The rule I adopted afterwards: every upload = the whole project, and every button = a direct URL with no redirects.

The thing with a link gets fixed faster

This is the most important lesson and it is not technical. An idea on your laptop stays exactly as it is for months. An idea with a link starts bothering you — people use it wrong, bugs show up, slowness shows up. And that friction is what develops you.

So if you are waiting to "finish it first": ship an incomplete version to a link, then finish. Perfection is not a prerequisite for publishing; it is a consequence of it.