Forem: Rafhael Marsigli

SLA, Free Tier, and Professional Maturity

Rafhael Marsigli — Wed, 04 Feb 2026 17:06:25 +0000

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.

Real-World Core Web Vitals: What Actually Impacts Business

Rafhael Marsigli — Sat, 31 Jan 2026 17:17:12 +0000

In a previous post, I've talked about the real-world PageSpeed reality for typical websites. Now it’s time to move past opinion and look at real companies, real experiments, and measurable business impact.

I’ve selected four real, well-documented cases where performance and Core Web Vitals improvements produced concrete results, followed by two broader data points that help put everything into perspective — no hype, no miracle promises.

Four cases with real impact

These are not small or isolated cases. They involve large companies, operating in highly competitive markets, spending millions to improve and optimize their code quality.

Vodafone: +8% in sales after improving LCP

Vodafone ran a controlled A/B test comparing two versions of a landing page. The main difference between them was performance, especially Largest Contentful Paint (LCP). After improving LCP by roughly 31%, the results were:

+8% increase in sales
+15% increase in lead-to-visit rate
+11% increase in cart-to-visit rate

This is one of the clearest examples of how performance directly impacts conversion when there is traffic volume and a well-defined funnel.

Google Search: a direct correlation between speed and abandonment

Google itself has published data showing that:

When load time increases from 1s to 3s, the probability of bounce increases by 32%
When it goes from 1s to 5s, bounce probability can increase by up to 90%

This is not a ranking case. It’s more important than that: a real user behavior signal that directly affects retention, engagement, and conversion metrics.

T-Mobile: aligning performance metrics with business metrics

T-Mobile implemented monitoring based on real user data (field data) using web-vitals.js. They found that degradations in metrics such as LCP and CLS were directly associated with:

higher bounce rates
lower conversion rates
worse perceived user experience

This case is not about a single headline number. It’s about proving that performance degradations show up directly in business metrics.

Shopify: where every 100ms matters

Shopify published internal data showing that:

100ms improvements in load time resulted in measurable increases in conversion rate
Small performance regressions caused negative revenue impact at scale

This type of impact only shows up when traffic operates at massive scale.

Data that puts everything into context

Not every performance improvement shows up as direct conversion. These data points help explain the real role of Core Web Vitals within the ranking ecosystem.

Google: Core Web Vitals are a ranking factor, but not a dominant one

Google officially states that Core Web Vitals are part of the ranking signals, but they do not replace relevant content, authority, or satisfied search intent. According to John Mueller (Google Search Relations), CWV works more as a tie-breaker than as a primary ranking factor.

Studies show many top-ranking sites don’t pass all CWV thresholds

Independent analyses indicate that many well-ranking pages do not meet all Core Web Vitals thresholds, reinforcing that:

CWV helps, especially in competitive scenarios, but it does not replace content, authority, or well-served intent.

So… what does this prove?

Performance and Core Web Vitals generate real impact when there is a technical bottleneck, meaningful traffic volume, and conversion on the table
They are part of modern SEO, but they don’t replace content, authority, or intent
Improving CWV helps you compete better, not “hack” rankings

Performance is a leverage point — powerful, but contextual. When there is scale and a real bottleneck, it turns into revenue. Outside of that, it turns into cost. Mature architecture is not about chasing perfect scores — it’s about knowing when to stop optimizing and start delivering value.

Before optimizing another 5 points of CWV, validate whether it actually solves a real business problem.

How I Cut Hosting Costs by $250/year With a Simple VPS Setup

Rafhael Marsigli — Wed, 28 Jan 2026 19:41:30 +0000

I'll get straight to the point: I maintain 5 legacy web clients. They pay me for simple hosting, and until last month, they were all sitting on a cPanel reseller account that cost me about approx. $28 USD (R$ 160.00/month.

Today, I migrated everything to a setup that costs me $7.50 USD, and I'm able to deliver a better service.

These are old, chill, loyal clients who just want the peace of mind of knowing that: their sites will stay online, and their emails will reach suppliers, accountants, etc., without having to hang on the phone with support. Well, that last point can be a real pain in the neck for those using shared hosting—but that's a topic for another discussion.

The thing is, every end of the year, the provider sends me a price hike notice that gets more absurd every time—I get it, costs are up, but I have nothing to do with that.

So, before the year ended and my hosting plan expired, I decided to "seek knowledge."

The Alternative

After a lot (or maybe not so much) of research, the best alternative I found—one that had a good cost for me and delivered equal or better quality for my beloved clients—was:

Hetzner VPS (~$7/month with backups)
HestiaCP as my control panel
Cloudflare for DNS (Free plan)
Brevo for Email (Free plan)

The first thing I had to get used to (one of the few downsides) is that Hestia is ugly. Ugly as sin. Not that cPanel is a work of art, but HestiaCP's layout looks like it came straight out of the 90s. Plus, the interface forces you to click three times more (and guess where things are hidden) to get to where cPanel would get you in one click. Coolify, which doesn't even focus that much on beauty, runs circles around poor old HestiaCP visually. But Hestia is that "ugly but functional" tool that gets the job done, and gets it done well.

Yeah, but for the savings, it was totally worth it. The first step was renting a new Hetzner server (I already have an account with a few servers there, so this was literally just configuration), and—after setting up the Firewall—installing HestiaCP on bare metal.

