Business change and projects end, but how do you wrap up and sunset an app, especially one you've worked on for years?

In the latest episode of the No Compromises podcast, we share a practical checklist for winding down an app when the whole company is closing. From documenting services and dependencies to deciding what data to retain, we cover backups, credentials, and why deleting local copies matters for security and sanity.

• (00:00) - Sunsetting a company vs project handoff
• (02:15) - First goals: stop charges, purge data
• (03:45) - Document before shutting anything off
• (04:15) - Use README/PRODUCTION.md and password manager
• (05:45) - Decide on retaining code, DB, uploads
• (07:15) - Hunt secrets in .gitignore and dotfiles
• (09:15) - Delete local containers and repos by default
• (11:30) - Silly bit

What do you do when you need to create some data but you haven't built out the UI for that data yet? A seeder is a great approach, but is it always the right one?

In the latest episode of the No Compromises podcast, we dive into a real project where starting with the most complex feature made test data management painful. Instead of exploding the complexity of our seeders, we built a minimal UI to manage test data.

We also talk about some other unexpected benefits, and talk through the trade-offs and why detours like this should feel uncomfortable (and be tightly scoped).

• (00:00) - Starting deep exposes messy user permutations
• (02:45) - Seeder explosion vs. a minimal UI
• (03:45) - Reframing the “detour” after using it
• (05:30) - Why the mini-UI helped: faster iteration, fewer seed resets
• (07:45) - Dogfooding + tester debugging benefits
• (08:00) - Guardrails: detours should feel uneasy and stay tight
• (09:00) - Silly bit

Blade gives you two big levers for keeping views maintainable: @include and Blade components.
When should you use one versus the other?
Does it matter?

In the latest episode of the No Compromises podcast, we lay out a clear heuristic for when to extract markup for organization (includes) versus when to encapsulate and reuse with controlled scope (components).

We also touch on scope pitfalls, “passing for documentation,” and why performance worries usually lie elsewhere.

Sign up for the free Mastering Laravel newsletter. The highest value-to-time ratio you will find.

Aaron admits he used to wrap every query in plain old if-statements—until Laravel’s when()/unless() helpers (and arrow functions) won him over. He and Joel compare their journeys, debate readability trade-offs, and share guidelines for deciding which style to use. Along the way they discuss false assumptions, evolving “code grammar,” and how tools such as Rector can automate the switch.

• (00:00) - Intro – refining long-held opinions
• (00:45) - Aaron’s original “query-then-if” pattern
• (01:45) - Why when() first felt clumsy (closures, scopes, extra params)
• (03:45) - Arrow functions & smaller conditions make when() nicer
• (05:00) - Joel’s lingering objection: avoiding unless() for readability
• (06:45) - Seeing the same helper everywhere changes minds
• (08:30) - Takeaways – keep revisiting old habits as Laravel evolves
• (09:30) - Silly bit

Joel and Aaron compare two very different ways to tackle pull-requests—reviewing them commit-by-commit or scanning the whole thing at once. They dig into when each approach shines, how “atomic” commits can help (or hurt) reviewers, and why understanding how your teammate’s brain works is a super-power. Along the way they share practical tips for leaving yourself notes, spotting hidden changes, and keeping large refactors under control.

• (00:00) - The “gift” of a pull request and the pain of huge PRs
• (02:30) - Joel’s commit-by-commit strategy and where it helps
• (04:50) - Aaron’s Tetris-style holistic review (and leaving self-notes)
• (07:45) - When atomic commits backfire and trust becomes a factor
• (08:45) - Silly bit

Joel and Aaron explain why every project should start in the client’s own GitHub organization—even when the client has never heard of Git. They share scripts, onboarding tips, and war-stories that show how small setup shortcuts turn into big headaches later. You’ll learn a repeatable way to protect both your reputation and your client’s code base.

• (00:00) - Intro & episode setup
• (01:15) - Create the repo in their org
• (02:15) - Quick hack versus right process
• (03:30) - Project-setup technical-debt risks
• (05:00) - Declaring non-negotiables to clients
• (06:45) - Docs that survive “hit-by-bus” events
• (08:00) - Solo-dev reputation boosters
• (08:45) - Silly bit

Joel and Aaron unpack how they use code-coverage numbers as a starting signal rather than a finish line. They discuss realistic thresholds, choosing the right tool for each test layer, and why coverage metrics can double as negotiation leverage inside big organizations. Listen in for practical ways to decide what to test—and when to stop.

• (00:00) - Testing passion vs. shipping work
• (01:00) - Coverage tells you what’s missing
• (03:45) - Picking a baseline metric that grows
• (06:15) - Draw the line between logic and UI tests
• (12:45) - Silly bit

Joel and Aaron unpack a recent client project where the only spec was “make these two systems talk.” They share how console-level prototypes helped them clarify data mapping, test tricky scenarios, and keep the client looped in without over-building a UI. If you’ve ever had to code first and document later, this one’s for you.

• (00:00) - Bridging two APIs with minimal specs
• (03:30) - Choosing an exploratory workflow over full UI
• (06:00) - Console closures for quick, testable steps
• (09:15) - Hand-off strategy: letting others poke the prototype
• (11:45) - Silly bit