DEV Community: Olusola Ojewunmi

The Case Against Rewrites: How I Evolved a 5-Year-Old Backend Codebase (And Why You Probably Shouldn’t Rewrite Yours Either)

Olusola Ojewunmi — Tue, 10 Mar 2026 10:02:00 +0000

A deep dive into modernising legacy systems incrementally without breaking production or losing years of edge-case history.

1. Most Legacy Systems Don't Fail Because of Bad Code. They Fail Because of Emotional Decisions.

Let's start with an uncomfortable truth: when your massive, tangled production backend starts slowing your team down, the code isn't your biggest enemy. Your ego is. And right behind your ego are the twin sirens of software engineering: the Rewrite Temptation and the Microservices Hype.

When we stare down the barrel of a 5-year-old backend — one that has survived pivoting business models, changing teams, and feature-factory panic — the instinct is always to burn it down and start over. We want a clean slate. We want the architectural purity we didn't have the time or experience to build five years ago. We tell ourselves it will be faster because "this time, we know the domain." We think that handing the entire business logic over to a constellation of managed cloud services, serverless functions, and shiny new vendors will somehow absolve us from having to manage complexity.

But here is the reality: production pressure doesn't stop just because engineering wants to refactor. If you tie your modernisation strategy strictly to a completely new rewrite or deep vendor lock-in, you are essentially betting the business on an unproven abstraction while starving your current customers of new value.

We didn't rewrite our 5-year-old backend. We evolved it. We deliberately avoided heavy vendor lock-in. We used AI agents not to write the code for us, but to act as archaeologists, dramatically accelerating our understanding of forgotten modules. We flirted heavily with microservices — and even paused the initiative because the organisational timing was undeniably wrong.

This isn't theory. This is the battle-tested playbook for incrementally modernising a growing, breathing monolith — without breaking the clients that depend on it.

2. What a 5-Year Backend Actually Looks Like

If you've never inherited or maintained a system that has been running and evolving for half a decade, the concept of "technical debt" can sound sterile and abstract. In reality, a 5-year backend is less like a poorly built bridge and more like an old city built on top of its own ruins.

When this system started half a decade ago, it was built by a small team operating with an early-career-level understanding. The goal was finding product-market fit, not establishing pristine domain-driven design.

As a result, pattern drift is everywhere. Look closely at the codebase, and you can see exactly when different paradigms were popular. You'll find early controllers that contain 800 lines of raw HTTP requests mingled with database queries and business logic. A year later, there's an attempt at the Repository Pattern — but it was half-abandoned, leaving a mix of raw ORM calls and over-engineered repository wrappers.

Accidental complexity runs rampant. In the critical paths — like order generation or payment processing — the coupling is terrifyingly tight. Fixing a bug in the notification dispatch system inexplicably breaks the user authentication flow because five years ago, someone needed the user's role and bypassed the boundary to fetch it directly from a deeply nested user relationship graph. There are models with 40 attributes and God Classes that serve as a dumping ground for anything tangentially related to a "User."

The standards are inconsistent, but the system works. It makes money. It serves users. You cannot disrespect the code, because the code got you here.

3. The Rewrite Temptation

In the face of mixed abstraction levels and tightly coupled core domains, the call to rewrite the system from scratch is deafening. A rewrite feels clean. It promises an end to the spaghetti code, the legacy bugs, and the cognitive overhead of parsing a giant monolith.

But a rewrite is dangerous, and quite frequently, it is a trap.

The hidden opportunity cost of a rewrite is immense. For every month you spend rebuilding existing functionality in a "cleaner" way, your product stagnates. Competitors move forward. The business grows impatient. But the technical risks are even worse: regression risk and knowledge evaporation.

That messy, 800-line function you loathe? It contains five years of hard-won edge-case handling. When you throw away the code, you throw away the business history written into it. The correct safety net for a rewrite is not a high code coverage number — a test suite can achieve 100% line coverage and still miss critical edge cases entirely if its assertions are weak. Coverage measures execution, not correctness. What you actually need is a comprehensive suite of behaviour-level tests that capture the observable outputs of every critical path. Practically speaking, that suite doesn't exist in most legacy codebases, which means a rewrite almost certainly guarantees that you will reintroduce old bugs.

Take a firm stance: unless the underlying technology stack is entirely deprecated, unsupported, or fundamentally incapable of scaling to projected usage, you must resist the rewrite. Evolve the system instead. Respect the edge cases.

4. The Microservices Attempt That Stalled

We didn't just consider rewriting; we aggressively pursued decomposition into microservices. Splitting these domains into discrete services seemed like the obvious, "senior" thing to do.

When the idea was first floated, I consulted a mentor with significantly more architectural experience. He explicitly warned against it: microservices weren't necessary for our scale, and we should simply embrace gradual refactoring over time. I didn't take that advice then — though I desperately wish I had.

And then, we stopped.

It wasn't a technical failure; it was a reality check. The key driver for the architecture change — yours truly — fell critically ill and took an extended leave of absence. Suddenly, the complex orchestration fell onto a team that was already trying to stay afloat. When I returned, feature backlog pressure from the business was crushing. I needed to ship value, not wire up Kubernetes clusters.

We realised a critical lesson: Architecture must survive absence. Microservices require organisational readiness and depth — your infrastructure maturity and team structure must match the architecture. Ours didn't yet.

So we paused the distributed microservices dream. Instead, we shifted our strategy to a Modular Monolith, as I was initially advised by my mentor. The goal was to set and improve our internal boundaries inside the existing codebase first — and then extract services later, only if and when the team and infrastructure were ready.

5. The Incremental Modernisation Framework

This approach mirrors what Martin Fowler describes as the Strangler Fig pattern — incrementally replacing legacy behaviour by building the new system around and alongside it, rather than in a single "big bang" replacement. The name comes from the strangler fig tree, which grows around a host tree over time until the host is fully replaced. Applied here, every modernised module is a new ring of growth around the legacy core, with the old code gradually hollowed out and replaced rather than demolished all at once.

I adopted a highly tactical blueprint built around this philosophy. It is designed to be executed incrementally, meaning feature development never has to fully stop.

Step 1: System Mapping Before Touching Code

Before you write a single line of refactoring, you must map the territory. We used dependency tracing to identify the deeply coupled domains — the modules where a change in one place sent shockwaves into three others.

Step 2: Behaviour Locking

You cannot safely change what you cannot test. We introduced what Michael Feathers, in his landmark book Working Effectively with Legacy Code, calls characterisation tests — tests written not to verify correctness, but to document and lock the current, actual behaviour of legacy code before you move it. We locked the behaviour so that as we started moving walls around, we would instantly know if we broke a load-bearing structure.

Step 3: Domain Isolation

With tests in place, we began domain isolation. This didn't mean moving code to a new server; it meant moving it to a clear, isolated namespace within the monolith with strict boundaries. Concretely, this meant:

Namespacing by domain (e.g., App\Domains\Orders, App\Domains\Payments) rather than by technical layer.
Banning cross-domain Eloquent relationships. If the Orders domain needed user data, it called a dedicated UserReadService interface — it did not reach across and eager-load a $order->user->wallet->transactions chain. Violations were caught in code review.
Using internal domain events to communicate state changes across module boundaries, laying the groundwork for potential future extraction without tight coupling.

To illustrate how this changed the code, here is how our OrderController evolved.

Before (V1): The God Controller

public function store(CreateOrderRequest $request): JsonResponse
{
    try {
        $order = $this->orderService->createOrder($request);
    } catch (Throwable $e) {
        return response()->error('Error occurred while creating order');
    }

    try {
        // Tight coupling to the Wallet/Ledger domain — reached directly across boundaries
        $charge = $this->orderService->walletCharge($order->user_id, $order->price, $order);
        $paymentComplete = data_get($charge, 'status');
        $remainingDebit = data_get($charge, 'remaining_debit');
    } catch (Throwable $e) {
        return response()->error('Error occurred while charging wallet');
    }
    // ... matching payment channels and long response logic ...
}

After (V2): The Delegating Controller & Isolated Service

class OrderController extends Controller
{
    public function store(UnifiedCreateOrderRequest $request): JsonResponse
    {
        try {
            // The controller's only job is HTTP input/output.
            // All business orchestration lives in the service layer.
            $result = $this->unifiedOrderCreationService->createOrder(
                $request->validated(),
                auth()->user()
            );

            return response()->success([
                'order'   => new OrderResource($result['order']),
                'payment' => $result['payment'],
                'pricing' => $result['pricing'],
            ], 'Order created successfully.');
        } catch (OrderCreationException $exception) {
            // Map domain exceptions to safe, user-facing messages.
            // Raw exception messages are never exposed to API consumers
            // to avoid leaking internal implementation details.
            return response()->error('Unable to process your order. Please try again.', 422);
        } catch (Throwable $exception) {
            Log::error('Unexpected order creation failure', [
                'user_id' => auth()->id(),
                'error'   => $exception->getMessage(),
            ]);
            return response()->error('An unexpected error occurred. Please contact support.', 500);
        }
    }
}

The payment and pricing logic — previously reached by crossing domain boundaries directly in the controller — now lives entirely within UnifiedOrderCreationService, which coordinates between App\Domains\Orders and App\Domains\Payments through their defined interfaces.

Step 4: Database Evolution Strategy

One of the most practically challenging aspects of this kind of modernisation is the schema itself. We handled this carefully across two modes:

Where the existing table structure was close enough, we extended it with new columns via additive migrations — never dropping or renaming existing columns before both V1 and V2 consumers were confirmed to be off the old fields. This expand-then-contract approach meant V1 and V2 endpoints could coexist on the same data without a risky simultaneous cutover.

Where the old schema was fundamentally at odds with the new domain model, we created new tables and models entirely, wrote dual-write logic during the transition period, and deprecated the old table once traffic had fully migrated. This was cleaner than trying to contort an existing structure and avoided the risk of a failed migration taking down V1 in the process.

Step 5: Opportunistic Refactoring

We implemented the "Touch → Improve" rule. We didn't carve out entire sprints for tech debt. Instead, if an engineer had to touch a massive God Class to add a feature, they were expected to leave it slightly better than they found it — extracting one method, adding one test, removing one dead branch.

Step 6: Versioned Endpoints Strategy

To avoid breaking consumers — mobile apps, web clients, third-party integrations — we preserved all V1 endpoints exactly as they were. When a domain was fully isolated and tested under the new architecture, we introduced V2 endpoints with the clean interface. Consumers migrated on their own timelines.

6. Using AI as a Code Archaeologist

AI is not an architect. It will not magically refactor a coupled monolith into clean domains. What it provides is an unparalleled acceleration in the comprehension phase — the part that usually takes senior engineers days of careful reading.

I used AI as a Code Archaeologist. When facing a 1,200-line controller handling dynamic pricing variations that no one had touched in three years, a human engineer would spend most of a day just mapping the variable states and tracing the execution paths. Instead, I would feed the code into an AI agent workflow — using Windsurf and GitHub Copilot for in-editor analysis, and constructing detailed, structured archaeological prompts in ChatGPT and Gemini — asking the agent to trace the data flow, identify unintentional duplication, and document the implicit business rules buried inside conditional logic. It surfaced hidden business rules and flagged dead variable paths in a fraction of the time a full human review would require.

This heavily assisted my safe refactoring process. But I remained rigorous about validation. AI acts as an incredibly smart pair programmer who completely lacks institutional context. In one case, an agent confidently asserted that a variable was unused — missing an indirect call via PHP's dynamic reflection that would have caused a production failure if I had acted on it blindly. Every AI output was treated as a strong hypothesis to be verified, not a conclusion to be merged.

The ultimate architectural judgment — what to abstract, what to leave alone, what the business actually needs — must remain in the hands of the senior engineer.

7. What the Git History Revealed

If you want to understand the true state of your architecture, don't look at the codebase today. Look at the git history.

In the Early Stage (Year 1), the commits were enormous: "Added the custom response macros, needed libraries, exception handlers, models, and migrations." No boundaries. Entire domains were slammed into the monolith in single commits. The git log reads like a construction site — fast, functional, and completely undisciplined.

In the Mature Stage (Recent Commits), the inflexion points are unmistakable: "feat: implement ops authentication with role-based access control." Commit hygiene improved significantly. Class sizes stabilised. Domain-scoped changes stay within their namespaces. You can quantify the maturity of an engineering culture solely through log analysis — and what you find will either give you pride or a very clear improvement agenda.

8. Avoiding Vendor Lock-In

One of the great modern traps is coupling your architecture to proprietary services. We deliberately kept business logic portable. We treated cloud providers as commodity compute, not as an extension of our domain logic. Queues, storage, and caching were accessed through abstraction layers rather than vendor-specific SDKs embedded throughout the codebase.

Modernisation should increase your portability, not decrease it. If switching your queue provider requires changes in 40 files, your modernisation has made you more fragile, not less.

9. Measurable Improvements

The results were concrete and trackable:

Defect rate on order operations dropped significantly. Once the new domain boundaries were locked in and characterisation tests were in place, the number of bugs originating from order-related operations dropped dramatically. The few issues that did surface were rapidly isolated — the clear boundaries meant the blast radius of any problem was immediately obvious, and fixes were targeted rather than speculative.
Reduced cognitive load. I went from being terrified to touch the pricing module to confidently building and shipping new enterprise pricing tiers.
Faster onboarding. Clearer domain boundaries mean a new engineer can understand a specific module without needing the full five-year context of the system.
Performance gains without rewrite sprints. Opportunistic refactoring during feature work yielded significant performance improvements on critical APIs — without a single dedicated "performance sprint."

10. Hard Lessons

I will be completely candid: not everything was a success.

Unnecessary refactors. I cleaned up legacy corners that had a defect rate of zero and hadn't been modified in three years. I wasted cycles making "ugly" code look pretty. If it works and rarely changes, leave it alone. The Boy Scout Rule applies to code you touch — not code you stumble past.
Premature abstractions. I built generic interfaces for future data models that never materialised. Abstractions are liabilities until they are proven by actual use cases.
AI oversight. The reflection call incident above was a real near-miss. AI output requires the same scrutiny as a pull request from a brilliant engineer who has never read the product requirements. Review it accordingly.

11. Redefining "Modern"

Modern does not equal rewrite.
Modern does not equal distributed microservices.
Modern does not equal the latest buzzword.

Modern means Observability, Replaceability, and Clear Boundaries — whether those exist across Kubernetes clusters or across namespaces in a well-structured PHP monolith.

The Reality Check

Let me be completely clear: our evolved system is not a flawless utopia. We still encounter bugs. We still hit unexpected performance bottlenecks as the user base grows. Code still rots if left unattended.

The profound difference today is not the absence of problems — it's our approach to solving them. When a critical bug surfaces now, we don't panic or threaten to nuke the entire module out of frustration. We write a failing test to lock the behaviour, isolate the boundary, and refactor the specific bottleneck. We have successfully replaced emotional, short-term reactions with disciplined, long-term engineering maturity.

That, more than any architectural pattern or tooling choice, is what a successful modernisation actually looks like.

12. Discussion

Evolution almost always beats ego-driven rewrites. But these questions don't have universal answers — they depend on team, scale, and context. I'd love to hear how other engineers navigate them:

When is the exact right moment to finally rewrite instead of evolve?
When is an organisational structure truly ready for microservices?
What does your git history say about your engineering team's growth?

Drop your experiences below. The hardest lessons are the ones we shouldn't have to learn in isolation.

How to Vibe Code Your MVP in Weeks Using AI-Assisted Development

Olusola Ojewunmi — Wed, 21 Jan 2026 10:11:12 +0000

We need to stop pretending that "doing it right" means taking three months to ship a CRUD app.

In the startup world, over-engineering isn't a badge of honour. It is often just procrastination disguised as quality. We hide behind "best practices," clean architecture, and perfect test coverage because it feels safe. It feels professional. But while we are debating folder structures, the market is moving on.

If you are treating your pre-revenue MVP like it’s a legacy enterprise system, you aren't being thorough—you are bleeding opportunity.

I recently shipped a production-ready Laravel MVP in about 45 hours of active coding time, all while working a full-time job as a Senior Engineering Lead. No sabbatical. No 40-hour blocks. Just nights, weekends, and an AI-assisted workflow that turns "stolen moments" into shipped features.

This isn't a guide on how to be lazy. It’s a guide on how to stop hiding.

The Call That Started It All

It was a regular Tuesday afternoon when my screen lit up with a Google Meet invite from the CEO. The CTO was already in the call when I joined. No agenda, no pre-read—just an invite titled "Quick Sync."

The CEO cut straight to it. He recounted something he'd heard about recently—a frustrating experience that had surfaced at a place he frequents. Someone close to the situation had dealt with a friction point that, frankly, shouldn't exist in 2025. The specifics don't matter here, but what struck me was the immediacy. This wasn't abstract product ideation. This was a real problem, freshly articulated, with tangible urgency behind it.

And then the constraint that reframes everything: a prospective first client was already in motion. They faced the same friction, the same gap. The window to deliver something meaningful—while the pain was still visceral—was narrow.

The call ended with a direct question: "How fast can we move on this?"

I gave an honest answer: "A couple of weeks, if we stay focused."

But there was a catch. I wasn't doing this with a clear calendar. I work full-time as a Senior Backend Developer and Engineering Team Lead, and I have my own personal projects in flight. I didn't have 40 hours of open air; I had nights, weekends, and stolen moments.

That was when I started "cooking."

This guide walks you through exactly how I did it—the AI-assisted workflow, the collaboration patterns, and the lessons learned shipping a production Laravel MVP in approximately 40–50 hours of focused coding, spread across 6 weeks.

[!NOTE]
Quick disclaimer: This isn't a Windsurf promotion. Windsurf is my editor of choice, but any capable AI-powered environment—Cursor, VS Code with Copilot, or similar—would work. The workflow is tool-agnostic. The principles transfer.

What You'll Learn