Pro Tip: Never install a service like HestiaCP inside a Docker container; stick it directly onto the machine (bare metal). It was built to manage the OS.

Even before migrating the (few) clients, I added all of them to Cloudflare to speed up DNS propagation—it was almost instant. Configuring the accounts afterward was easy: first, I "disable the Cloudflare proxy (the orange cloud)" to generate the SSL on the server, and then enable it again later (this avoids that SSL handshake latency between the client in Brazil and the server in Germany).

And finally, the email configuration

This was supposed to be the part where "the rubber meets the road" (or where the nightmare begins). But it wasn't.

It would be madness to use the Hetzner IP to send emails directly; it's begging for a headache (blocklists hate cheap cloud IPs). The alternative was using an SMTP Relay: 1. AWS SES, 2. Resend, or 3. Brevo.

I chose Brevo because I can have more than one domain on the free plan, unlike Resend. Plus, I get 300 free emails per day, which is way above the volume my clients actually use. I also didn't want to go through AWS SES's massive bureaucracy—I wouldn't be surprised if they asked for a blood sample just to unlock a production account.

Here, I have the peace of mind that even if I need to pay for Brevo's monthly plan in the future, I'll still be turning a profit.

So, it was just a matter of creating an API key to use in my Hestia setup and watching the logs to see if everything was going smoothly. Honestly? It's easier to configure this than dealing with "graylist" issues and the bad reputation of shared IPs from popular hosting providers.

The result one month later

Zero client complaints.
Zero email deliverability issues.
Fluid site navigation.

All my fears fell apart. Was it hard work? Yes, because you have to manually configure one client, repeat for the next, repeat for the next... But on the technical side, it's incredibly simple and robust.

And cheap. Can it be more work? Sure, but the support from those big companies often can't solve anything without you giving them technical hints or begging to be escalated to a higher tier of operations anyway. In the end, it was worth it.

The bottom line: From R$ 160+ (January would have had another hike) down to approx. R$ 45.00 ($7.50 USD). After this first month, I thought: "Ah... I should have done this years ago, and I'd have a brand new motorcycle in the garage by now! (or not)"

About scale

This is not a project meant for dozens of servers. It’s designed to maintain what I already have, with room for ~10 more simple accounts without issues.

It’s not a huge amount of money saved, but it’s a great way to apply and learn different approaches in production. Not every client wants extreme performance - most of them just want the basics online, reliably.

Extra Tip

Cover your back. Hosting is wonderful until the first limit is hit or the first IP gets blocked. Have transparent contracts and terms of service, both for you and your clients. Define clear storage limits, fair extra fees if a limit is breached, and explicitly define punitive actions in case of abuse—like spamming, for example.

This Post Wasn’t Written by AI

Rafhael Marsigli — Mon, 26 Jan 2026 19:30:06 +0000

Or was it? 🤔

Let’s be honest: just the emoji used here already raises suspicion. This emoji pattern is used to exhaustion by AI-generated texts ("please Claude, don’t use emojis in the DAMN REPO DOCUMENTATION"), so before even reaching the second sentence the reader is already skeptical (and rightly so). I myself start reading with bias, looking for signals instead of ideas — and I use AI for a lot of things.

Those signals show up fast. The structure is just too good. Balanced paragraphs, a clear introduction, organized development, a predictable conclusion. A text built to perform well: SEO, headings, keywords nicely distributed, and that strategic separation (which annoys me) with --- between h2s. Because every “well-written” article needs a visual pause.

And when AI

Creates those texts

That look like a poem?

Full of punchy one-liners??

Yeah, that’s been bothering me. A lot. Sometimes I just want to read without feeling like I’m being led around by an algorithm or by a clearly manipulative text. Don’t get me wrong, none of this is wrong. But the problem is that, added together, everything starts to sound the same.

The bad side

When I launched the blog on my site, I fell into this trap — not in the way big news portals do, but in a more “juvenile” way. I’d write the article, AI would improve it, I’d read the result — think it looked beautiful — and publish it. The next day, when I reread it, I felt embarrassed, rewrote it, added my human flaws (which I actually like!). But then it doesn’t engage.

Writing without AI makes me realize that I love writing, but I’m painfully bad at it. I’ve always dreamed of writing a book, even if it sells nothing, but my very human limitations get in the way of producing something decent. The short-term solution I found is this:

Use AI to tear your text apart, give that brutally honest critique — but without rewriting it. Let me spend half an hour here writing, even if that means publishing one less post per month.

But is it worth it? Probably not. Let’s be real. Look at the most consumed content, the most mainstream stuff, the best-selling books, the most listened-to music, the most watched movies. This is how the world works. And this is where the so-called dead internet theory starts to feel less exaggerated and more like a natural consequence: Skynet won’t take over the internet, we won’t become slaves, babies won’t feed the Matrix — but humans have discovered it’s easier to outsource thinking than to sustain an original idea.

Thinking is tiring, making mistakes publicly is costly, and having an opinion exposes you — oooh, nice punchy sentence! Like it or not, AI creates a comfortable, error-proof safety layer. We stop exposing what we really think or what our real quality is, and instead expose what we want to show — or what others expect from us.

As a result, that text about that amazing project becomes 100% technical, beautiful, but empty of business logic — why was that decision made? AI doesn’t know, and it was the one who wrote it. We end up in that space where everything is well written, everything is correct… and everything is the same.

