Early in your career, you usually measure the success of a stack by efficiency: “How can I deliver maximum performance while spending the minimum amount of resources?”. It’s an intellectually stimulating challenge. However, as the years go by — and a few production incidents pile up in your baggage — the metric changes.
Professional maturity doesn’t arrive when you master the framework of the moment, but when you understand that not every technical decision is about performance or cost. Some decisions are purely about who holds the bag when things go wrong.
Every action has a reaction. And every lack of action, a lack of reaction
Before moving on: if you’re setting up a home lab or a study project, ignore all of this. But if there’s a paying client on the other end, things get tight.
The common mistake: confusing price with risk
There’s a dangerous confusion in our development “bubble”: the idea that free is inherently bad and paid is necessarily good. That’s not quite how it works. The problem isn’t the value of the invoice at the end of the month, but where that resource is positioned in your architecture.
The truth is that everything “works until it doesn’t.” A lab accepts anything; production doesn’t. The mistake isn’t using a free service. The mistake is using a service without guarantees at the heart of your application.
What SLA really means
Let’s step outside the books here: if you look up the academic definition of SLA (Service Level Agreement), you’ll find uptime percentages and availability calculations. But in the real world — real people, flesh and bone, with their own motivations — SLA is something else: it’s the boundary of responsibility.
SLA is the line that divides what is a “vendor technical incident” from what is “a problem exclusively yours”:
- With SLA: If the service goes down, there is a contract, a response window, and a legal obligation.
- Without SLA: If the service goes down, the provider owes you nothing. And “nothing”, in this case, includes even a support response.
Without an SLA, you can be “terminated” for any reason, in any situation — how do you explain that to paying clients? At the end of the day, SLA is what separates a professional partnership from silent “good luck.” A service with an SLA usually has:
- Incident response with defined windows
- Priority in mitigation queues during regional failures
- Financial credits or contractual penalties in case of violation
Without an SLA, there is no queue, there is no deadline, and there is no obligation — and if it exists, there is no obligation to deliver any of it. You’re not just cheaper in the queue — you’re out of it.
Free Tier with SLA
The entry point starts here.
Don’t get me wrong, I’m not anti-free. On the contrary, many excellent services offer free tiers that are designed for production from day one.
We’re talking about categories like transactional emails, DNS, basic observability services, or third-party APIs. The characteristic here is clear: limits are explicit, continuity is guaranteed and, if you exceed usage, billing is automatic. The service is free up to a point, but the support structure and the seriousness of the service are the same as the paid plan.
This is an entry strategy, not a shot in the dark.
Free Tier without SLA
Here, if I liked emojis, I’d use the siren and warning ones several times.
The real problem lives in “free by benevolence”. That model where the provider offers a resource without contractual guarantees. Here, the scenario changes: accounts can be terminated without notice, resources can be removed overnight and, in case of regional instability, you’re last in the priority queue.
Without an SLA, you’re building your house on rented land and the owner can ask for it back at any moment. If the service disappears, all the downtime and data loss become a problem you’ll have to explain alone to your client.
Real examples of critical infrastructure interruptions at companies with SLAs:
- AWS: in October 2025, Amazon Web Services suffered a major outage in its US-EAST-1 region, affecting platforms like Reddit, Snapchat, Uber rival Lyft and many dependent services. The failure started in an internal network subsystem, blocking everything from DNS to core APIs for hours. This type of event shows that even giant providers can impact the core when a central component fails.
- Azure: in October 2025 (that month was rough), Microsoft faced a significant outage in Azure Front Door, impacting critical services like Microsoft 365 (Teams, Outlook, SharePoint) and infrastructure associated with the Azure environment.
What do we learn from this? Even a service with an SLA can suffer interruptions; the difference is that, with an SLA, there is a formal response process and possible compensation — without it, you and your client are left in a void and depend on the provider’s goodwill, while your client is sending that two-minute voice message to your WhatsApp.
Core vs. Edge: The distinction that changes the game
To decide where to use what, I use a simple mental model: the division between Core and Edge.
- The Core: What keeps the system alive. Compute, database, base networking. If this goes down, the system stops existing. In the Core, Free Tier without SLA is a bet that’s far too dangerous for any serious professional
- The Edge: Auxiliary services. Integration webhooks, analytics, secondary job triggers or non-critical audit logs. If the edge fails, the impact is contained
Ideally, even edge services should have SLAs, even when they’re on a free tier. “Free with automatic billing when you exceed limits” is still a contract. “Free by benevolence” is not. The difference isn’t technical — it’s strategic. Free in the core is a bet. Free at the edge is a strategy.
The argument nobody likes to hear
Whenever we discuss this, someone raises their hand and says: “But I’ve been using service X for five years and never had a problem.”
We need to be honest: “never had a problem” is not an engineering metric, it’s a statistic of luck. And luck is not an infrastructure strategy. Seniority begins precisely when you consciously decide to reduce risk, instead of proving you can operate at the edge of danger.
Personal experience, no matter how long, does not replace a contractual guarantee when disaster knocks on the door.
A career decision, not a stack decision
When you work as a freelancer or lead a project, your reputation is on the line. For a personal project, a weekend offline is a lesson. For a client, it’s loss and broken trust — and even lawsuits, depending on the size of the mess.
Choosing to pay for a service with an SLA — or opting for a free tier that offers minimum guarantees — is a decision about your quality of sleep and the longevity of your career. It’s about predictability. It’s about being the professional the client trusts because they know you’re not “playing” with their business.
The criterion I carry for life
Before implementing any service in a production application for a final client, I run a small mental checklist:
- Does this service have a clear SLA?
- If it goes down right now, who is responsible for responding?
- If it disappears tomorrow, how big is my migration effort?
- Am I saving money or am I just taking on a risk that doesn’t belong to me?
Mature engineering isn’t about extracting every drop of performance from the stack or saving every cent. It’s about knowing where not to play.
Top comments (0)