How to use AI for architectural scaffolding before writing code
Setting up an effective AI-assisted development environment
The iterative workflow that actually works under pressure
Collaboration patterns for distributed teams
Post-launch maintenance realities and how AI helps (and doesn't)
Time investment benchmarks from a real project

Reality Check: What Vibe Coding Is NOT

Before we go further, let’s draw a hard line. "Vibe Coding" is not an excuse for sloppy engineering.

It is NOT pasting prompts and hoping for the best.
It is NOT shipping code you don't understand.
It is NOT bypassing security or architectural standards.

Vibe coding is context-aware acceleration. It is using AI to handle the implementation details (the "how") so you can focus entirely on the architectural intent (the "what" and "why"). If you can't read the code the AI generates, you shouldn't ship it.

Prerequisites

Before you start vibe coding your MVP, ensure you have:

A clear problem statement (alignment > speed)
Laravel development environment (I use Laravel Herd)
An AI-powered code editor (Windsurf, Cursor, or VS Code with Copilot)
Access to high-reasoning LLMs for architectural thinking (I utilized Claude Sonnet 4.5, Google Gemini 3 Pro, and GPT-5 across my workflows)

Step 1: Architect Before You Code

Don't jump into your editor immediately. Use AI to think through architecture first.

What I Did

With urgency as the backdrop, I needed to move fast but deliberately. The first phase involved getting an initial architecture in place—something I could think through and validate before committing to code.

I opened Google Anti Gravity and described the problem space. Not the solution—the problem. The constraints. The edge cases I could anticipate. This was my first time using it for this kind of architectural thinking, and it proved invaluable for exploring different approaches before writing a single line of code.

Prompt pattern:
"I'm building a system that needs to [core requirement].
The key constraints are [list constraints].
What architecture patterns would you recommend?
What edge cases should I consider before I start?"

Why This Works

AI excels at brainstorming and pattern matching. Before you've written a single line, you can:

Validate data relationships
Identify potential architectural decisions
Surface edge cases you'd otherwise discover mid-implementation
Get a mental model of the system's shape

Time invested: 1–2 hours
Time saved: Potentially days of refactoring

Step 2: Set Up Your AI-Assisted Environment

Once architecture is clear, switch to your code editor.

My Transition

As the project evolved and iteration became heavier, I switched from Google AI Studio to Windsurf. The shift wasn't about capability—it was about workflow fit. Windsurf better suited how I wanted to work contextually, maintaining awareness of the codebase as I moved through features and fixes. I was simply more familiar with its patterns.

The Stack That Worked

Tool	Purpose
Google AI Studio (Gemini Advanced)	Initial architectural scaffolding and design validation
Windsurf	Primary editor with contextual AI assistance
Laravel Boost MCP	Laravel-specific code generation and framework guidance
Herd MCP	Local development environment orchestration
Tailwind CSS	Utility-first styling for rapid UI development
Livewire	Reactive components without leaving PHP

MCP Configuration Note

[!WARNING]
Laravel Boost MCP and Herd MCP are not compatible out-of-the-box with Windsurf's editor and plugins. If you're using these MCP servers, you'll need to configure them carefully. I've written a detailed guide on fixing this: Fixing Laravel Boost in Windsurf: A Global MCP Setup Guide.

Step 3: Iterative Development (The Vibe Coding Loop)

Here's where AI-assisted development truly shines.

The Core Workflow

┌─────────────────────────────────────────────┐
│  0. Create a solid implementation plan      │
│  1. Describe what you want to build         │
│  2. AI generates initial implementation     │
│  3. You review, refine, correct             │
│  4. Test immediately                        │
│  5. Repeat                                  │
└─────────────────────────────────────────────┘

Non-Negotiable: The Implementation Plan

Before writing any code, create a comprehensive implementation plan from start to finish. This isn't optional—it's the foundation that makes AI-assisted development work.

Use AI to help you:

Map out the entire MVP scope
Identify dependencies and sequencing
Surface tradeoffs early (e.g., "Do we need this feature for v1?")
Document decisions so you don't relitigate them later

Fine-tune this plan iteratively with AI until it feels solid. The time invested here pays dividends when you're deep in implementation and need to make quick decisions.

The Key Mindset Shift

AI-assisted ≠ AI-driven

This distinction shaped everything. AI wasn't writing the application for me—it was helping me think faster. When I had an idea, I could validate it quickly. When I needed to scaffold a component, I could generate a starting point and refine it. When I hit a wall, I could explore alternatives without losing momentum.

The human remains the architect. The AI accelerates execution.

Practical Tips from the Trenches

Stay contextual: Keep related files open. AI needs context to be useful.
Correct early: When AI misunderstands, fix immediately. Don't let errors compound.
Commit frequently: Small, atomic commits. You'll thank yourself during debugging.
Test as you go: Don't wait until "it's done." Test components in isolation.

Step 4: Collaboration Patterns That Scale

Sustained pressure demands distributed ownership. Building under pressure is rarely solo, and this project was no exception.

How We Worked

The CTO and I logged significant hours on Google Meet—not merely discussing requirements, but actively testing together in real-time. He would surface something that felt off, I would push a fix, and we'd validate immediately. The rhythm became instinctive.

Periodically, the CEO and company director joined these sessions. There's irreplaceable value in fresh perspective. Someone who hasn't been immersed in the same context for hours will identify friction you've internalized as normal.

Responsibility Partitioning

Role	Ownership
CTO	Server provisioning, Bitbucket pipeline configuration, deployment orchestration, production stability
Developer (me)	Business logic, user flows, edge case handling, bug fixes

This separation enabled genuine parallelism. While I resolved a validation defect, he configured SSL termination. While he debugged a pipeline failure, I refined a notification flow. Neither of us waited on the other.

The Feedback Loop

test → feedback → fix → repeat

The collaboration wasn't ceremonial—it was operational. We weren't scheduling reviews to satisfy process. We were building together, in real-time, with shared accountability for the outcome.

Step 5: Maintenance (Where Reality Asserts Itself)

Shipping the MVP marked a milestone, but seasoned engineers understand: it's the beginning, not the conclusion.

What to Expect Post-Launch

Production users possess an uncanny ability to surface truths that no test suite anticipates:

Edge cases you never modeled will surface
Workflows you assumed were self-evident won't be
Data patterns will defy your assumptions

In the weeks following initial deployment, defects emerged. Requirements evolved. The system that felt complete revealed its gaps under authentic load.

How AI Helps (and Doesn't)

AI tooling continued to accelerate the work—suggesting fixes, helping trace through unfamiliar code paths, reducing the friction of context-switching.

But judgment, prioritization, and accountability remained unambiguously human responsibilities.

No AI can articulate why something matters to the business. It can help remediate a defect, but it cannot determine whether that defect is critical or cosmetic.

A Real Refactoring Story: When Your Data Model Fights Back

I'll be honest here: this one was on me.

During the initial build, I was moving fast with AI-generated code and database structures. I reviewed them, approved them, and moved on. The schema looked reasonable. The relationships made sense at first glance. But I failed to catch a fundamental modeling issue—a key domain entity was set up as a standalone table when it should have been a specialized extension of an existing user-context relationship.

The problem didn't surface until I was testing a related feature, hit a bug, and started digging deeper. That's when the friction became obvious: duplicate data paths, inconsistent relationships, and unnecessary complexity rippling across multiple features.

Here's where AI became genuinely valuable as a thinking partner. I broke down the issue, proposed the remodeling approach, and asked: "What are the ripple effects? And is this worth the effort now, or should we live with it?"

The response was unambiguous: do it now. The reasoning was sound—migrating data and updating relationships would only get harder as the dataset grew and more features depended on the flawed structure. Better to pay the cost early than compound it later.

The fix required significant refactoring:

Extend an existing pivot table with domain-specific columns
Write a data migration to move existing records
Update every component, service, and notification that touched the old model
Refactor related feature relationships to use the consolidated structure
Update all the profile and management components to use the new approach.

The Critical "Senior" Moment
During this refactor, Windsurf suggested a "quick fix" that involved adding a JSON column to patch the data structure without migration. It would have worked instantly. It would have saved me 3 hours that night.

I rejected it immediately.

Why? Because I know that JSON patches on core relational data turn into query nightmares six months later. An AI optimizes for solving the current error. A senior engineer optimises for future maintainability. I forced the AI to generate the harder, proper migration path. Speed matters, but not at the cost of structural integrity.

This was spread across multiple pull requests. AI accelerated each step—generating migration scaffolds, updating model relationships, tracing through affected components. However, the decision to restructure came from living with the original design and recognising where it broke down.

Lesson: Your first data model might be wrong—and that's okay. Design for flexibility and possible refactoring down the road. Don't rush into rigid schema decisions just to feel "done." The cost of early flexibility is low; the cost of late rigidity is high.

Time Investment Benchmarks

Transparency matters. Here's what this MVP actually took, derived from the project's commit history:

Metric	Value
Active development days	8 distinct days
Total elapsed time	~6 weeks
Estimated coding hours	40–50 hours
Total commits	107

Context is critical here. I didn't take six weeks off to build this. I hold a full-time role as a Senior Backend Engineer and Team Lead, plus I actively maintain other personal software projects. This MVP was built entirely in the margins—early mornings, late nights, and weekends.

This is where the true value of AI-assisted development lies. It wasn't just about generating code faster; it was about instant context recovery. When I only had 45 minutes on a Tuesday night, I didn't spend 20 minutes remembering where I left off. Windsurf and the implementation plan allowed me to dive straight into the "flow state," execute a feature, and sign off.

AI tooling didn't eliminate the work—it compressed it. Efforts that might have consumed weeks under traditional workflows occurred in focused sessions, with rapid iteration and immediate validation.

Key Lessons for Your MVP

Reflecting on this project, several principles crystallised:

1. Speed Is a Form of Clarity

Let’s be uncomfortable for a second: Over-engineering is usually disguised fear in a lot of cases. We build complex architectures for simple problems because we are afraid of tech debt. But for an MVP, the only debt that kills you is apathy—building something nobody uses.

In this project, I deliberately skipped standard abstractions I would mandate in my day job. It felt "wrong" at first. But that speed revealed the product's actual shape faster than any architecture diagram could. Code can be refactored; time cannot be refunded.

2. AI Accelerates Momentum, Not Accountability

These tools are force multipliers—they amplify velocity when direction is clear. But they do not own outcomes. Ownership remains yours.

3. Real Users Reveal Truths No Prompt Can Anticipate

Test suites are constrained by your imagination. Users will discover paths you never considered. Architect for iteration, not premature perfection.

4. Collaboration Eclipses Solo Brilliance

The tight feedback loop with the CTO—real-time testing, immediate remediation—delivered more value than any individual AI tool. Human collaboration remains the ultimate accelerator.

Quick Reference: The Vibe Coding Workflow

                  PHASE 1: PREPARATION
                  [Problem Definition]
                           │
                           ▼
              [AI Architectural Brainstorm]
                           │
                           ▼
      [Implementation Plan] ───→ [Environment Setup]
                                        │
                                        │
      PHASE 2: VIBE CODING LOOP         │
            ┌───────────────────────────┘
            │
            ▼
      [Iterative Dev Loop] <──────────────┐
            │                             │
            ▼                             │
      {Working Feature?} ──── NO ─────────┤
            │                             │
           YES                            │
            │                             │
            ▼                             │
      [Test with Stakeholders]            │
            │                             │
            ▼                             │
        {Feedback?} ───────── YES ────────┘
            │
            NO (Approved)
            │
            ▼
       [ 🚀 SHIP IT ] ───→ [Maintenance & Iteration]

Technical Stack Reference

For those interested in the underlying architecture:

Layer	Technology
Framework	Laravel
Frontend	Livewire for reactive components
Styling	Tailwind CSS
Architecture	Multi-tenancy (implementation details intentionally omitted)

Final Thoughts: You Are Out of Excuses

This project proved one uncomfortable truth: The barrier to entry has collapsed.

The "I don't have time" excuse is gone. The "I need a team" excuse is gone. The tools I used (Windsurf, MCP, Claude, Gemini) didn't just write code; they removed the friction that usually kills momentum. They allowed me to be an Architect for 45 hours straight, rather than spending 20 of those hours fighting syntax.

You have a choice.
You can keep polishing your boilerplate, feeling busy, and protecting your ego with "clean code" that nobody uses.
Or you can open your editor tonight, scope it down, and ship something that might actually break.

If you are a senior dev, these tools make you a 10x architect. If you are a junior, they are the best partner you will ever have.

But they won't click the "Deploy" button for you.

The window is open. Start cooking.

What Building a Simple E-commerce Cart Taught Me About Senior Laravel Engineering

Olusola Ojewunmi — Mon, 12 Jan 2026 07:40:08 +0000

TL;DR: I built a production-grade e-commerce cart in 14 hours to explore Laravel Volt. This article focuses on the engineering decisions that matter: concurrency handling, partial failure recovery, data snapshotting, and query optimization. Full source code available on GitHub.

🎯 Context

Over the holiday break, I carved out a focused window to build something I'd been meaning to explore: a production-grade e-commerce cart using Laravel Volt. The entire project—from first commit to final polish—took roughly 14 hours spread across December 29-30, 2025.

This wasn't a side project for fun. It was part of a technical assessment where I was given flexibility to choose my stack. I opted to try Laravel Volt for the first time, knowing it would be a learning experience. Ultimately, the team was looking for a different implementation approach, and we parted ways amicably. But the exercise itself was valuable—it forced me to think deeply about correctness, concurrency, and the kind of engineering judgment that separates junior implementations from senior ones.

📦 The complete source code is available here: https://github.com/Ojsholly/laravel-ecommerce-cart

This article isn't about the UI or feature completeness. It's about the backend decisions that matter when you're building systems that handle real money, real inventory, and real user expectations.

🛠️ Tech Stack

Layer	Technology
Framework	Laravel 12
Language	PHP 8.4
Frontend	Livewire 3 + Volt (first time using Volt)
Styling	Tailwind CSS
Database (Dev)	PostgreSQL
Database (Test)	SQLite (in-memory)
Background Jobs	Laravel Queues & Scheduler
Testing	Pest
Version Control	GitHub

The choice of Volt was deliberate—I wanted to see how it felt to build reactive components without writing explicit Livewire classes. The learning curve was steeper than expected, but it paid off in reduced boilerplate.

🎯 The Problems That Matter

When you're building an e-commerce cart, the interesting problems aren't in the UI. They're in the edge cases:

⚡ What happens when two users try to buy the last item simultaneously?
🛒 How do you handle partial checkout when some items go out of stock mid-session?
📧 How do you avoid spamming admins with low-stock notifications?
📸 How do you ensure historical order data remains accurate even if products change?

These are the problems that junior engineers often miss—and the ones that cause production incidents.

1. ⚡ Concurrency & Row-Level Locking

The most critical part of checkout is stock validation. If you don't lock rows properly, you'll oversell inventory.

The Problem: Race Conditions

Here's the naive approach (don't do this):

// ❌ Race condition: two requests can both see stock = 1
$product = Product::find($productId);
if ($product->stock_quantity >= $quantity) {
    $product->decrement('stock_quantity', $quantity);
}

The problem: Between checking stock and decrementing it, another request can sneak in. Both requests see stock_quantity = 1, both proceed, and you've just sold two units of an item you only had one of.

Visual Breakdown of the Race Condition

Timeline	User A	User B	Database Stock
T1	Read stock → sees `1`		`1`
T2		Read stock → sees `1`	`1`
T3	Check: `1 >= 1` ✅		`1`
T4		Check: `1 >= 1` ✅	`1`
T5	Decrement → `stock = 0`		`0`
T6		Decrement → `stock = -1` ❌	`-1`

Result: Both purchases succeed, but inventory is now negative. You've oversold.

The Solution: Pessimistic Locking

// ✅ Lock the row for the duration of the transaction
$product = Product::lockForUpdate()->find($productId);

if ($product && $product->hasStock($quantity)) {
    $product->decrement('stock_quantity', $quantity);
}

This is wrapped in a database transaction, so the lock is held until the transaction commits. No other request can read or modify that row until we're done.

Full Checkout Implementation

public function processCheckout(Cart $cart): Order
{
    return DB::transaction(function () use ($cart) {
        [$availableItems, $unavailableItems] = $this->validateStock($cart);

        if ($availableItems->isEmpty()) {
            throw new InsufficientStockException('All items are out of stock.');
        }

        $order = Order::create([/* ... */]);

        foreach ($availableItems as $item) {
            $this->createOrderItem($order, $item);
            $this->decrementStock($item->product, $item->quantity);
        }

        $this->removeAvailableItemsFromCart($cart, $availableItems);

        return $order;
    });
}

private function validateStock(Cart $cart): array
{
    $availableItems = collect();
    $unavailableItems = collect();

    foreach ($cart->items as $item) {
        $product = Product::lockForUpdate()->find($item->product_id);

        if ($product && $product->hasStock($item->quantity)) {
            $availableItems->push($item);
        } else {
            $unavailableItems->push($item);
        }
    }

    return [$availableItems, $unavailableItems];
}

💡 Key Takeaway: Without row-level locking, you'll have angry customers who paid for items you don't have. With it, you have a system that behaves correctly under load.

2. 🛒 Handling Partial Failure Gracefully

Here's a scenario that trips up a lot of implementations:

User adds 5 items to their cart
Another user buys one of those items, depleting stock
First user tries to checkout

What should happen?

Approach	Junior Implementation ❌	Senior Implementation ✅
Error Handling	Fail entire checkout with generic error	Identify which items are available
Cart Management	Delete all items (losing user intent)	Process only available items
Stock Handling	Proceed anyway and oversell	Leave unavailable items in cart
User Feedback	Confusing error message	Clear feedback on what was purchased

Implementation

// Separate available from unavailable items
[$availableItems, $unavailableItems] = $this->validateStock($cart);

// Only process available items
$pricing = $this->priceCalculationService->calculateOrderPricing($availableItems);

// Remove only what was purchased
$this->removeAvailableItemsFromCart($cart, $availableItems);

The key insight: Preserve user intent. If they wanted 5 items and only 4 are available, sell them 4 and keep the 5th in their cart. Don't make them start over.

Frontend Handling

On the frontend, unavailable items are clearly distinguished:

✅ Visual indicators (opacity, grayscale images)
✅ "Out of Stock" badges
✅ Excluded from pricing calculations
✅ Checkout button disabled if all items are unavailable

💡 Key Takeaway: This isn't just good UX—it's correct behavior. Partial failure is a reality in distributed systems. Handle it gracefully.

3. 📸 Snapshotting Data for Historical Accuracy

Here's a mistake I see often: storing only foreign keys in order items.

// ❌ What happens if the product is deleted or its price changes?
OrderItem::create([
    'order_id' => $order->id,
    'product_id' => $product->id,
    'quantity' => $quantity,
]);

Six months later, the product is deleted or repriced. Now your order history is broken. You can't show customers what they actually paid for.

The fix: snapshot the product data at the time of purchase.

// ✅ Preserve historical accuracy
OrderItem::create([
    'order_id' => $order->id,
    'product_id' => $product->id,
    'quantity' => $quantity,
    'price_snapshot' => $product->price,
    'product_snapshot' => $product->toSnapshot(),
]);

The toSnapshot() method captures everything needed to reconstruct the order:

public function toSnapshot(): array
{
    return [
        'id' => $this->id,
        'uuid' => $this->uuid,
        'name' => $this->name,
        'description' => $this->description,
        'price' => $this->price,
        'images' => $this->images,
        'primary_image' => $this->primary_image,
    ];
}

💡 Key Takeaway: Orders are legal documents. They need to be immutable and accurate, even if the underlying product data changes or disappears.

4. 📧 Background Jobs & Avoiding Notification Spam

Low-stock notifications are a common feature. The naive implementation:

// ❌ Sends a notification every time stock decrements below threshold
if ($product->stock_quantity <= $lowStockThreshold) {
    SendLowStockNotification::dispatch($product);
}

The problem: if stock is at 5 and the threshold is 10, you'll send a notification on every sale until stock hits 0. That's 5 emails for the same issue.

The fix: only notify when crossing the threshold.

private function decrementStock(Product $product, int $quantity): void
{
    $lowStockThreshold = config('cart.low_stock_threshold', 10);
    $stockBeforeDecrement = $product->stock_quantity;

    $product->decrement('stock_quantity', $quantity);

    $stockAfterDecrement = $product->fresh()->stock_quantity;

    // Only notify when crossing from above to below threshold
    if ($stockBeforeDecrement > $lowStockThreshold 
        && $stockAfterDecrement <= $lowStockThreshold) {
        SendLowStockNotification::dispatch($product);
    }
}

💡 Key Takeaway: Notification fatigue is real. Admins will ignore your alerts if you spam them. Send one notification per threshold crossing, not one per sale.

5. 📊 Daily Sales Reports & Query Optimization

Another common feature: daily sales reports sent via email. The challenge is aggregating data efficiently without N+1 queries.

Here's the job structure:

public function handle(): void
{
    $stats = $this->calculateStats();
    $recentOrders = $this->getRecentOrders();
    $topProducts = $this->getTopSellingProducts();

    Mail::to($adminEmail)->send(
        new DailySalesReport($stats, $recentOrders, $topProducts, $this->date)
    );
}

The interesting part is getTopSellingProducts(). You need to:

Aggregate sales by product
Fetch product snapshots (since products might have changed)
Avoid N+1 queries

Here's how I did it:

private function getTopSellingProducts(): Collection
{
    // Single query to get aggregated sales data
    $topProductsData = Order::completed()
        ->whereDate('orders.created_at', $this->date)
        ->join('order_items', 'orders.id', '=', 'order_items.order_id')
        ->selectRaw('
            order_items.product_id, 
            sum(order_items.quantity) as total_quantity, 
            sum(order_items.quantity * order_items.price_snapshot) as total_sales
        ')
        ->groupBy('order_items.product_id')
        ->orderByDesc('total_quantity')
        ->limit(5)
        ->get();

    // Single query to fetch order items (which contain snapshots)
    $orderItemsByProductId = OrderItem::whereIn('product_id', $topProductsData->pluck('product_id'))
        ->whereHas('order', fn($q) => $q->completed()->whereDate('created_at', $this->date))
        ->get()
        ->keyBy('product_id');

    // Map aggregated data to snapshots
    return $topProductsData->map(function ($item) use ($orderItemsByProductId) {
        $orderItem = $orderItemsByProductId->get($item->product_id);
        $snapshot = $orderItem->product_snapshot ?? [];

        return [
            'name' => $snapshot['name'] ?? 'Unknown Product',
            'quantity' => $item->total_quantity,
            'revenue' => number_format((float) $item->total_sales, 2),
        ];
    });
}

💡 Key Takeaway: N+1 queries kill performance. Two queries for any number of products is better than N+1 queries for N products.

6. 🏗️ Separation of Concerns

One pattern I stuck to throughout: keep business logic out of controllers and Livewire components.

Components should be thin:

public function placeOrder(): void
{
    try {
        $checkoutService = app(CheckoutService::class);
        $order = $checkoutService->processCheckout($this->cart);

        $this->dispatch('cart-updated');
        $this->dispatch('notify', message: 'Order placed successfully!', type: 'success');
        $this->redirect(route('orders.show', $order), navigate: true);
    } catch (\Exception $e) {
        $this->dispatch('notify', message: $e->getMessage(), type: 'error');
    }
}

All the complexity lives in CheckoutService. This makes testing easier, logic reusable, and the codebase more maintainable.

💭 What I Learned About Volt

This was my first time using Laravel Volt, and it was a mixed experience.

What I liked:

Less boilerplate than traditional Livewire classes
Faster iteration for simple components
Good for prototyping

What I found challenging:

Computed properties require specific naming conventions (getXProperty())
Debugging is harder without explicit class files
IDE support is weaker than traditional Livewire

Would I use it again? For rapid prototyping, yes. For a large production app, I'd probably stick with traditional Livewire classes for better tooling and discoverability.

🎓 Reflections

Building this cart in 14 hours was a forcing function. I couldn't afford to bikeshed or over-engineer. I had to focus on correctness first, polish second.

The things that mattered:

✅ Transactions and locking
✅ Handling partial failure gracefully
✅ Snapshotting data for historical accuracy
✅ Avoiding notification spam
✅ Query optimization

The things that didn't matter (in this timeframe):

⏸️ Perfect UI polish
⏸️ Comprehensive admin dashboards
⏸️ Payment gateway integration

💡 Key Takeaway: This is the kind of prioritization that defines senior engineering: knowing what to build, what to defer, and what to skip entirely.

🎯 Final Thoughts

The team ultimately went with a different tech stack, which is fine. Not every project is a fit, and that's okay. But the exercise itself was valuable—it forced me to think through problems I don't encounter in my day-to-day work, and it gave me a chance to explore Volt in a real-world context.

The repo is open source. Star it if you find the locking logic useful: https://github.com/Ojsholly/laravel-ecommerce-cart

The codebase includes:

✅ 123 passing tests (Pest)
✅ Full checkout flow with concurrency handling
✅ Background jobs for notifications and reports
✅ Partial checkout support
✅ Product snapshotting
✅ Query optimization

It's not perfect, but it's correct. And in production systems, correctness is what matters.

🔗 Links & Resources

📦 GitHub Repository: https://github.com/Ojsholly/laravel-ecommerce-cart
⭐ Star the repo if you found the locking logic or partial failure handling useful
💬 Questions? Feel free to reach out—I'm always happy to discuss Laravel architecture and engineering tradeoffs

Thanks for reading! If this helped you think differently about e-commerce cart implementation, consider sharing it with your team.

Fixing Laravel Boost in Windsurf: A Global MCP Setup Guide

Olusola Ojewunmi — Mon, 22 Dec 2025 12:14:54 +0000

Fixing Laravel Boost in Windsurf: A Global MCP Setup Guide

If you’ve tried adding Laravel Boost as an MCP server in Windsurf and hit “cannot initialize server”, you’re not alone.

The most common cause is simple:

Windsurf often starts MCP servers from a working directory that is NOT your Laravel project root.
So a “normal” MCP command like php artisan boost:mcp fails because artisan isn’t in the current directory (or it runs with the wrong PHP).

In other words: this is usually not a Boost problem — it’s a Windsurf MCP launch context problem.

When Laravel announced Boost, I was thrilled.
I rushed over to the docs expecting to see a simple “Use this with Windsurf” section.
But as I kept scrolling… that smile gradually dropped from my face.
I saw Cursor, Junie, and a bunch of familiar integrations — but not Windsurf.
So I kept searching until I landed on a setup that’s boringly reliable.

This tutorial shows a robust approach that works across all your Laravel projects:

Install Boost per project (required)
Add a Windsurf MCP server that calls a wrapper script
The wrapper script finds the correct Laravel project and runs php artisan boost:mcp

If you keep multiple Laravel projects open at the same time, you’ll also see how to configure per-project MCP entries so each project stays isolated.

Note: While we’re configuring Windsurf “globally” so it can work with any project, Laravel Boost itself must still be installed locally in every Laravel project via Composer. This wrapper simply helps Windsurf find the correct local installation.

Bonus:

Add Herd MCP to Windsurf too (handy if you use Herd for local sites/PHP)

The target architecture (what we’re building)

Windsurf can launch MCP servers from arbitrary directories, so the reliable design is to put an adaptive layer in front of Boost:

Windsurf (any cwd)
  -> wrapper script (stable entrypoint)
       -> find Laravel project root (locate artisan)
       -> choose correct PHP (prefer Herd / isolated PHP)
       -> exec: php artisan boost:mcp

Once you understand that flow, every config choice in this guide makes sense.

Prerequisites

You have Windsurf installed
You have PHP installed (Herd/Homebrew/Linux packages/Windows PHP)
Python 3 is recommended (only needed for the optional auto-detection fallback; without it the script falls back to $PWD / SITE_PATH)
You have at least one Laravel project

Install Boost in each Laravel project (required)

In every Laravel project you want Boost to work with:

composer require laravel/boost --dev
php artisan boost:install

Then verify inside that project:

php artisan boost:mcp

If this fails, fix your Laravel app boot/dependencies first. MCP depends on the app being able to boot.

Understanding Windsurf MCP config files

Windsurf follows the Claude Desktop MCP config schema.

Windsurf Editor:
- macOS/Linux: ~/.codeium/mcp_config.json
- Windows: C:\Users\<you>\.codeium\mcp_config.json
Windsurf JetBrains plugin (PhpStorm/IntelliJ):
- macOS/Linux: ~/.codeium/windsurf/mcp_config.json
- Windows: C:\Users\<you>\.codeium\windsurf\mcp_config.json

Warning: If you edit the wrong file, you’ll keep seeing “cannot initialise server” even though the JSON looks correct.

Quick way to confirm you’re editing the right file:

Temporarily point the command to a definitely-invalid path (or rename your wrapper script).
Refresh MCP servers in Windsurf.
If the error message doesn’t change, you’re editing the wrong config file.

For the rest of this guide:

If you’re using the Windsurf Editor, edit ~/.codeium/mcp_config.json
If you’re using Windsurf inside PhpStorm, edit ~/.codeium/windsurf/mcp_config.json

Tip: You can include multiple servers (Boost, Herd, etc.) inside the same mcpServers object.

The Fix: Use a Wrapper Script

Instead of configuring laravel-boost as:

{
  "command": "php",
  "args": ["artisan", "boost:mcp"]
}

…we configure it to run a wrapper script. The wrapper script:

Phase 1 — Locate the Laravel project root

Search upward for artisan
Fall back to other hints like SITE_PATH
(Optional) Use Windsurf trackers to guess active workspaces (requires Python 3)

Phase 2 — Choose the right PHP

Prefer Herd’s per-site PHP when available (so isolated sites use their own PHP)
Fall back to a usable php binary

Phase 3 — Launch MCP

exec herd php artisan boost:mcp (preferred)
or exec <php_bin> artisan boost:mcp

Using the right PHP version per project (Herd + alternatives)

One subtle issue when you have lots of Laravel projects is PHP version drift: one project might require PHP 8.1 while another needs PHP 8.3.

If you use Laravel Herd (recommended)

Herd supports per-site PHP versions via “isolation”. Once a project is isolated, Herd can automatically run the correct PHP when you execute commands from that project.

Set a PHP version for a project:

cd /path/to/your-project
herd isolate 8.3

Confirm what PHP Herd will use for that project:

cd /path/to/your-project
herd which-php

That’s why the wrapper script in this tutorial prefers:

herd php artisan boost:mcp

If you’re not using Herd

You still have options:

asdf / mise / phpenv
- These can select PHP based on the current directory (e.g. .tool-versions / .mise.toml).
- The key is ensuring the tool’s “shims” are available to Windsurf (non-interactive process).
Docker / Laravel Sail
- You can run Boost using the project’s containerized PHP instead of your host PHP.
- This is heavier, but very consistent across teams.
One global PHP
- If all your projects support the same PHP version, the simplest option is to keep one PHP installed globally (Herd/Homebrew/etc.).

macOS / Linux Setup

Step 1: Create the wrapper script

Create a file at:

macOS/Linux: ~/.codeium/laravel-boost-mcp.sh

Then make it executable:

chmod +x ~/.codeium/laravel-boost-mcp.sh

Step 2: Add `laravel-boost` to Windsurf MCP config

Edit:

Windsurf Editor (macOS/Linux): ~/.codeium/mcp_config.json
Windsurf JetBrains plugin (macOS/Linux): ~/.codeium/windsurf/mcp_config.json

Add (or replace) your laravel-boost entry:

{
  "mcpServers": {
    "laravel-boost": {
      "command": "/Users/<you>/.codeium/laravel-boost-mcp.sh",
      "args": ["${workspaceFolder}"],
      "disabled": false,
      "env": {}
    }
  }
}

Multi-project isolation (recommended)

If you work on multiple Laravel projects in parallel, create one Boost entry per project (same wrapper, different env), and give each entry a unique server name.

{
  "mcpServers": {
    "laravel-boost-project-name": {
      "command": "/Users/<you>/.codeium/laravel-boost-mcp.sh",
      "args": ["${workspaceFolder}"],
      "disabled": false,
      "env": { "LARAVEL_PROJECT_ROOT": "/path/to/project-name" }
    },
    "laravel-boost-another-project": {
      "command": "/Users/<you>/.codeium/laravel-boost-mcp.sh",
      "args": ["${workspaceFolder}"],
      "disabled": false,
      "env": { "LARAVEL_PROJECT_ROOT": "/path/to/another-project" }
    }
  }
}

Notes:

Keep your other MCP servers in the same file; just add this entry inside the existing mcpServers object.
The path must be the full absolute path to the script.

If you’re adding multiple MCP servers, don’t replace the whole file—just add laravel-boost inside the existing mcpServers object.

Step 3: Restart/refresh MCP servers in Windsurf

Open Windsurf settings
Go to MCP / Tools
Click refresh (or restart Windsurf)

Step 4: Quick sanity check

Run:

~/.codeium/laravel-boost-mcp.sh --check

You should see:

what directory it decided is the Laravel project root (artisan_dir)
which php binary it found as a fallback (php_bin)
whether Herd CLI is available (herd_bin)
what Herd would use as the PHP for that project (herd_which_php) if available

If this output looks correct but Windsurf still can’t start the server, jump to the Troubleshooting section below.

Step 5: Test the wrapper in real-world scenarios

This wrapper is designed to behave well even when Windsurf starts it from a “random” working directory.

Scenario A: Not a Laravel project (expected: skipped)

From any folder that is not a Laravel app:

~/.codeium/laravel-boost-mcp.sh --check

Expected output includes:

skipped (no Laravel project detected; artisan not found)

Scenario B: Laravel project without Boost installed (expected: skipped)

Inside a Laravel project that does NOT have Boost:

cd /path/to/laravel-project
~/.codeium/laravel-boost-mcp.sh --check

Expected output includes:

skipped (Boost not installed in this project)

Scenario C: Laravel project with Boost + Herd per-site PHP (expected: Herd isolated PHP)

Inside a Laravel project with Boost installed:

cd /path/to/laravel-project
composer require laravel/boost --dev
herd isolate 8.3
herd which-php
~/.codeium/laravel-boost-mcp.sh --check

Expected output includes:

herd_bin: ...
herd_which_php: ... (matching your isolated version)

Then, to confirm it can actually start, run the wrapper (this is a long-running process; stop with Ctrl+C):

~/.codeium/laravel-boost-mcp.sh

Final macOS/Linux wrapper script (multi-project safe)

Save as: ~/.codeium/laravel-boost-mcp.sh

#!/usr/bin/env bash
set -euo pipefail

find_artisan_dir() {
  local dir="$1"
  while true; do
    if [[ -f "$dir/artisan" ]]; then
      printf "%s" "$dir"
      return 0
    fi

    local parent
    parent="$(dirname "$dir")"
    if [[ "$parent" == "$dir" ]]; then
      return 1
    fi
    dir="$parent"
  done
}

find_php() {
  if command -v php >/dev/null 2>&1; then
    command -v php
    return 0
  fi

  local candidates=(
    "/opt/homebrew/bin/php"
    "/usr/local/bin/php"
    "$HOME/Library/Application Support/Herd/bin/php"
  )

  local p
  for p in "${candidates[@]}"; do
    if [[ -x "$p" ]]; then
      printf "%s" "$p"
      return 0
    fi
  done

  return 1
}

get_windsurf_active_paths() {
  local py=""
  if [[ -x "/usr/bin/python3" ]]; then
    py="/usr/bin/python3"
  elif command -v python3 >/dev/null 2>&1; then
    py="$(command -v python3)"
  else
    return 0
  fi

  "$py" - <<'PY'
from pathlib import Path
import re

base = Path.home() / '.codeium' / 'windsurf' / 'code_tracker' / 'active'
if not base.exists():
    raise SystemExit(0)

paths = []
for f in base.rglob('*_mcp.json'):
    try:
        b = f.read_bytes()
    except Exception:
        continue

    for m in re.finditer(br'file:///[^\x00\s"]+', b):
        u = m.group(0).decode('utf-8', 'ignore')
        if u.startswith('file:///'):
            paths.append(u[7:])

seen = set()
for p in paths:
    if p in seen:
        continue
    seen.add(p)
    print(p)
PY
}

collect_candidate_start_dirs() {
  local candidates=()

  candidates+=("$PWD")

  if [[ -n "${SITE_PATH:-}" ]]; then
    candidates+=("$SITE_PATH")
  fi

  local p
  while IFS= read -r p; do
    [[ -n "$p" ]] && candidates+=("$p")
  done < <(get_windsurf_active_paths 2>/dev/null || true)

  printf "%s\n" "${candidates[@]}" | awk 'NF && !seen[$0]++'
}

start_dir="${PWD}"
artisan_dir=""

check_mode=0
root_arg=""
if [[ "${1:-}" == "--check" ]]; then
  check_mode=1
  shift
fi

if [[ -n "${1:-}" ]]; then
  root_arg="$1"
  shift
fi

if [[ -n "${root_arg}" ]] && [[ "${root_arg}" != "\${workspaceFolder}" ]] && [[ "${root_arg}" != "${workspaceFolder}" ]] && [[ "${root_arg}" != "\${workspaceRoot}" ]] && [[ "${root_arg}" != "${workspaceRoot}" ]]; then
  if [[ -d "${root_arg}" ]]; then
    artisan_dir="$(find_artisan_dir "${root_arg}" 2>/dev/null || true)"
  fi
fi

if [[ -z "${artisan_dir}" ]] && [[ -n "${LARAVEL_PROJECT_ROOT:-}" ]]; then
  if ! artisan_dir="$(find_artisan_dir "${LARAVEL_PROJECT_ROOT}" 2>/dev/null)"; then
    echo "laravel-boost MCP: LARAVEL_PROJECT_ROOT set but artisan not found." >&2
    echo "- LARAVEL_PROJECT_ROOT: ${LARAVEL_PROJECT_ROOT}" >&2
    exit 1
  fi
fi

if [[ -z "${artisan_dir}" ]]; then
  while IFS= read -r candidate; do
    if artisan_dir="$(find_artisan_dir "$candidate" 2>/dev/null)"; then
      break
    fi
  done < <(collect_candidate_start_dirs)
fi

if [[ -z "$artisan_dir" ]]; then
  echo "laravel-boost MCP: skipped (no Laravel project detected; artisan not found)." >&2
  echo "- starting directory: $start_dir" >&2
  if [[ -n "${SITE_PATH:-}" ]]; then
    echo "- SITE_PATH: ${SITE_PATH}" >&2
  fi
  exit 0
fi

if [[ ! -d "${artisan_dir}/vendor/laravel/boost" ]]; then
  echo "laravel-boost MCP: skipped (Boost not installed in this project)." >&2
  echo "- artisan_dir: ${artisan_dir}" >&2
  echo "Tip: run 'composer require laravel/boost --dev' in this project." >&2
  exit 0
fi

php_bin=""
if ! php_bin="$(find_php)"; then
  echo "laravel-boost MCP: php binary not found in PATH or common locations." >&2
  echo "Ensure PHP is installed and available to your IDE (Herd/Homebrew)." >&2
  exit 1
fi

if [[ "${check_mode}" == "1" ]]; then
  echo "laravel-boost MCP wrapper check" >&2
  echo "- starting directory: ${start_dir}" >&2
  if [[ -n "${root_arg}" ]]; then
    echo "- root_arg: ${root_arg}" >&2
  fi
  if [[ -n "${LARAVEL_PROJECT_ROOT:-}" ]]; then
    echo "- LARAVEL_PROJECT_ROOT: ${LARAVEL_PROJECT_ROOT}" >&2
  fi
  if [[ -n "${SITE_PATH:-}" ]]; then
    echo "- SITE_PATH: ${SITE_PATH}" >&2
  fi
  echo "- artisan_dir: ${artisan_dir}" >&2
  echo "- php_bin: ${php_bin}" >&2
  herd_bin=""
  if command -v herd >/dev/null 2>&1; then
    herd_bin="$(command -v herd)"
  fi
  if [[ -n "${herd_bin}" ]]; then
    echo "- herd_bin: ${herd_bin}" >&2
    herd_php="$(cd "${artisan_dir}" && herd which-php 2>/dev/null || true)"
    if [[ -n "${herd_php}" ]]; then
      echo "- herd_which_php: ${herd_php}" >&2
    fi
  else
    echo "- herd_bin: <not found>" >&2
  fi
  exit 0
fi

cd "$artisan_dir"
if command -v herd >/dev/null 2>&1; then
  exec herd php artisan boost:mcp
fi

exec "$php_bin" artisan boost:mcp

Add Herd MCP to Windsurf (macOS, Linux, Windows notes)

If you use Laravel Herd, you can also add Herd’s MCP server to Windsurf.

What Herd MCP does

Herd MCP provides tools around Herd’s local dev environment (sites, PHP versions, etc.).

Important OS note

macOS: Fully supported.
Windows: Fully supported.
Linux: Herd is not typically available, so you can skip this section.

Step 1: Create a Herd wrapper script

Create a file at:

macOS: ~/.codeium/herd-mcp.sh

Make it executable:

chmod +x ~/.codeium/herd-mcp.sh

Step 2: Add the `herd` server in Windsurf MCP config

Edit:

macOS: ~/.codeium/windsurf/mcp_config.json

Add (or update) this entry inside mcpServers:

{
  "mcpServers": {
    "herd": {
      "command": "bash",
      "args": [
        "/Users/<you>/.codeium/herd-mcp.sh",
        "${workspaceFolder}"
      ],
      "disabled": false,
      "env": {}
    }
  }
}

Why run it with bash?

On macOS, some security/xattr quirks can cause direct execution errors.
Running via bash <script> tends to be more reliable inside GUI apps.

Windows Herd MCP (no wrapper required)

On Windows, Herd installs its MCP PHAR under:

%USERPROFILE%\.config\herd\bin\herd-mcp.phar

You can add it directly in your MCP config (Windsurf Editor or the JetBrains plugin config file, depending on what you use):

{
  "mcpServers": {
    "herd": {
      "command": "php",
      "args": [
        "%USERPROFILE%/.config/herd/bin/herd-mcp.phar"
      ],
      "env": {
        "SITE_PATH": "YOUR-SITE-PATH"
      }
    }
  }
}

Step 3: Restart/refresh MCP servers

In Windsurf MCP settings, click Refresh (or restart Windsurf).

Step 4: Sanity check

~/.codeium/herd-mcp.sh --check

You should see:

detected project root (exported as SITE_PATH)
php binary used
Herd MCP phar path

Final macOS Herd wrapper script (multi-project safe)

Save as: ~/.codeium/herd-mcp.sh

#!/usr/bin/env bash

# A robust wrapper to start Herd MCP in Windsurf.
#
# Why this exists:
# - Windsurf may launch MCP servers from a directory that is NOT your project.
# - Herd MCP benefits from knowing the project root via SITE_PATH.
#
# What this script does:
# 1) Finds a Laravel project root by searching upwards for an `artisan` file.
# 2) Falls back to SITE_PATH if provided.
# 3) Optionally uses Windsurf trackers to guess your active workspace.
# 4) Finds a usable PHP binary (PATH first, then common locations like Herd).
# 5) Runs Herd's MCP PHAR with SITE_PATH exported.

set -euo pipefail

find_artisan_dir() {
  local dir="$1"
  while true; do
    if [[ -f "$dir/artisan" ]]; then
      printf "%s" "$dir"
      return 0
    fi

    local parent
    parent="$(dirname "$dir")"
    if [[ "$parent" == "$dir" ]]; then
      return 1
    fi
    dir="$parent"
  done
}

find_php() {
  if command -v php >/dev/null 2>&1; then
    command -v php
    return 0
  fi

  local candidates=(
    "/opt/homebrew/bin/php"
    "/usr/local/bin/php"
    "$HOME/Library/Application Support/Herd/bin/php"
    "$HOME/Library/Application Support/Herd/bin/php82"
  )

  local p
  for p in "${candidates[@]}"; do
    if [[ -x "$p" ]]; then
      printf "%s" "$p"
      return 0
    fi
  done

  return 1
}

get_windsurf_active_paths() {
  local py=""
  if [[ -x "/usr/bin/python3" ]]; then
    py="/usr/bin/python3"
  elif command -v python3 >/dev/null 2>&1; then
    py="$(command -v python3)"
  else
    return 0
  fi

  "$py" - <<'PY'
from pathlib import Path
import re

base = Path.home() / '.codeium' / 'windsurf' / 'code_tracker' / 'active'
if not base.exists():
    raise SystemExit(0)

paths = []
for f in base.rglob('*_mcp.json'):
    try:
        b = f.read_bytes()
    except Exception:
        continue

    for m in re.finditer(br'file:///[\x21-\x7E]+', b):
        u = m.group(0).decode('utf-8', 'ignore')
        if u.startswith('file:///'):
            paths.append(u[7:])

seen = set()
for p in paths:
    if p in seen:
        continue
    seen.add(p)
    print(p)
PY
}

find_herd_mcp_phar() {
  local candidates=(
    "/Applications/Herd.app/Contents/Resources/herd-mcp.phar"
  )

  local p
  for p in "${candidates[@]}"; do
    if [[ -f "$p" ]]; then
      printf "%s" "$p"
      return 0
    fi
  done

  return 1
}

start_dir="${PWD}"
project_dir=""

check_mode=0
root_arg=""
if [[ "${1:-}" == "--check" ]]; then
  check_mode=1
  shift
fi

if [[ -n "${1:-}" ]]; then
  root_arg="$1"
  shift
fi

if [[ -n "${root_arg}" ]] && [[ "${root_arg}" != "\${workspaceFolder}" ]] && [[ "${root_arg}" != "${workspaceFolder}" ]] && [[ "${root_arg}" != "\${workspaceRoot}" ]] && [[ "${root_arg}" != "${workspaceRoot}" ]]; then
  if [[ -d "${root_arg}" ]]; then
    project_dir="$(find_artisan_dir "${root_arg}" 2>/dev/null || true)"
  fi
fi

if [[ -z "${project_dir}" ]] && [[ -n "${LARAVEL_PROJECT_ROOT:-}" ]]; then
  if ! project_dir="$(find_artisan_dir "${LARAVEL_PROJECT_ROOT}" 2>/dev/null)"; then
    echo "herd MCP: LARAVEL_PROJECT_ROOT set but artisan not found." >&2
    echo "- LARAVEL_PROJECT_ROOT: ${LARAVEL_PROJECT_ROOT}" >&2
    exit 1
  fi
fi

if [[ -z "${project_dir}" ]]; then
  while IFS= read -r candidate; do
    if project_dir="$(find_artisan_dir "$candidate" 2>/dev/null)"; then
      break
    fi
  done < <(collect_candidate_start_dirs)
fi

if [[ -z "$project_dir" ]]; then
  echo "herd MCP: could not find artisan." >&2
  echo "- starting directory: $start_dir" >&2
  if [[ -n "${SITE_PATH:-}" ]]; then
    echo "- SITE_PATH: ${SITE_PATH}" >&2
  fi
  echo "Tip: Open a Laravel project folder (or set SITE_PATH to the project root) and try again." >&2
  exit 1
fi

php_bin=""
if ! php_bin="$(find_php)"; then
  echo "herd MCP: php binary not found in PATH or common locations." >&2
  exit 1
fi

herd_phar=""
if ! herd_phar="$(find_herd_mcp_phar)"; then
  echo "herd MCP: herd-mcp.phar not found." >&2
  echo "Tip: Ensure Laravel Herd is installed, or update find_herd_mcp_phar() with your Herd path." >&2
  exit 1
fi

if [[ "${check_mode}" == "1" ]]; then
  echo "herd MCP wrapper check" >&2
  echo "- starting directory: ${start_dir}" >&2
  if [[ -n "${root_arg}" ]]; then
    echo "- root_arg: ${root_arg}" >&2
  fi
  if [[ -n "${LARAVEL_PROJECT_ROOT:-}" ]]; then
    echo "- LARAVEL_PROJECT_ROOT: ${LARAVEL_PROJECT_ROOT}" >&2
  fi
  if [[ -n "${SITE_PATH:-}" ]]; then
    echo "- SITE_PATH (env): ${SITE_PATH}" >&2
  fi
  echo "- SITE_PATH (resolved): ${project_dir}" >&2
  echo "- php_bin: ${php_bin}" >&2
  echo "- herd_phar: ${herd_phar}" >&2
  exit 0
fi

export SITE_PATH="${project_dir}"
exec "$php_bin" "$herd_phar"

Combined `mcp_config.json` example (Boost + Herd)

This is how your MCP config can look with both servers configured (same schema, different file location depending on Windsurf Editor vs JetBrains plugin):

{
  "mcpServers": {
    "laravel-boost": {
      "command": "/Users/<you>/.codeium/laravel-boost-mcp.sh",
      "args": ["${workspaceFolder}"],
      "disabled": false,
      "env": {}
    },
    "herd": {
      "command": "bash",
      "args": [
        "/Users/<you>/.codeium/herd-mcp.sh",
        "${workspaceFolder}"
      ],
      "disabled": false,
      "env": {}
    }
  }
}

Windows Setup (PowerShell)

Windsurf on Windows can also launch MCP servers from an unexpected working directory. The fix is the same idea: use a wrapper.

Step 1: Create the wrapper script

Create:

C:\Users\<you>\.codeium\laravel-boost-mcp.ps1

Step 2: Configure Windsurf MCP to run the script

Edit:

C:\Users\<you>\.codeium\windsurf\mcp_config.json

Add:

{
  "mcpServers": {
    "laravel-boost": {
      "command": "powershell.exe",
      "args": [
        "-NoProfile",
        "-ExecutionPolicy",
        "Bypass",
        "-File",
        "C:\\Users\\<you>\\.codeium\\laravel-boost-mcp.ps1",
        "${workspaceFolder}"
      ]
    }
  }
}

Step 3: Restart/refresh MCP servers in Windsurf

Refresh MCP servers (or restart Windsurf).

Final Windows PowerShell wrapper script (well-commented)

Save as: C:\Users\<you>\.codeium\laravel-boost-mcp.ps1

<#
A robust wrapper to start Laravel Boost MCP in Windsurf on Windows.

Why this exists:
- Windsurf may start MCP servers from a non-project directory.
- `php artisan boost:mcp` fails if it can’t find `artisan`.

What this script does:
1) Finds a Laravel project root by walking up directories looking for `artisan`.
2) Falls back to SITE_PATH if provided.
3) Finds a usable php binary.
4) Runs `php artisan boost:mcp` inside the detected project.

