Kayleigh Whitehurst
I'm a Laravel developer who spends most of my time on the backend, but I believe great software starts with understanding the whole picture.
Over the past decade, I've been building web applications — designing APIs, modelling data, and crafting systems that hold up under real-world load. I found Laravel around version 4 and it clicked immediately: opinionated in all the right places, clear about what it was for. It's become a long-term home, not just because of the framework itself, but because of the kind of thinking it encourages — structure first, elegance later.
I'm comfortable on the frontend too (Livewire, Alpine.js, Tailwind), and I lean into that when it makes sense. But my instinct is always to start from the data layer and work outward. Good interfaces are built on good foundations.
What I believe
Code is communication
The hardest part of most projects isn't writing the logic — it's making the structure legible to whoever reads it next (usually future-me). I've learned that good naming and clear intent matter more than clever patterns, every time. In a Laravel codebase especially, where conventions do so much heavy lifting, fighting them costs more than you'd expect.
Build what's needed, not what might be
Over-engineering is easy. Under-engineering is harder because it requires honest assessment of what your system actually does today. I'd rather build something simple that works than something ambitious that doesn't need to exist yet. Laravel gives you a lot of power out of the box — I've found that most projects don't need more than what's already there.
The data model is the most important decision
Most architectural problems aren't really architectural — they're scope problems that got modelled into the database. I slow down at the data layer and ask "what is this actually for?" before reaching for solutions. Eloquent makes it tempting to push logic into models or build relationships you don't need yet. The best Laravel apps I've worked on all started with a data model that was honest about what each piece of data actually represents.
Who I work best with
Product teams who want someone experienced to help them move faster — whether that's untangling legacy code, shipping features cleanly, or just getting more reliable from their existing Laravel application. Founders who understand that experienced eyes on a codebase are worth the slower pace, and who value getting it right over getting it done fast.
Engineering leads who want a collaborator, not just another pair of hands. If you need someone to own architecture decisions, ask hard questions about approach, and push back when a decision will hurt you later — that's the kind of work I do well. If you're looking for someone to quietly execute a stack of tickets without comment, we probably won't be a good fit.
The toolkit
Backend
- Laravel 13 & the broader ecosystem
- PHP 8.5 — typed, modern, opinionated
- API design (REST, GraphQL)
- Queue systems, background jobs, event sourcing
- MySQL, PostgreSQL, SQLite
- Test-driven development (Pest 5, PHPUnit 13)
Frontend
- Livewire 4 for reactive Laravel UI
- Tailwind CSS v4
- Flux UI Pro 2 components
- Alpine.js for lightweight interactivity
- Accessible, responsive by default
Want to work together?
If what you've read sounds like a fit, I'd genuinely like to hear what you're building.