The good side?

There’s a lot of good stuff there — which can be used for evil or just used poorly. I now have: a reviewer, a junior programmer, a DevOps assistant, and hundreds of other roles/tasks just a chat away. Same quality as a real specialist? Of course not. But delivering something decent for a fraction of a fraction of the cost? Absolutely.

Ok, but you’re contributing to the end of jobs, creative work, humanity, the whales.

Here I need to bring up a harsh reality: nobody cares. Often not even us. We don’t fight for what we don’t actively defend — we just accept it, or get left behind. Small developers, small studios, and creative people without deep technical backgrounds are now shipping genuinely useful things thanks to the accessibility AI brought. And it feels like this is just the beginning. I don’t even know what my professional future will look like in 10 years, but I have to reference that now-dead blog/podcast I loved: Update or Die.

I’m from the era when DreamWeaver was loved (that’s a lie, that era never existed), and even though I was slow to adopt some things, I realized how rewarding it is to have an assistant on your second monitor working on your side project while you do your day job. Or that AI technical review that will save you — and teach you — a lot before an important presentation.

It’s dangerously gratifying. Once again, we’re putting ourselves in the hands of a few big companies. So what can we do? Get very rich and escape to the countryside (lovely dream), or accept it and try to build some financial cushion. Maybe the future of content isn’t about proving it was written by humans, but about accepting that if no one risks saying something real, it hardly matters who wrote it.

Damn, I’m really nailing the punchy lines today.

So tell me — do you think this text was written by AI? Or not? 🤔

How I Built Persistent Memory for AI Using TypeScript and Markdown

Rafhael Marsigli — Fri, 23 Jan 2026 21:35:27 +0000

Cross-platform. TypeScript strict mode. 30 E2E tests. Multi-OS CI. Independent technical review. Built in less than 24 hours, with AI.

This is the story of the build. What happened in the following 30 days is another story.

The pain that woke me up in the morning

If you use Claude, Codex, or any AI assistant for programming, you’ve lived this. Every session starts the same way: paste context, repeat rules, reinforce decisions already made, warn about what cannot be done, explain the project’s patterns one more time. No matter how good the AI is, it always starts from zero.

“Ah, but just keep a CLAUDE.md, GEMINI.md, etc.” Yes, you can do that. But what can a single file really represent in a living project, with history, accumulated decisions, and current state? In the end, it’s like working with an extremely capable developer, but with a goldfish memory.

I had already been trying - and managing, with a lot of manual work — to solve this for months using hand-written Markdown. It worked, but it was rough. Every new project felt like starting from scratch, as if I were carving important decisions into stone every time.

The problem was never the AI. It was the lack of persistent memory, real history, and decisions that don’t get lost between sessions.

The idea: external memory for AI

After shaping and organizing the ideas in my head for a while, at 8 a.m. I woke up decided — it’s like those days when you wake up possessed by the urge to clean the house — everything was clear enough to turn into code.

That’s how AIPIM - AI Project Instruction Manager was born. It used to be AI Project Manager, then AIPM, then… through a random but valuable insight, AIPIM. Not as hype, but as a practical tool. The proposal is simple: create an external memory layer between the project and the AI assistant.

This layer solves two core pains: keeping persistent context between sessions and recording the real project history, including decisions, tasks, and current state. All of this is organized in a .project/ structure, entirely in Markdown, which the AI can read, respect, and follow.

context.md becomes the source of truth
current-task.md defines the focus
decisions/ stores immutable architectural decisions
backlog/ with completed/ records work honestly

I was already using exactly this methodology before AIPIM existed. The difference is that now it became an automated CLI.

How I worked with AI (for real)

I didn’t use passive autocomplete. I used Claude Code as a pair programmer. I defined the direction, the AI executed, I reviewed everything, fixed a lot of things, and nothing passed without full understanding. There was no “accept suggestion.” There was technical dialogue.

A real example: I asked for a framework detector. The AI proposed heuristics using package.json and the filesystem. I pointed out edge cases, like React with Vite versus CRA, and demanded hierarchical fallback. The flow was continuous, no context switching, always with human decisions in command.

By the afternoon, the first `aipim install` worked

Near the end of the afternoon, the first milestone was standing: a functional CLI. It wasn’t magic. There were bugs, tweaks (my goodness, many of them — if Claude had ears, they’d be hurting), and review. AI leaves traces, especially in complex tasks, and someone needs to follow those traces carefully. From the start, I made it clear that the project needed to be cross-platform, with real error handling like EACCES and ENOSPC, working on Windows, macOS, and Linux.

Updates without overwriting customization

This was a point where AI alone wouldn’t solve it. The problem was updating base templates without destroying user customizations. The obvious suggestion was to use git diff. My answer was simple: what if there’s no git? What if the repository is dirty?

The solution was architectural. Each generated file receives a cryptographic SHA-256 signature embedded as a comment. If the hash matches, the file is pristine and can be updated. If it diverges, it was modified and must be preserved. Claude implemented it perfectly, but the decision was human. This point, by the way, was one of the most praised in the technical review, compared to strategies used in Kubernetes manifests.

Tests: where AI really shined

I don’t like writing tests (although I do write them), and here the AI was absurdly good. I asked for unit tests for the detector and, in minutes, there were 17 cases covering all frameworks. Then I asked for more: 30 cross-platform E2E scenarios. Tests came for installation, update, validation, and task lifecycle, running on Linux, Windows, and macOS in CI. That would have been days of manual work.