Usage:
- Check mode:
  .\laravel-boost-mcp.ps1 --check
#>

param(
  [Parameter(ValueFromRemainingArguments=$true)]
  [string[]]$Args
)

function Find-ArtisanDir([string]$StartDir) {
  $dir = Resolve-Path $StartDir

  while ($true) {
    if (Test-Path (Join-Path $dir 'artisan')) {
      return $dir
    }

    $parent = Split-Path $dir -Parent
    if ($parent -eq $dir) {
      return $null
    }

    $dir = $parent
  }
}

function Find-Php() {
  # Prefer php on PATH
  $php = Get-Command php -ErrorAction SilentlyContinue
  if ($php) { return $php.Source }

  # Common candidates
  $candidates = @(
    "C:\\Program Files\\PHP\\php.exe",
    "C:\\PHP\\php.exe"
  )

  foreach ($c in $candidates) {
    if (Test-Path $c) { return $c }
  }

  return $null
}

$startDir = Get-Location
$artisanDir = $null
$checkMode = $false
$rootArg = $null

 # Support: --check [<workspaceFolder>]
 if ($Args.Count -gt 0 -and $Args[0] -eq '--check') {
   $checkMode = $true
   if ($Args.Count -gt 1) {
     $Args = $Args[1..($Args.Count - 1)]
   } else {
     $Args = @()
   }
 }

 if ($Args.Count -gt 0) {
   $rootArg = $Args[0]
 }

 # 1) If Windsurf passed the project path explicitly (via ${workspaceFolder}), use it first
 if ($rootArg -and $rootArg -ne '${workspaceFolder}' -and (Test-Path $rootArg)) {
   $artisanDir = Find-ArtisanDir $rootArg
 }

 # 2) Try from current directory
 if (-not $artisanDir) {
   $artisanDir = Find-ArtisanDir $startDir
 }

 # 3) Fallback to SITE_PATH if provided
 if (-not $artisanDir -and $env:SITE_PATH) {
   $artisanDir = Find-ArtisanDir $env:SITE_PATH
 }

