Archives

Nine posts in, the question I actually get isn't 'is this good.' It's 'do I need the paid part, or am I fine with the free one.' Here's the honest answer, not the sales answer.

No engineering lead has ever put 'inconsistent response shapes' on a risk register. It doesn't look like a risk. It looks like a Tuesday. Then it shows up as three weeks nobody budgeted for.

The most honest objection I get isn't about the price. It's this: Laravel already gives me controllers, requests, resources, and exceptions. Why do I need a package to tell me how to use the ones I already have?

Every AI coding assistant I've used writes decent, generic Laravel. None of them write my Laravel, unless I tell them how — and I got tired of re-explaining the same architecture in every new conversation.

A new module means a model, a factory, a repository, a service, a controller, two request classes, a resource, a collection, a DTO, a policy, an observer, a service provider, and a feature test. Eleven files, one architecture, and one command.

The question 'why is this endpoint slow' usually gets answered by adding a third-party APM tool, waiting for a billing approval, and then staring at a flame graph that wasn't built for your architecture. There's a faster answer.

The architecture is free and stays free. But I've watched enough open source maintainers burn out maintaining something for free that I decided, before this ever shipped, not to become one of them.

PHP-FPM forgives you in a way Octane doesn't. It gave every request a clean process — Octane keeps the process alive, and every leftover assumption from the PHP-FPM era turns into a live bug.

Almost every cache bug I've debugged wasn't a TTL problem. It was a scoping problem — the cache didn't know what it was allowed to know, so it forgot the wrong things, or remembered the wrong things, at exactly the wrong moment.

Two requests updated the same row eleven milliseconds apart. Both read the same starting balance. Both wrote what they believed was correct. One of them was wrong, and nothing in the stack told us which.

The first thing I check in a Laravel code review now is how many places in the codebase catch a fatal error and decide what to do about it. The honest answer is usually: however many controllers exist.

Ask ten engineers on the same team what a validation error looks like in your API, and you'll get more than one answer. That's not an API. That's a suggestion — and it's the second post in The Foundation Papers.

Every Laravel project I started for eight years began the same way — I copied the last one. This is the story of why I stopped, and what I extracted instead: core-foundation, now open source.

I’m starting something I’ve wanted to do for a long time. A public build series where I go from the very first line of agentic AI code all the way to enterprise-grade architecture — completely in the open.

Throughout my professional life, the most difficult engineers I had to collaborate with have had one thing in common: they find it hard to expand on what has been already done. You almost know them at first glance...

I've come to a critical realization that software engineering is not a craft when it’s done on a professional capacity. why? read more...

I've come to a critical realization that software engineering is not a craft when it’s done on a professional capacity. why? It's all about the law of diminishing returns. As we know writing and verifying code takes time, leading to a clash between two forces: business and engineering.

I've come to a critical realization that software engineering is not a craft when it’s done on a professional capacity. why? read more...