It took just a few hours.

`TypeScript Strict`, no compromises

Here I was picky, but I’d be with myself anyway. Strict mode, zero any. The rule was explicit and the AI respected it. In the technical review, the type safety score was 95/100.

The Brutal and Honest Feedback

The strengths were clear: clean architecture, the SHA-256 signature system, 30 cross-platform E2E scenarios, and strict TypeScript. The red flags were fair too: a diff command announced but not implemented, a dependency installed and not used, and too few tests in the updater, a critical module.

The final score was 88/100.

What I Learned in These First 24 Hours

AI doesn’t replace judgment; it executes. Tests stopped being an excuse; in 2026, not having tests is a choice. And speed doesn’t have to kill quality when there’s process.

Numbers, 24 Hours Later

There were about 2,000 lines of core code and 2,000 lines of tests, 30 E2E scenarios, strict TypeScript without any. Without AI, this would have taken one to two weeks. With AI, it took about 24 real hours — including a trip to the mall with my family in the middle of the day. The project was functional, tested, and published to npm. Exactly as I wanted: an evolved version of my old Jurassic Markdown manager.

What Came Next

In the following days, I used AIPIM to manage AIPIM itself:

I documented nine sessions
Completed 31 tasks
Wrote eight ADRs
Fixed all 16 red flags
Raised the score from 88 to 90

But that’s for a next post, because this one has already crossed the healthy longform limit (even though I enjoy it).

For Those Who Want to Go Further

The complete technical report is available in the repository, generated with Claude Code (Sonnet 4.5), and can be read in full. AIPIM is already on npm and on github.

Usage is simple and explained in the README.

PageSpeed 70 vs 95: the true reality

Rafhael Marsigli — Mon, 19 Jan 2026 17:52:05 +0000

Let’s be honest from the start: if you have a website for an accounting firm, a psychologist, a real estate agency, a barbershop, a clinic, an office, or any other common local business, it’s very unlikely that someone is opening your site with a stopwatch in hand thinking:

“Wow, it loaded in 1.8s instead of 1.2s.”

That’s simply not how most decisions are made in the real world.

The myth the dev bubble helped create

(And at some point, I was part of it too.)

Inside the developer bubble, it often feels like a PageSpeed score below 90 is a serious mistake, Lighthouse not fully green is a sign of negligence, and a CLS above 0.1 is almost an architectural sin. But outside that bubble — where businesses need to generate leads and pay bills — the logic tends to be far more pragmatic.

Clients want to show up on Google, be found on Maps, inspire trust, and be able to contact someone without friction. They don’t know what LCP is, they don’t care about TBT (not the old Twitter one, the other), and they’re very unlikely to reject a service because a PageSpeed score is 78 instead of 95.

And that doesn’t make them wrong — just human.

So… does PageSpeed matter?

Yes, it does. A lot. But not in the same way for every context.

There’s a massive difference between a truly slow website — heavy, janky, taking 5, 6, 8 seconds to show anything — and a well-built site sitting around a 65–80 score, loading fast enough to deliver a solid experience.

Beyond that point, gains still exist, but they stop being transformational and become incremental. Going from 40 to 70 completely changes user perception. Going from 70 to 95 improves important details, but rarely redefines the outcome of a local business on its own.

“But what about SEO?”

Yes, speed is a ranking factor. That’s a fact. But it’s also not the dominant factor in most scenarios.

In practice — especially for common websites — content quality, well-executed local SEO, clarity of the offer, authority, and reviews carry far more weight. Speed works as a strong reinforcement — often as a tie-breaker — but rarely as a miracle solution on its own.

A PageSpeed score of 98 helps, improves experience, and reduces friction. It just doesn’t compensate for weak content or a confusing value proposition.

The point almost no one puts on the table

Chasing very high scores usually involves real technical decisions: reducing animations, revisiting aesthetics, changing rendering strategies, moving to SSG/ISR, optimizing builds, reviewing dependencies. All of that has a cost — in time, complexity, and architectural trade-offs.

For many common websites, the most visible return from these optimizations appears when there is volume: meaningful traffic, many sessions, many conversions, or more complex digital products. Outside of that, the gains exist, but they’re more subtle and cumulative.

This isn’t being anti-performance. It’s understanding technical proportion. Architecture is also about knowing how far it makes sense to go.

The right question isn’t “what’s the score?”

The right question is:

“Does my site load fast enough to deliver a good experience and not push people away?”

If the answer is yes, you’ve already solved most of the problem. Everything else becomes refinement.

A quick preview of the next post

Before anyone assumes this is just opinion, a future post will continue this discussion and dive into the data: real studies, Core Web Vitals, field metrics, large companies, and concrete impacts on conversion and business. No empty lab tests — just numbers from people who actually gained or lost money because of performance.

Now I want to hear from you: have you ever seen a client complain about speed? Lost a project because of a score? Felt a real difference after improving performance?

Let’s talk about real life — with less dogma and more context.

This post was conceived, developed, and written by me. I used AI only to improve clarity and readability.

So, AI will finally take your job

Rafhael Marsigli — Wed, 14 Jan 2026 15:00:00 +0000

This question show up every year wearing a different outfit.

Before, it was:

Low-code
No-code
Dheap offshore labor
Frameworks that “do everything”

Now it’s AI’s turn.

And as always, the fear isn’t irrational — it’s just misdirected. I won’t be a denier, nor an alarmist. This is a practical analysis, based on what’s already happening right now, not on marketing promises.

The mistake starts when we confuse code with work

Many people think a programmer’s job is writing code. It’s not. Code is a byproduct. The real work of a programmer is:

Understanding problems
Translating business rules
Making technical decisions
Dealing with trade-offs
Taking responsibility for failures

AI writes code. It does not take responsibility for consequences.

What AI already does better than many people

Let’s be fair. Today, AI is already excellent at:

Generating CRUDs
Writing repetitive code
Creating basic tests ~~(oh, thank you AI!)~~
Refactoring isolated snippets
Suggesting implementations

This scares those who live only at this level. And here comes the uncomfortable part:

"a large portion of the market lives exactly there."

Who is actually at risk

AI doesn’t replace “programmers". It replaces profiles. From this perspective, those at risk are:

People who only execute tickets
Those who copy and paste without understanding
Those who depend on frameworks to think
Those who cannot explain their own code

These people aren’t losing ground to AI. They’re losing ground to inevitable automation. And being brutally honest, fighting the “AI revolution” is like fighting the industrial revolution — it doesn’t work.

Who gains strength with AI

Now the other half of the story — and this is where it gets interesting. Gaining strength are:

Developers who understand the domain
Architects
~~Eeal~~ seniors
People who know how to say “no”
those who design before they code

For these profiles, AI becomes a force multiplier, not a competitor. In practice, a high-quality employee who doesn’t ask for equity.

AI still doesn’t build systems — it builds answers

A point almost no one talks about: AI responds to prompts. It doesn’t understand organizational context. It doesn’t know:

Why a rule exists
What level of risk is acceptable
What would break the business
who pays the price when things go wrong

Systems live inside human realities. AI does not.

The near future: fewer devs, more responsibility?

Yes, there will be fewer positions for trivial code, mechanical tasks, and context-free maintenance. But there will be more demand for clarity, predictability, architecture, and technical communication.

The market doesn’t want less software. It wants less chaos.

The real dividing line

The question isn’t: “Will AI take my job?” It’s: “Can I explain why my code exists?” If the answer is yes, you’re safe. If it’s no… the problem isn’t AI.

How to prepare (for real)

Not by learning more frameworks.

But by learning fundamentals, business domain, code reading, clear writing, and simple design. And by using AI as an assistant, a copilot, an accelerator — never as an outsourced brain.

AI doesn’t replace professionals

It replaces improvisation, superficiality, and blind dependency. If you write code without understanding the system — yes, your job is at risk. If you build systems that people and businesses depend on — AI came to help you, not replace you.

The future doesn’t belong to those who type faster. It belongs to those who think better.

A Love-Hate Letter do Json

Rafhael Marsigli — Wed, 14 Jan 2026 14:43:57 +0000

Using JSON as a configuration format is (usually) a mistake.

Not a preference. Not a style choice. A normalized architectural mistake, and a very normalized one.

People get uncomfortable with that sentence because JSON works. And in tech, once something works, we collectively agree to stop asking if it actually makes sense, and we start building religions around it.

Let’s be clear, JSON is a massive success. As a transport format, it’s basically unbeatable: predictable, deterministic, boring in the best way, trivial to parse, trivial to generate, everywhere. Machine-to-machine, JSON is fantastic. The problem starts when we look at a format designed to be produced by computers, and decide it should also be written, read, reviewed, versioned, and maintained by humans, as if we were also computers, just slower.

We are not.

And yes, “but my editor formats it” is not an argument. That’s like saying a chair made of nails is fine because you bought good pants.

This is not an attack on JSON. This is an attack on the industry habit of using the right tool in the wrong place, then acting surprised when the people writing it start to hate their lives.

Why JSON won

JSON didn’t win because it’s expressive. It won because it’s limited, consistent, and boring. That’s an enormous advantage when two systems that don’t know each other need to exchange data without negotiating intent, context, and interpretation.

It’s a small closed format. No clever shortcuts. No “oh but in this case”. No magical semantics. Just primitives and structure. That is exactly what you want for contracts. When someone says “my API speaks JSON”, everyone understands the shape of the deal instantly. No surprises. No creative interpretations. No YAML-level philosophical debates about what on means.

As a transport format, JSON deserves all the respect it gets. If the file is machine-generated, rarely touched, and validated by a strict schema, JSON on disk is fine. My problem is human-authored JSON pretending to be a friendly authoring format.

Where everything starts to go wrong

The moment you decide humans should author JSON, you are effectively saying: “the syntax matters more than the intent”. You don’t say it out loud, but that’s the outcome.

This usually doesn’t come from malice. It comes from laziness dressed up as simplicity: “the system consumes JSON, so people should write JSON”. It sounds logical. It’s also the kind of logic that produces self-inflicted pain at scale.

JSON demands perfect syntactic precision to express even the smallest idea. One missing quote, one comma, one bracket, and everything breaks. There is no “kind of broken”. There is only “parse error” and the conversation is over.

For machines, that’s fine. For humans, that’s hostile.

And before someone says “skill issue”, go edit a large IAM policy JSON at 2am, push it, break production, and then come back to lecture everyone about how “it’s simple, actually”.