if (-not $artisanDir) {
  Write-Error "laravel-boost MCP: could not find artisan. Starting directory: $startDir"
  if ($env:SITE_PATH) { Write-Error "SITE_PATH: $($env:SITE_PATH)" }
  exit 1
}

$phpBin = Find-Php
if (-not $phpBin) {
  Write-Error "laravel-boost MCP: php binary not found. Ensure PHP is installed and available in PATH."
  exit 1
}

 if ($checkMode) {
   Write-Host "laravel-boost MCP wrapper check"
   Write-Host "- starting directory: $startDir"
   if ($rootArg) { Write-Host "- root_arg: $rootArg" }
   if ($env:SITE_PATH) { Write-Host "- SITE_PATH: $($env:SITE_PATH)" }
   Write-Host "- artisan_dir: $artisanDir"
   Write-Host "- php_bin: $phpBin"
   exit 0
 }

Set-Location $artisanDir
& $phpBin artisan boost:mcp

Troubleshooting

Symptom	Likely cause	Fix
`Could not open input file: ./artisan`	MCP server started outside project root	Use the wrapper script (it finds `artisan` by walking up directories)
“Cannot initialize server” never changes	Edited the wrong MCP config file	Verify the config path; use the temporary “invalid command” test above
MCP starts, but Boost tools are missing	Boost not installed in that project	`composer require laravel/boost --dev` in the target project
`php artisan boost:mcp` fails in terminal	Laravel app can’t boot	Fix the underlying Laravel error first (env/config/extensions)
	Wrong PHP version / missing extensions	Windsurf uses PATH PHP, not project PHP
	Wrong project info returned (multi-project)	MCP server reused across projects, or wrapper guessed the wrong root
	Auto-detection doesn’t work	`python3` not available

