What does zero-cost infrastructure cost you?
Nothing paid sits in the critical path, so the product costs nothing to run. What that takes off your bill, what it forbids, and where a free tier ends.
Nothing paid sits in the critical path, so the product costs nothing to run. The constraint decides the architecture before it decides a bill. Where a free tier stops being free is stated up front, not discovered in production.
What it removes from your side is a monthly invoice for keeping it switched on. What it does not remove is capability.
The rule itself is short. Free-tier infrastructure, work done in the browser wherever the browser can do it, and no paid service in the critical path. Zero-cost infrastructure is the short name for it.
I am Ahsan Mahmood, and every product in the catalogue is built under that rule. It has to run without a paid service in the critical path, without a server that must be kept alive, and without a vendor whose pricing can move under you. That began as a budget decision and became a design one. Every service page states the same constraint beside the work it describes.
One word does the damage here. The rule is about what the product costs me to keep switched on. It says nothing at all about what the product charges the people using it. A paid plan sits on top of free-tier infrastructure without contradicting a line of this post.
What leaves your bill, and what stays on it?
Three things leave. A rented server, a paid service sitting in the middle of a feature, and a vendor whose pricing can move under you while the product sits idle. What stays is what you were always going to pay. Hosting, third-party services and store fees are yours and are paid to those vendors directly.
So the invoices arrive with your name already on them. A domain, a store registration and an API you chose to pay for with your own key in it. There is no line item for keeping the thing switched on. The costs that do stay with you are written down on pricing.
None of that is accidental. The list of what a product may depend on is short. It is settled before the first screen is drawn.
Why does the running cost decide the architecture?
Because a constraint that hard forces one question early: does this feature need a server at all? The answer is no far more often than the industry's defaults suggest. The version that does not need one arrives with predictable running costs and no surprise invoice.
It rules things out, which is the point. A constraint that never costs you anything was not a constraint.
In practice that means work done in the browser wherever the browser can do it. The database is Firebase or Supabase on a free tier, picked because it survives a real launch, with the query budget treated as a real constraint rather than a formality. A server appears only where one is genuinely required. Laravel, or a Cloudflare Worker.
What does the constraint forbid?
An architecture that only works while traffic is small. The free tier is a budget, not an excuse, so a design that falls over in the week the product succeeds is not a saving. It is a bill nobody has told you about yet.
It also forbids a feature that needs a paid API in the middle of it, unless you are paying for that API and know you are. That sentence sits on the about page, among the things I say I will not build.
Concretely: the search cluster sized for a catalogue that does not exist, and the always-on service kept warm for traffic that has not arrived. Both are cheap to draw on a diagram and expensive to keep switched on. Both would land on your bill rather than mine.
Where does a free tier stop being free?
At the quota, usually without warning. A free-tier database meters reads rather than money, so a careless query does not arrive as a bill at the end of the month. It takes the product off the air for everyone using it until the counter resets.
The exam platform went down on a day nobody had changed anything, because a free-tier read quota ran out. Nothing had broken. A screen fetched a whole collection so it could filter it in the browser, which is unremarkable with a few dozen rows in development and ruinous with real content in production.
Every automated check on the way to production had been green. The platform is ImtehanHub, and the rule that came out of that day sits in every data layer I have written since.
An unbounded list read is a bug on the first day and an outage on the day the collection grows — so every list query carries an explicit limit and the database does the filtering, the sorting and the counting. A quota does not degrade politely. It stops.
What does the constraint not cost you?
Capability. Sign-in, a database that enforces its own access rules, file storage, transactional email, push notifications and error tracking are all available under the rule. What changes is which provider gets picked and how the data layer is written. That is my problem rather than your users'.
ZTools is the product I would point at. It began as a web app of utilities for Zaions, my own company, and I rebuilt it into a tools platform with an Android app, a browser extension and a docs site beside it. All of those are live. None of that changed what it costs to run.
One item on that capability list I did not want to rent. Where a product needs file storage or transactional email, that is FilesHub, a platform I built and operate myself. It exists precisely so the free-tier rule did not have to bend the first time an app needed to send a password reset.
FilesHub is a server, so it does cost something to run. I pay for it. That cost is one platform carrying every product I have, not a line item on each one. It does not reach your bill.
I would rather own that piece than route your files through a service whose pricing page I do not control.
Who runs the product when I am not available?
You, or whoever you hire next. The repository, the deployment, the store listings and the documentation are yours. Nothing needed to run or rebuild the product stays on my machine, and nothing is licensed back to you. The handover is written on the assumption that I am not around to answer questions about it.
Full IP transfer of the delivered code lands on final payment, with a handover that names where the thing is deployed and what it depends on. Anything past the delivered code, such as the hosting it sits on or the accounts it runs on, is what the scope says. It is not a term I publish on a page that has never seen your setup.
So what a delivered product depends on is named in writing at the handover, rather than found later in a stack trace.
There is no server only I know how to restart, and no month in which the cheapest way out of a dependency is to keep paying me.
Finished means it runs without me.
So what does it cost you in the end?
An architecture that only makes sense at a scale you do not have yet. Designs of that shape get ruled out. If one of them is what you had in mind, you hear it before anything starts rather than in month four, when the invoice for the message queue arrives.
It is a real limit. If what you are building genuinely needs that architecture in its first month, this is the wrong constraint for it — and I would rather say so than take the work.
Tell me through the contact form what you are building and roughly where you expect it to run. If you want the engineering half of this, a zero-cost backend architecture that actually holds is the one to read next.
Does a product that costs nothing to run have to be free to use?
No. The rule is about what the product costs me to keep switched on, not about what it charges the people using it. A paid plan sits on top of free-tier infrastructure without contradicting anything. One word is doing the work of two ideas here, and only one of them is mine.
Which running costs still stay with me?
Hosting, third-party services and store fees are yours and are paid to those vendors directly. A domain, a store registration and any API you decided to pay for are invoices with your name already on them, and none of them route through me. What does not appear is a line item for keeping the product switched on.
Is a free tier safe to launch a real product on?
Yes, when the quota is treated as the specification rather than as headroom. That means the database filters, sorts and counts instead of the browser, every list read is paginated with an explicit limit, and a query written without one is a defect on the day it is written, not the day the table grows. Where it is not safe is under an architecture that only works while traffic is small.
Does the constraint limit what my product can actually do?
Sign-in, a database that enforces its own access rules, file storage, transactional email, push notifications and error tracking are all available under it. What changes is which provider gets picked and how the data layer is written, which is my problem, not your users'. What it genuinely rules out is a feature that needs a paid API in the middle of it, unless you are paying for that API and know you are.
What happens if the product grows past the free tier?
It moves onto a paid tier of the same provider, and that move is planned for, not discovered. The database reference and URL live in the application's configuration and nowhere else, so pointing the product at a bigger project is usually a configuration change rather than a rewrite. The constraint is a starting position, and it is meant to be outgrown.
https://aoneahsan.com/blog/what-zero-cost-infrastructure-costs-you