JSON is structurally hostile to humans

This isn’t taste. It’s structural.

JSON has no comments. JSON is verbose. JSON makes you repeat yourself. JSON makes you care about commas and quotes more than meaning. JSON has no way to express intent, only structure. So people start inventing conventions and superstitions:

“this key is optional, but only in this scenario”
“this value is a string, but it behaves like an enum, except when it doesn’t”
“this section is deprecated, but still required because reasons”
“don’t touch this block unless you like pain”

And because JSON can’t carry context, the context leaks elsewhere: README files, Confluence pages, Slack messages, tribal knowledge, “ask João”. Your configuration stops being configuration and becomes a scavenger hunt.

When you see a big hand-written JSON file, it rarely communicates clarity. It communicates resistance. It communicates that someone suffered, and the only reason it still exists is because everyone agreed to pretend this is normal.

JSON configuration is a normalized mistake

Configuration, by definition, is something humans will read, write, review, version, and argue about in pull requests. It carries intent. It needs context. It benefits from comments. JSON provides none of that, by design.

So what happens? We create these beautiful 300-line objects full of tiny flags, where one comma can invalidate the entire thing, and then we ship the “documentation” somewhere else. Review becomes painful. Change becomes scary. And the final experience is basically “it works, but it works powered by spite”.

Examples everyone knows:

tsconfig.json: it’s not the worst offender, but it’s the perfect illustration of “human-authored JSON that wants comments really badly”.
package.json: scripts, tool configs, overrides, it becomes a dumping ground because it’s convenient, not because it’s good.
Any complex policy config (permissions, rules, routing, workflows): JSON turns your domain into punctuation management.

And yes, you can add tooling. You can add schemas. You can add validators. You can add prettier. You can add a UI that generates JSON. Notice something? The more serious your system gets, the more you move humans away from writing JSON. That’s not a coincidence. That’s your own architecture admitting the truth.

The pro-JSON argument

“But JSON is simple. Everyone knows it.”

Everyone knows a lot of things that are terrible tools for certain jobs.

Everyone knows regular expressions too. That does not mean we should store business logic as regex strings inside a JSON file and call it “configuration”. Familiarity is not a tool-selection criterion. Fitness for the problem is.

JSON is simple to consume, not simple to author. And that distinction matters a lot more than people want to admit.

Authoring formats exist for a reason

If the config is meant to be written by humans, use a format designed for humans.

TOML exists for a reason. HCL exists for a reason. Even YAML exists for a reason, and yes, YAML has its own problems, and anyone pretending YAML is “clean” has probably never debugged a weird parsing edge case on a Friday night.

But the point stands: authoring formats usually allow comments, are more readable, and reduce the cognitive cost of writing. They let people think about the domain first, and the representation second.

Also, a lot of “good” systems already follow this pattern:

Humans write something expressive. Machines validate and normalize it. JSON only shows up at the boundaries, when data needs to travel, or when it becomes a strict contract between systems.

That separation is not bureaucracy. It’s respect for human limits.

The pipeline that avoids unnecessary suffering

In well-designed systems, the flow is usually:

Humans author something expressive, comfortable, and reviewable.
The machine validates it, transforms it, normalizes it.
JSON appears only when it must: transport, persistence, interop.

If you want typed configuration, TypeScript can be amazing, because types and tooling actually work in your favor.
If you want “configuration people can read and discuss”, TOML/YAML/HCL or a small DSL is often a better fit.
If you want system-to-system contracts, JSON is still the king.

The pattern repeats in modern tools because it works. It respects human limitations and exploits machine strengths. Forcing JSON from the start skips the sane pipeline and pushes all the cost onto the people who should pay it the least.

Hater or fan?

I still love JSON where it makes sense: contracts, APIs, serialization, machine-to-machine communication.

I still hate JSON when someone expects me to write, review, and maintain complex rules in it, as if that were a normal human experience.

This is not elitism. It’s not a trend. It’s not stubbornness.

It is basic respect for the people who have to deal with the code.

JSON does not need to be omnipresent to remain valuable. It just needs to stay in the right place.

And that place is definitely not between you and the keyboard at two in the morning.

The Silent Revolution of Workflow Automation: How n8n Broke the Market

Rafhael Marsigli — Tue, 13 Jan 2026 15:00:00 +0000

The silent revolution of workflow automation has finally reached everyone's hands. For over a decade, automating processes between different systems was a privilege of large corporations with generous budgets or depended on tools that charged heavily for every small action executed.

Then came n8n.

An open-source platform created in Berlin that, in less than six years, has earned over 163,000 GitHub stars, surpassed 230,000 active users, and reached a valuation of $2.5 billion in October 2025. More important than the numbers: n8n proved that it was possible to build powerful automations without spending a fortune or handing over data control to third parties.

This article provides a deep dive into how workflow automation has evolved, why traditional tools created artificial barriers, and how n8n shattered those paradigms. This is a dense, long article backed by extensive research—so get ready and sit back, because there’s quite a story to tell! So grab your snack and drink...

The World Before n8n: A Decade of Automation for the Few

To understand n8n's impact, we must first examine the landscape that existed before its arrival. The history of workflow automation for non-programmers began in 2010, when the idea of connecting applications without writing code seemed revolutionary.

IFTTT and the Birth of Simple Automation