Quick checks

Run ~/.codeium/laravel-boost-mcp.sh --check and confirm the resolved artisan_dir is the correct project.

- If you use Herd, confirm `herd which-php` matches what you expect in that directory.

Summary

Windsurf MCP servers can fail if started from the wrong working directory.
A wrapper script that finds artisan and a working php makes Boost reliable.
Configure Windsurf to run the wrapper instead of php artisan boost:mcp directly.

What this teaches us about AI tooling (meta takeaway)

This isn’t unique to Windsurf or Boost.
Any AI tool that shells out to a project-specific CLI will eventually hit the same class of issues:

The tool assumes cwd is the project root.
The tool assumes the runtime (PHP, Node, Python, etc.) matches the project.

The durable solution is the same pattern you used here: create an adaptive entrypoint that can find the project, select the right runtime, and print diagnostics when things go wrong.

If this helped, consider sharing your wrapper suggestions and or improvements back to the community.

How to Build Applications That Survive the Real World

Olusola Ojewunmi — Mon, 15 Dec 2025 09:12:11 +0000

A Practical Guide to Production-Ready Engineering (Using Laravel for Illustrative Examples)

Most applications don't fail because the code is wrong. They fail because the supporting guardrails—the unsexy, invisible, operational foundations—were never built.

I've seen it happen more times than I'd like to admit: a team ships a beautiful feature, users love it, and then—without warning—everything falls apart. Not because of a bug in the login flow, but because nobody thought about what happens when the database fills up, or when a third-party API changes its response format overnight.

"Production ready" is not an engineering badge, it's a survival strategy. It means your application can survive the chaos of the real world: traffic spikes, disk failures, malicious actors, and the inevitable 3 AM emergency.

This article is a practical checklist of the non-functional requirements that separate hobby projects from production-grade systems. While the concepts apply to any language or framework, I've included Laravel examples to show how to implement them effectively.

TL;DR: The 10 Production Essentials

✅ Logging & Error Monitoring
✅ Backups & Disaster Recovery
✅ Queue Management & Job Failures
✅ Caching Strategy
✅ Security Hygiene
✅ Encrypting Sensitive Data
✅ Environment Configuration & Secrets
✅ Monitoring & Observability
✅ Automated Testing
✅ Deployment & CI/CD

1. Logging & Error Monitoring

The Principle

Running a production application without proper logging is like flying a plane without instruments. You can't troubleshoot what you can't see, and you can't prevent what you can't detect.

Logging is your application's black box recorder. When a user says "it's broken," your logs should tell you exactly why, without you needing to reproduce it blindly.

Laravel Implementation Example

Laravel makes structured logging straightforward. You have two main approaches:

Option A: Contextual Manual Logging

Don't just log text; log context.

use Exception;
use Illuminate\Support\Facades\Log;

try {
    $payment = PaymentGateway::charge($order);
} catch (Exception $e) {
    Log::error('Payment processing failed', [
        'order_id' => $order->id,
        'amount' => $order->total,
        'error' => $e->getMessage(),
        'user_id' => auth()->id(),
    ]);

    throw $e;
}

Option B: Clean Global Error Handling (Laravel 11+)

Define global exception reporting rules in bootstrap/app.php:

// bootstrap/app.php
use Illuminate\Foundation\Configuration\Exceptions;

return Application::configure(basePath: dirname(__DIR__))
    ->withExceptions(function (Exceptions $exceptions) {
        $exceptions->report(function (PaymentFailedException $e) {
            Log::critical('Payment Failure detected', [
                'details' => $e->getMessage(),
            ]);
        });
    })
    ->create();

Pro Tip: Don't rely on logs alone. Consider:

Sentry
Honeybadger
Rollbar
Laravel Nightwatch
Laravel Pulse

2. Backups & Disaster Recovery

The Principle

Backups are not a "nice to have"—they are the difference between a recoverable mistake and a company-ending event.

An untested backup is not a backup; it is a false sense of security.

Hard drives fail. Developers delete the wrong table. Hackers encrypt data. If you cannot restore your system within one hour, you do not have a disaster recovery plan.

Laravel Implementation Example

Use spatie/laravel-backup:

// app/Console/Kernel.php
protected function schedule(Schedule $schedule)
{
    $schedule->command('backup:run')->daily()->at('01:00');
    $schedule->command('backup:monitor')->daily()->at('03:00');
}

Quarterly drill: Restore your system from scratch. If you haven't tested your restore… assume it's broken.

3. Queue Management & Job Failures

The Principle

Queues handle emails, reports, and long-running tasks. When misconfigured, they become silent saboteurs.

Common failure modes:

Workers die — jobs pile up
Third-party outage — retry storms
Slow jobs — queue starvation

Laravel Implementation Example

Use Laravel Horizon for Redis queues.

use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Facades\Notification;
use Throwable;

class ProcessOrderNotification implements ShouldQueue
{
    public $tries = 3;
    public $backoff = [60, 300, 900]; // 1m, 5m, 15m

    public function failed(Throwable $exception)
    {
        Log::error('Order notification failed permanently', [
            'order_id' => $this->order->id,
            'error' => $exception->getMessage(),
        ]);

        Notification::route('slack', env('SLACK_WEBHOOK'))
            ->notify(new JobFailedNotification($this->order, $exception));
    }
}

4. Caching Strategy

The Principle

Caching is not optional — it is a scalability prerequisite. Without it:

Databases melt
Response times degrade
Infrastructure costs explode

Laravel Implementation Example

$stats = Cache::remember('dashboard-stats', 3600, function () {
    return [
        'total_revenue' => Order::sum('total'),
        'active_users' => User::where('active', true)->count(),
    ];
});

