Welcome: Why I Wrote This Book

After seven years of consulting work across more than a hundred development teams, I kept seeing the same pattern: smart developers, good intentions, and codebases that had become impossible to change.

Not because the developers were bad. Not because PHP was wrong. But because side effects, hidden dependencies, and tightly coupled code had compounded over time until every change risked breaking something unexpected.

The Team That Shipped Nothing #

One team stands out in my memory. They hadn’t shipped a single feature in six months. Not one. Management was frustrated, developers were demoralized, and the codebase had become something everyone feared to touch.

When we arrived, we (Benjamin Eberlei and I) found controllers with methods spanning two thousand lines. Npath complexity so high that static analysis tools reported integer overflows. Massive arrays stored in sessions, passed between controllers that each expected slightly different structures. SOAP calls and SQL queries scattered throughout business logic.

It took twenty-five days of careful work, writing end-to-end tests first, then continuously extracting methods, renaming concepts, and separating concerns, to get the controllers down to a size where developers could work productively again.

The team started shipping within weeks.

This wasn’t an exceptional case. It was typical.

The Common Thread #

Every codebase I entered had the same fundamental problem when it came to testing and maintainability: side effects.

Code that modified global state. Code that reached out to databases in unexpected places. Code that depended on the current time, the filesystem, or external services without any way to control those dependencies. Code where calling a method twice might produce different results, not because of different inputs, but because something somewhere had changed.

This kind of code cannot be tested in isolation. It cannot be reasoned about locally. A change in one place can break something in another place with no obvious connection.

The solution isn’t to eliminate side effects entirely, that leads to pure functional programming and a level of abstraction that slows down practical web development. The solution is to actively minimize side effects while keeping the flexibility to have them when necessary.

Why This Book Exists #

I wrote this book because the same patterns that helped those hundred teams can help yours.

These aren’t academic theories. They’re patterns that work in production, under pressure, with real deadlines and real constraints. Patterns that let teams move fast without creating disasters. Patterns that make code changeable instead of feared.

The book covers the core insight that separates state from logic, the building blocks that make this practical (Data Objects, Services, Gateways, Controllers, Components), and how to introduce these patterns into existing codebases without breaking what already works.

Two Perspectives, Not One #

Throughout the book, two voices offer different perspectives on the same problems. Paula and Peter represent approaches I’ve seen in nearly every development team, and the tension between them is productive.

Paula builds libraries. Her code is used by teams she’ll never meet. She needs interfaces, clear extension points, and comprehensive type safety. When she ships something, it must be right, because changing it later breaks other people’s code. She favors Test-Driven Development and extracts interfaces early.

Peter builds products. He has full access to all the code. When requirements change, he can change everything. He favors simplicity and speed. He writes testable code but only tests what matters. He trusts his team to read the code rather than relying on documentation that will go stale.

Both approaches are valid. Paula’s approach is essential for open source libraries and frameworks. Peter’s approach is efficient for product development where the team controls all the code.

Context determines which approach fits. The book will help you recognize that context.

Pay What You Want, Including Zero #

This book uses pay-what-you-want pricing, starting at €0.

Why? Because I’d rather you read it and apply the patterns than skip it because of price. If it saves your team even one day of debugging, consider coming back to pay then.

The knowledge in this book comes from real consulting work, real disasters averted, and one company (Frontastic) that scaled through eight years and multiple pivots without ever needing a rewrite. If that knowledge helps you, that’s enough.

Different bundles include different materials, just the book, the book plus code examples, or everything including AI integration files for modern development workflows. Pick what fits your needs.

What You’ll Learn #

You’ll learn how to structure code so that it stays simple as it grows. How to separate concerns so that changes stay local. How to introduce these patterns into existing codebases without breaking what works.

You’ll learn when to write tests and when to just write testable code. How to scale horizontally when traffic spikes. How to organize teams around bounded contexts as you grow.

Most importantly, you’ll learn how to make code changeable, because changeable code is what lets teams ship.

Get Started #

The book is available now in multiple formats: PDF, EPUB, MOBI, and HTML. Code examples and AI integration files are available in higher tiers.

Choose your bundle and start reading. If it helps, great. If not, you paid what felt right.

Let me know what you think. I’m genuinely interested in whether these patterns work for your team the way they’ve worked for the teams I’ve consulted with.

– Kore

P.S. If you’ve worked with me before, as a consulting client, a conference attendee, or a colleague, you already know I’m not selling theory. This is the stuff that actually worked. I just finally wrote it down.