In December 2010, Linden Tibbets and his brother Alexander launched IFTTT (If This Then That) in San Francisco. The proposal was elegant in its simplicity: create automatic "recipes" based on single triggers. If it rains, send a notification. If you post on Instagram, save the photo to Dropbox.

The platform quickly won over millions of users—reaching 32 million—but its fundamental architecture imposed severe limitations. IFTTT worked only with single-step linear flows. There was no way to create conditional branches, loops, or complex data transformations. When the company implemented a freemium model in September 2020, limiting free users to just three applets, the community reacted with frustration. The tool that promised simplicity revealed its structural limitations.

Zapier and the Consolidation of the Task-Based Model

A year after IFTTT, in October 2011, three freelance developers—Wade Foster, Bryan Helmig, and Mike Knoop—noticed they were building the same integrations repeatedly for different clients. From this frustration, Zapier was born, eventually becoming the giant of the category.

Zapier grew impressively, reaching $310 million in annual recurring revenue in 2023 and a $5 billion valuation in 2021. However, Zapier's pricing model created a fundamental problem. The platform charges by tasks—and every action within a workflow counts as a separate task. A flow with 10 steps processing 200 orders a day consumes 60,000 monthly tasks, which can easily exceed $899 per month. For startups, costs scale exponentially.

Integromat and Make

In Prague, a team led by Ondřej Gazda developed Integromat, launching in 2016. It stood out by offering a more sophisticated visual builder. In 2022, it was rebranded as Make, positioning itself as the enterprise version of Zapier. While it brought innovation, it maintained a pricing model based on operations, where even "polling" (checking for triggers) could consume credits, leading to billing surprises.

The Four Barriers That Prevented Democratization

Before n8n, four structural obstacles kept workflow automation as a privilege of the few:

Pricing That Punishes Growth: The task-based model created a perverse trap: the more you automated, the more expensive it became.
Cloud-Only and Zero Data Control: Data—including access tokens and customer info—flowed through third-party servers, creating security and compliance (GDPR/HIPAA) nightmares.
Vendor Lock-in: Workflows built on one platform couldn't be exported to another. If a vendor raised prices, the cost of switching was rebuilding everything from scratch.
Developers Treated as Second-Class Citizens: Existing tools offered limited snippets for JavaScript or Python with severe memory and time restrictions, no debugging, and no Git versioning.

The Birth of n8n in Berlin

Enter Jan Oberhauser, a German developer with a unique background in the Hollywood visual effects (VFX) industry. Having worked on films like Maleficent, Jan became an expert in automating pipelines to ensure files flowed seamlessly between artists and renders.

From Personal Frustration to Side Project

When Jan founded his own startups, he found existing automation tools unsatisfactory. He developed n8n as a side project for a year and a half because he needed something that worked with obscure APIs, allowed self-hosting for data protection, and provided access to the source code.

The Launch

n8n GmbH was founded in June 2019 in Berlin. The name "n8n" is a numeronym for "nodemation"—combining "node" (referring to both the visual interface and Node.js) with "automation."

Fun Fact: Jan chose the abbreviation because he didn't want to type a long name into the terminal every time he ran a command.

What Did n8n Do Differently?

n8n reimagined the fundamental rules of the market through four key architectural decisions:

1. Fair-Code Model

Instead of traditional open-source or closed proprietary models, n8n adopted Fair-Code. The code is on GitHub for everyone to see and modify. It is free for internal use and self-hosting, while protecting the project from being repackaged and sold by hosting competitors.

2. Free and Unlimited Self-Hosting

This was the most disruptive move: anyone can run n8n on their own infrastructure for free with unlimited executions. A $5-10/month VPS is enough to start. Sensitive data never leaves your infrastructure, making GDPR compliance trivial.

3. Pricing per Execution, Not per Task

n8n charges (in its cloud version) per workflow execution, not per individual action. A 50-step workflow counts as one execution. This makes n8n 10 to 50 times cheaper for complex, high-volume workflows.

4. Total Freedom for Code

n8n treats developers as first-class citizens. You can write full JavaScript or Python, import any npm library, execute terminal commands, and use native GraphQL. The visual editor allows real-time debugging, showing inputs and outputs for every node.

The Market Impact and the AI Era

The combination of these features removed the barriers for millions. Startups can now automate from Day 1. I, Personally, spend less than $ 6 USD) per month to run my entire n8n infrastructure!

The AI Catalyst

Since 2022, n8n has positioned itself as the ideal platform for AI Orchestration. It offers over 70 nodes related to LangChain, with native connectors for ChatGPT, Claude, Gemini, and local models via Ollama.

75% of n8n clients already use AI features. Because of self-hosting, companies can build AI agents that handle sensitive data without sending it to a third-party cloud.

Now, automation Finally Belongs to Everyone

For over a decade, business automation required a choice between expensive simplicity or inaccessible power. n8n broke that false dichotomy.

From a side project in Berlin to a $2.5 billion unicorn, n8n's success validates an alternative business model where transparency is the expectation, not the exception. It has forced giants like Zapier and Make to reconsider their pricing and value propositions.

The future of productivity is about doing less of what doesn't matter to do more of what does. n8n is the tool for that future.

Why I Dropped Laravel Observers?

Rafhael Marsigli — Mon, 12 Jan 2026 22:30:00 +0000