// Invalidate when data changes
Cache::forget('dashboard-stats');

A slow system is a broken system.

5. Security Hygiene

The Principle

Security is a mindset. Most breaches come from basic oversights:

Unvalidated input
Exposed .env files
Unsafe SQL
Mass assignment mistakes

Laravel Implementation Example

// SAFE
$users = DB::select(
    'SELECT * FROM users WHERE email = :email',
    ['email' => $request->email]
);

// UNSAFE
$users = DB::select(
    "SELECT * FROM users WHERE email = '{$request->email}'"
);

6. Encrypting Sensitive Data

The Principle

Some data is so sensitive that even if your database leaks, attackers should learn nothing.

Examples:

BVN
NIN
Passport numbers
Bank account numbers

Laravel Implementation Example

class UserProfile extends Model
{
    protected $casts = [
        'bvn' => 'encrypted',
        'passport_number' => 'encrypted',
        'bank_details' => 'encrypted:array',
    ];
}

Laravel handles encryption and decryption automatically.

7. Environment Configuration & Secrets

The Principle

Leaking credentials is one of the fastest ways to destroy a business.

Never:

Commit .env
Hardcode secrets
Share production keys in Slack/WhatsApp

Laravel Implementation Example

php artisan config:cache

Enforce required variables:

use Exception;

public function boot()
{
    if (app()->environment('production')) {
        if (!env('STRIPE_SECRET') || !env('DB_PASSWORD')) {
            throw new Exception('Critical environment variables are missing!');
        }
    }
}

8. Monitoring & Observability

The Principle

Monitoring is your system's heartbeat. Without it, failures remain invisible until customers complain.

I learned this the hard way.

A Real Incident: Ignoring Alerts Has a Price

I set up daily Honeybadger health checks for our Laravel API. Every midnight, I received a "200 OK" email. It became routine — background noise.

One night at 3 AM, I woke up, saw multiple Honeybadger emails, assumed they were noise, and went back to sleep.

A couple of minutes after 8 AM, during our morning standup, the CEO joined the call and dropped a statement developers everywhere dread hearing:

"The entire app is down."

Our server had crashed hours earlier, presumably very late during the previous night. We scrambled to migrate the database and redeploy under pressure.

Only later did I re-check the ignored emails—they were warnings that the app was unreachable, not success notifications.

Two lessons carved into my memory:

Silence is not safety. Daily health checks matter—make them impossible to ignore.
Alerts require action. If an alert doesn't require action, delete it.

Laravel Implementation Example

// routes/web.php
Route::get('/health', function () {
    return Spatie\Health\Health::check();
});

Connect /health to an uptime monitor (UptimeRobot, Oh Dear).

9. Automated Testing

The Principle

Untested code is legacy code the moment you write it. Tests are not about perfection—they're about confidence.

You cannot deploy with confidence if you don't know what will break.