In a previous post about migrating to DTOs, I talked about how I stopped depending on Laravel’s “magic arrays” in favor of stricter typing. That was Step 1 of my journey toward more predictable code. This wasn’t yesterday, and it’s not exactly recent, but I still think it’s worth documenting this experience here.

Once you start using DTOs and an Actions/ style architecture, the Observer path becomes weird (and kind of unviable) pretty quickly.

So, without further ado (yes, I know, I write a lot and I tend to ramble), today I need to talk about Step 2, and this one hurt more than I expected: I stopped using Observers as a crutch.

For years I was (I mean, I still am, just differently) a Laravel power user. If the docs had a feature, I tried it. Observers felt like a superpower: skinny controllers, “clean” models, and every side effect neatly hidden inside a UserObserver.

But as my projects stopped being simple CRUD apps and became actual business domains, I started noticing a very ugly pattern: Observers are not clean code. Observers are invisible logic. And invisible logic is the kind of thing that makes you waste an entire afternoon staring at the wrong file, convinced the bug is “in Laravel”, when it’s actually inside an Observer someone created 9 months ago and forgot about.

The “clean code” illusion

The appeal of an Observer is obvious. You open the controller and it looks beautiful:

public function store(UserData $userData)
{
    // Look how "clean" this is!
    $user = User::create($userData->toArray());

    return response()->json($user);
}

Pretty. But there’s a catch: that “clean” is mostly makeup.

Because, without the developer who will read this file 6 months from now realizing it, that single line User::create() may trigger a whole chain reaction:

Sends a welcome email
Creates a Stripe Customer
Logs activity
Notifies a Slack channel
Updates a search index
Clears some cache keys
Brews coffee

And so on.

And that’s where the fun begins. You look at the line, it just “creates a user”. But the system is basically throwing a secret party behind your back.

This is what I call Spooky Action at a Distance: you change the database here, and code executes somewhere else you didn’t even remember existed.

The execution order trap

Another very common issue is execution order betraying you.

Imagine you have logic in the created event that depends on some relationship. But if you use User::create(), created fires immediately. Often before you had a chance to associate stuff like Roles, Teams, Profile, etc.

And then you start seeing code smells like this:

public function created(User $user)
{
    // Trying to guess if the relation is loaded yet...
    if ($user->relationLoaded('team')) {
        // ...
    }
}

This is fragile. And worse, it’s fragile in a silent way.

Today it works. Tomorrow someone changes a flow, runs an import, uses createQuietly, or just changes the order of an attach, and suddenly your Observer becomes roulette.

If a business rule depends on the accidental execution order of Eloquent events, that’s not “architecture”. That’s faith.

The real issue: side effects with no owner

Deep down, what made me quit wasn’t “observers are evil”. It was realizing I was putting business rules in a place where:

It’s not obvious they exist
It’s not obvious when they run
It’s not obvious how to disable them
It’s not obvious how to test the flow without triggering half the system

Even when nothing breaks, the mental cost is still there. And when something breaks, the developer debugging it pays the bill.

There’s a moment in every experienced dev’s life where the last thing they want is more headache. They want control and predictability.

The solution: explicit beats implicit

In the same way I replaced Form Requests with DTOs to make input explicit, I replaced Observers with explicit Services and Actions.

Yes, it means writing a few more lines.

But those extra lines tell a story. And story is what your “future self” needs when something goes wrong.

And I think this is the most important point: an Action wants to be an explicit flow. An Observer wants to be an invisible side effect. Put the two together and you get a system where nobody knows what the “source of truth” for behavior actually is.

Here’s a refactored version of the flow. Notice there’s no magic. You read the code and you know what happens:

final class CreateUserAction
{
    public function __construct(
        private BillingService $billing,
    ) {}

    public function execute(UserData $data): User
    {
        return DB::transaction(function () use ($data) {
            $user = User::create($data->toArray());

                      DB::afterCommit(function () use ($user) {
                          $this->billing->createCustomer($user);
                        });

            $user->notify((new WelcomeNotification())->afterCommit());

            return $user;
        });
    }
}

The bonus is that your code becomes a control panel.

Want an import to NOT send emails? Don’t call it.
Want an admin flow that creates users without Stripe? Don’t call it.
Want to test only “create user” without triggering the rest of the universe? You can.

When Observers ARE acceptable

Does this mean Observers are useless? Obviously not. I still use Observers when it’s a purely technical concern, always true, regardless of context, and not really a business rule.

Examples I consider acceptable:

Generating a UUID for a model
Clearing cache keys
Updating search indexes (Elasticsearch/Meilisearch), depending on the case

But business logic (sending emails, charging a card, assigning teams, provisioning resources)? I avoid it.

Because business rules need an owner, and they need to live somewhere you can actually see.

Maturity is predictability

I already hinted at this earlier: when we’re junior, we love tools that do things for us. We love magic.

As we get more senior (more grumpy?), magic starts charging interest. You start preferring code that says exactly what will happen, even if it looks less elegant. Dropping Observers felt uncomfortable at first. I felt like I was writing “boilerplate”. But that “boilerplate” turned into something much more useful: living documentation. It’s code I can read, understand, and debug without needing a mental map of the entire event system.

If you’re tired of side effects breaking flows, take a careful look at your Observers.

Especially the created one.

Especially the one that “just does a tiny thing”.

And if it makes sense, move it into a Service or an Action and make the flow explicit.