Common excuses (and why they're wrong):

"We don't have time" — You'll spend 10x more time debugging production
"Tests slow us down" — Manual testing is slower and less reliable
"Our code is too complex to test" — That's a design problem, not a testing problem

Laravel Implementation Example

Feature Tests (Test Critical Paths)

// tests/Feature/OrderFlowTest.php
class OrderFlowTest extends TestCase
{
    public function test_user_can_complete_checkout()
    {
        $user = User::factory()->create();
        $product = Product::factory()->create(['price' => 100]);

        $response = $this->actingAs($user)
            ->post('/orders', [
                'product_id' => $product->id,
                'quantity' => 2,
            ]);

        $response->assertStatus(201);
        $this->assertDatabaseHas('orders', [
            'user_id' => $user->id,
            'total' => 200,
        ]);
    }

    public function test_checkout_fails_with_insufficient_stock()
    {
        $product = Product::factory()->create(['stock' => 1]);

        $response = $this->actingAs(User::factory()->create())
            ->post('/orders', [
                'product_id' => $product->id,
                'quantity' => 5,
            ]);

        $response->assertStatus(422);
        $response->assertJsonValidationErrors('quantity');
    }
}

What to Test (Priority Order)

Critical business flows — Checkout, payments, authentication
Data integrity — Money calculations, user permissions, data validation
Third-party integrations — API failures, timeouts, fallback behavior
Edge cases — Empty carts, expired sessions, invalid input

Run Tests in CI/CD

# GitHub Actions
- name: Run Tests
  run: php artisan test --parallel

The Golden Rule: If it breaks in production, write a test for it.

10. Deployment & CI/CD

The Principle

Manual deployments fail. CI/CD ensures safe, predictable, repeatable releases.

If your deployment involves SSH + git pull, you're one command away from an outage.

Laravel Implementation Example

# GitHub Actions Snippet
- name: Deploy to Production
  run: |
    ssh user@server 'cd /var/www/app && git pull origin main'
    ssh user@server 'cd /var/www/app && composer install --no-dev'
    ssh user@server 'cd /var/www/app && php artisan migrate --force'
    ssh user@server 'cd /var/www/app && php artisan config:cache'
    ssh user@server 'cd /var/www/app && php artisan queue:restart'

Summary: Building for the Real World

Production readiness isn't about adding complexity—it's about adding reliability. Every item on this checklist exists because someone, somewhere, learned a painful lesson the hard way.

Modern frameworks like Laravel have made production readiness easier than ever.

With a few packages and the right discipline, you can build systems that are:

Resilient
Observable
Secure
Maintainable
Professional

A Practical Adoption Path

Week 1: Logging & Monitoring
Week 2: Backups
Week 3: Queue Management
Week 4: Security & Encryption
Week 5: Health Checks
Week 6: Automated Testing
Week 7: CI/CD Pipeline

The Real Cost of Neglect

No backups — permanent data loss
No monitoring — silent failures
No encryption — possible breach of confidential user data and lawsuits
No queue handling — stuck orders
No testing — production bugs and regressions
No CI/CD — broken deployments

The time you invest in production readiness pays dividends every single day your application runs. It's the difference between a side project and a sustainable business. Between a stressful on-call rotation and peaceful weekends. Between "it works" and "it works reliably."

Your Application Deserves Better

If you're building something that matters—something people depend on, something that generates revenue, something that stores user data—you owe it to yourself and your users to build it right.

Start today. Your future self will thank you.

💬 Discussion Questions:

Which of these 10 items do you struggle with most?
Have you had a production incident that taught you a hard lesson?
What's your #1 production-readiness tip?

Drop your thoughts in the comments—I read and respond to every one.

Found this helpful? Follow me for more practical guides on building production-grade applications. Have questions about implementing any of these practices? Ask below!

AI-Assisted Engineering: A Senior Developer’s Framework for Speed, Quality, and Sound Technical Judgment - Part 2

Olusola Ojewunmi — Mon, 01 Dec 2025 07:36:45 +0000

Executive Overview
In Part 1, we covered the “thinking layer”— how AI improves architectural reasoning. Now we shift to the execution layer: how AI improves daily coding, testing, refactoring, debugging, and delivery.

Over the last few months of production work, this workflow consistently delivered:

✔️ ~70% time savings on code scaffolding
✔️ ~78% faster test generation
✔️ ~67% faster debugging cycles
✔️ More consistent Laravel architecture

This is the practical playbook behind those numbers.

1. AI-Accelerated Code Scaffolding

AI excels at generating structured, consistent scaffolds—if you provide a strong, detailed and precise specification.

Service Classes (83% Faster)

Traditional: 60–75 minutes
AI-assisted: 10–15 minutes

My Prompt Strategy:
I use Windsurf combined with Laravel Boost (to enforce modern Laravel patterns) and provide a prompt like this:

"Create a SeasonalDiscountService that retrieves active discount rules from config/discounts.php.

Requirements:

Methods: getDiscountForCategory(string $category), getActiveCampaigns(), calculateImpact().

Use dependency injection and full type hints.

Handle expired campaigns gracefully with defaults.

Constraint: Return a strictly typed DiscountDTO, never a raw array."

The Result: A production-ready service class with proper namespaces, docblocks, and error handling. I step in only to validate the business logic.

2. AI-Enhanced Refactoring

Refactoring legacy code is safer with AI — but requires synchronization.

The “Explain → Verify → Execute” Loop

When dealing with complex, "spaghetti" legacy logic, I never jump straight to refactoring. I use a synchronization step first:

Explain: I highlight the complex method in Windsurf or sometimes the whole flow of execution of the feature, and ask: > "Explain the logic of the method or feature flow step-by-step."
Verify & Correct: I review the AI's explanation. If it misinterprets a variable or edge case, or omits some part of the logic, I correct it explicitly in the chat.
Execute: Only once I have confirmed the AI's mental model matches the existing implementation, do I issue the refactor command, while adding constraints where necessary.

The "Reverse Code Review"

Sometimes I flip the script. I will manually refactor the AI's code (or existing legacy code) to apply a specific design pattern or personal preference, and then I ask the AI to review my work.

Prompt:
"I have refactored your logic to use the match expression instead of the switch statement. Review my changes for regressions, missed edge cases, or logic errors. Then, merge the best parts of my refactor with your original error handling."

The Result: The AI acts as a safety net. It often catches subtle bugs I introduced (like missing a null check during my refactor) and upgrades the final code by combining my architectural structure with its robust boilerplate.

The "Hardcoded to Config" Move

Prompt:
"Extract all hardcoded rate limits, API timeouts, and retry thresholds in this controller into config/discounts.php. Make them environment-variable configurable."

Real stats: I recently moved 20+ hardcoded values in 20 minutes. A task that usually takes around 1 hour of tedious copy-pasting, which is also prone to errors of omission sometimes.

3. Testing: A Force Multiplier

Testing is usually the first thing to slip when deadlines loom. AI reverses that trend when utilised properly.

Traditional: 120 minutes
AI-assisted: 25 minutes
Time saved: ~79%

Generating the Suite

I don't write tests from scratch anymore. I ask AI to generate the skeleton and the standard cases:

"Create unit tests for LoyaltyPointsCalculator covering:

Gold Tier: Earns 2x points on all orders.

Silver Tier: Earns 1.5x points only on weekends (mock the date).

Standard Tier: Earns 1x points.

Edge Case: Orders over $1,000 get a flat 500-point bonus regardless of tier."

The "Blind Spot" Check

"What edge cases am I missing for this points calculation?"
AI Result: "You missed: Refunded orders (negative points), zero-dollar orders, and floating point precision errors on multiplier math."

Running Tests With AI

I also use AI to run my test suite.

It picks up failed test cases automatically.
It proceeds to investigate the cause of the failures and recommends multiple solutions.
After my review and decision, it implements the fixes and reruns the suite.
It automatically runs the test suite after significant refactoring to ensure no regressions.
It can also suggest additional test cases for improved test coverage for the codebase.

4. Documentation: The Silent Productivity Killer

Documentation is the task every engineer hates, but every team needs. AI turns this from a chore into a breeze.

AI allows me to effectively document code and applications, making handovers and onboarding new devs effortless compared to manual effort.

My Documentation Workflow:

Code Comments: "Add strict DocBlocks to this service class explaining the business rules for the discount calculation."
Onboarding: "Read this repository and generate a CONTRIBUTING.md file that explains how to set up the environment, run migrations, and seed the database."
API Docs: "Generate Swagger/OpenAPI definitions for these 3 new endpoints."

Result: I consolidated 31 fragmented documentation files into 1 comprehensive README in 30 minutes, saving ~2 hours of manual work.

5. Infrastructure & Deployment: The DevOps Accelerator

I am a Backend Engineer, not a full-time DevOps specialist. AI helps bridge that gap by generating, explaining, and debugging deployment scripts and also build errors that I would otherwise spend hours Googling.

Writing & Learning

Instead of copying opaque Bash scripts from StackOverflow, I now use AI to build and teach me the infrastructure.

The Prompt:

"Write a GitHub Actions workflow to deploy this Laravel app to a DigitalOcean Droplet via SSH.
Requirements:

Run tests before deploying.

Use rsync for zero-downtime file transfer.

Reload PHP-FPM after transfer.

Explain: Add comments explaining what every flag in the rsync command actually does."

The Result:

A working CI/CD pipeline.
A clear explanation of why we use rsync -avz (archive mode, verbose, compressed).
I learn while I build, rather than just copy-pasting.

I apply this same logic to Dockerfiles (optimising layers), Nginx configs, and Makefiles.

6. Debugging: Ranked Root Cause Analysis

Stop staring at stack traces. Use AI to structure your diagnostic thinking.

My Debugging Workflow (15-20 mins):

Input: Error message + Code Context + Recent Changes.
Prompt: > "Based on this error, provide 3 likely root causes ranked by probability. For each, suggest a verification step."
Action: I test the "70% likely" cause first.

7. The Data: Real World Time Savings

Let's look at the actual numbers from 12 months of production work.

Task Type	Traditional Time	With AI	Time Saved
Service Class	60 min	10 min	83%
Test Suite	120 min	25 min	79%
Documentation	120 min	30 min	75%
Debugging	60 min	20 min	67%
Refactoring	90 min	30 min	67%

The Takeaway: This results in a 25-30% net productivity gain per engineer. For a team of 5, that’s the equivalent of adding a 6th engineer without the headcount.

8. My Multi-AI Prompt Strategy

The secret to high-quality output is a two-step process:

The "Thinking" Step (ChatGPT/Gemini): I dump my messy requirements here. "I need to implement a new rewards tier..." I ask the AI to structure this into a technical spec.
The "Execution" Step (Windsurf + Laravel Boost): I feed the refined, structured spec into Windsurf. It executes with full codebase awareness and Laravel-specific context.

The Rule: Invest 5 minutes in prompt design to save 30 minutes of cleanup.

The "No Assumptions" Clause

I always explicitly instruct Windsurf:

"Do not make assumptions. If any part of this requirement is ambiguous or open to interpretation, ask clarifying questions before you generate any code."

This simple instruction prevents the AI from confidently guessing wrong and forces a clarification loop that saves hours of rewriting later.

The Seniority Gap: Asking for Features vs. Asking for Architecture

One of the clearest indicators of seniority isn't just the code you write—it's the prompt you write.

The "Junior" Prompt:

"Build a registration form with first name, last name, email, phone number, and address."

The Result: Happy-path code. It works, but it’s fragile. It likely misses validation and lacks atomicity.

The "Senior" Prompt:

"Create a user registration endpoint.
Technical Constraints:

Validation: Enforce strict typing. DNS/RFC validation on production.

Data Integrity: Wrap the user creation and profile setup in a database transaction to ensure efficient rollback.

Performance: Email uniqueness check via optimized indexed query.

Security: Sanitise inputs to prevent XSS and mass-assignment."

The Result: Enterprise-grade code that is secure, atomic, and environment-aware.

9. Guardrails: Where I Draw the Line

AI speeds up execution, but I own the quality. Here is my safety checklist:

Security: I never blindly trust AI with auth logic or input validation.
N+1 Queries: AI loves to write inefficient loops. I always review database interactions.
Business Logic: AI can write the code, but only I know if the Loyalty logic matches the Marketing team's request.
Secrets: Never paste API keys or real customer data into the prompt.

Closing Thoughts: The Future of Hybrid Engineering

Teams that master structured AI workflows will ship faster, maintain higher quality, and onboard engineers quickly. Hybrid AI-assisted engineering isn’t the future—it’s the present.

Meta Note: In true "practice what you preach" fashion, this article’s structure was refined using the same AI-assisted workflow described above: structured prompts, multi-AI refinement, and final human review.

(Now, if only I could prompt the AI to explain to my PM why this "5-minute fix" will actually take three days... ☕)

Which part of your engineering workflow would you delegate to AI first — and what’s stopping you from doing it today?

About the Author
Senior Backend Engineer specialising in Laravel, distributed systems, and backend architecture. Focused on scalable systems and hybrid AI-assisted engineering workflows.

Read Part 1: Decision-Making, Architecture, and Problem Solving

AI-Assisted Engineering: A Senior Developer’s Framework for Speed, Quality, and Sound Technical Judgment

Olusola Ojewunmi — Mon, 24 Nov 2025 06:57:50 +0000

Part 1: Decision-Making, Architecture, and Problem Solving

Executive Summary
Modern software engineering has changed forever. The question isn’t whether to use AI—it’s how intentionally you use it while preserving engineering judgment.

As a senior backend engineer working with Laravel and distributed systems, I’ve spent the past couple of months developing a structured AI-assisted workflow. The outcome?

✔️ 70% faster execution on delegated tasks
✔️ Zero compromise on architectural or business logic integrity
✔️ Cleaner design decisions backed by structured reasoning

This framework is not about replacing human engineers. It’s about establishing a hybrid model where AI accelerates mechanical execution, and engineers lead architecture, decision-making, and correctness.

I Learned This the Hard Way

I wasn’t always this disciplined. When I first started using AI, I treated it like a magic wand. I pushed code to production blindly—without rigorous verification.

I paid dearly for it.
I introduced expensive N+1 queries that choked the DB, pushed logic that defied our business rules, and deployed raw, unverified code that caused regression. I learned that blind trust is expensive. Gradually, I refined my approach from "AI-generated" to "AI-assisted", moving from a passive user to an active architect.

This article explains the thinking layer of that refined workflow.

My Multi-AI Workflow Philosophy

I rely on a three-tier system:

1. The Thinking Layer: ChatGPT + Google Gemini

These tools are where my ideas take shape. I use them to:

Clarify requirements
Structure technical thoughts
Stress-test assumptions
Explore multiple architectural approaches
Generate high-signal prompts for execution

The "Prompt Engineering" Gap:
This is often where the gap between junior and senior engineers becomes visible.

A junior engineer might skip this layer and ask the IDE directly: "Build a registration form." The AI will guess the requirements, usually resulting in fragile, "happy-path" code.
A senior engineer uses this Thinking Layer to generate a specification first. I ask ChatGPT: "Draft the strict technical requirements for a production-grade registration system, considering security, atomicity, and validation."

The output of this layer: ➡️ A clean, structured, context-rich prompt.

2. The Execution Layer: Windsurf (Cascade) + Laravel Boost

Once my thinking is refined, I move to Windsurf (or Cursor/Copilot).

Windsurf: Provides full codebase awareness, stateful context, and implementation precision.
Laravel Boost: I pair this with specific prompts to enforce modern Laravel patterns, respect service container conventions, and produce clean DTOs.

This pairing ensures speed AND correctness.

3. The Review Layer: Copilot + Gemini

These tools are used after the implementation. I use them as a "second pair of eyes" to:

Review PRs: Highlight potentially problematic changes on varying levels of complexity.
Simulate: Run mental simulations of how the implementation handles race conditions or high load.
Refine: Suggest logical improvements or optimizations I might have missed.
Automate: Generate suitable, descriptive commit messages based on staged files.

This layer acts as my quality assurance gate before I even push the code.

(And yes—I still write “please” and “thank you” in my prompts. You know… just in case the AI uprising ever happens 😄.)

How AI Enhances Architectural Decision-Making

Good architecture requires exploring multiple solutions, assessing trade-offs, and understanding constraints. Here is my 6-step architectural workflow.

Step 1: Present Requirements with Context

The quality of the architectural output is capped by the quality of your context.

The "Junior" Prompt:

"How should I build a pricing system?"

Result: Generic, brittle CRUD advice.

The "Senior" Prompt:

"I need to redesign our pricing system.
Constraints:

Current State: Database-stored logic that is brittle.

Requirements: Role-based pricing, configurable thresholds.

Load: 10K+ daily orders; read-heavy.

Stack: Team experienced with Laravel Service patterns."

Result: Robust patterns (Pipeline/Strategy) tailored to the stack.

Step 2: Request Multiple Architectural Options

I always ask:

"Give me 3 distinct architectural approaches."
AI usually proposes:

Pipeline architecture
Strategy pattern
Rules engine

This expands the solution space immediately.

Step 3: Ask for a Trade-Off Matrix

Next, I request a comparison.

"Compare options by testability, extensibility, performance, maintainability, and migration complexity."

This gives me a clearer, multi-dimensional view.

Step 4: Validate Against Real Constraints

AI doesn’t know your team’s strengths or your deployment risks. That’s where senior judgment comes in. I evaluate:

Can my team maintain this?
Does this introduce fragile dependencies?
Is the operational overhead worth it?

Step 5: Break Into Phases

Once I choose an approach:

"Produce a 5-phase implementation plan. Each phase must be independently deployable and testable."

This removes uncertainty and helps me review each phase independently, allowing me to detect architectural drift early.

Step 6: Make the Final Decision

AI provides insights, not authority. I decide—and I am accountable.

Complex Problem-Solving: AI as a Debugging Partner

Debugging is where AI shines—not because it “fixes bugs” magically, but because it structures reasoning. My debugging loop now takes 15–20 minutes, not 60–90.

The Ranked Diagnostic Workflow

Provide Context: I paste the error, stack trace, relevant code, and recent changes.
AI Analysis: Based on this error, provide 3 likely root causes ranked by probability. For each, suggest a verification step.
Execution: I test the highest-probability cause (e.g., the 70% likely one) first.
Validation: I apply the fix and verify.

This prioritization prevents rabbit holes and wasted time.

My Acceptance / Rejection Framework

Not all AI output is equal. My mental model for code review:

✅ Immediate Acceptance (Low Risk)

Boilerplate
DTO scaffolding
Documentation structure
Test class skeletons

⚠️ Acceptance After Review (Medium Risk)

Service method logic
Controllers
Refactoring suggestions
Review for: Business logic correctness and performance.

❌ Rejection or Heavy Revision (High Risk)

Complex domain logic
Authorization/Authentication
Security-sensitive code
Database migrations

Stress-Testing Ideas Before Implementation

One of AI’s hidden superpowers is pre-execution simulation.

"What can go wrong?"

"What failure modes should I expect with this payment design? Consider race conditions and timeouts."

"Find the Blind Spots"

"What edge cases am I missing for this coordinate validation?"
AI Result: Invalid formats, extreme ranges, null/empty cases, injection attempts.

Closing Thoughts: The Hybrid Engineer

The engineers who excel in the next decade won’t be those who avoid AI, nor those who blindly trust it. It will be engineers who combine clarity, system thinking, and human judgment with AI-assisted speed, structure, and exploration.

AI accelerates execution. You drive decisions.

About the Author
Senior Backend Engineer specializing in Laravel, distributed systems, and backend architecture. Focused on scalable systems, clean architecture, and AI-augmented workflows.

🚀 Part 2 Coming Up Next: Code Generation, Refactoring, Testing & Delivery Automation.

DEV Community: Olusola Ojewunmi

The Case Against Rewrites: How I Evolved a 5-Year-Old Backend Codebase (And Why You Probably Shouldn’t Rewrite Yours Either)

1. Most Legacy Systems Don't Fail Because of Bad Code. They Fail Because of Emotional Decisions.

2. What a 5-Year Backend Actually Looks Like

3. The Rewrite Temptation

4. The Microservices Attempt That Stalled

5. The Incremental Modernisation Framework

Step 1: System Mapping Before Touching Code

Step 2: Behaviour Locking

Step 3: Domain Isolation

Step 4: Database Evolution Strategy

Step 5: Opportunistic Refactoring

Step 6: Versioned Endpoints Strategy

6. Using AI as a Code Archaeologist

7. What the Git History Revealed

8. Avoiding Vendor Lock-In

9. Measurable Improvements

10. Hard Lessons

11. Redefining "Modern"

12. Discussion

How to Vibe Code Your MVP in Weeks Using AI-Assisted Development

The Call That Started It All

What You'll Learn

Reality Check: What Vibe Coding Is NOT

Prerequisites

Step 1: Architect Before You Code

What I Did

Why This Works

Step 2: Set Up Your AI-Assisted Environment

My Transition

The Stack That Worked

MCP Configuration Note

Step 3: Iterative Development (The Vibe Coding Loop)

The Core Workflow

Non-Negotiable: The Implementation Plan

The Key Mindset Shift

Practical Tips from the Trenches

Step 4: Collaboration Patterns That Scale

How We Worked

Responsibility Partitioning

The Feedback Loop

Step 5: Maintenance (Where Reality Asserts Itself)

What to Expect Post-Launch

How AI Helps (and Doesn't)

A Real Refactoring Story: When Your Data Model Fights Back

Time Investment Benchmarks

Key Lessons for Your MVP

1. Speed Is a Form of Clarity

2. AI Accelerates Momentum, Not Accountability

3. Real Users Reveal Truths No Prompt Can Anticipate

4. Collaboration Eclipses Solo Brilliance

Quick Reference: The Vibe Coding Workflow

Technical Stack Reference

Final Thoughts: You Are Out of Excuses

Further Reading

What Building a Simple E-commerce Cart Taught Me About Senior Laravel Engineering

🎯 Context

🛠️ Tech Stack

🎯 The Problems That Matter

1. ⚡ Concurrency & Row-Level Locking

The Problem: Race Conditions

Visual Breakdown of the Race Condition

The Solution: Pessimistic Locking

Full Checkout Implementation

2. 🛒 Handling Partial Failure Gracefully

Implementation

Frontend Handling

3. 📸 Snapshotting Data for Historical Accuracy

4. 📧 Background Jobs & Avoiding Notification Spam

5. 📊 Daily Sales Reports & Query Optimization

6. 🏗️ Separation of Concerns

💭 What I Learned About Volt

🎓 Reflections

🎯 Final Thoughts

🔗 Links & Resources

Fixing Laravel Boost in Windsurf: A Global MCP Setup Guide

Fixing Laravel Boost in Windsurf: A Global MCP Setup Guide

The target architecture (what we’re building)

Prerequisites

Install Boost in each Laravel project (required)

Step 2: Add `laravel-boost` to Windsurf MCP config

Step 2: Add the `herd` server in Windsurf MCP config

Combined `mcp_config.json` example (Boost + Herd)

- If you use Herd, confirm `herd which-php` matches what you expect in that directory.