What’s a Framework, Anyway?
Right out of the gate I want to share that this post gets a bit technical, so here’s a layperson’s intro: A framework is the foundation we build your custom web application on. Think of it like the frame of a house, it provides the skeletal structure and components that save us from reinventing the wheel on every build. Picking the right framework can make all the difference in how stable and secure the final product will be, and how easy it will be to maintain long after launch.
For those of you that just want the gist please enjoy this TLDR:
After over two decades of web development and trying everything from building our own framework to exploring every shiny new option, we’ve landed on Laravel as our go-to choice for custom web application development. Why? Simply put, it gives us the perfect balance of structure and flexibility, has outstanding documentation and community support, and most importantly, it lets us build enterprise-quality applications that last ages without needing costly rewrites. For our clients, this means faster development, lower long-term costs, and sites that stand the test of time.
The Long Journey
For those of you still with me, let’s dig deeper into the decades-long journey that led us to Laravel.
For a quarter century, we’ve been building for the web. For at least twenty of those years, PHP has been our language of choice. We’ve watched it evolve from a scrappy scripting language into a mature, object-oriented powerhouse. Along the way, we’ve tried numerous PHP-based frameworks, some big, some small, and even built our own. And before you ask, yes, of course we also jumped on the JavaScript framework bandwagons as they rolled through town (e.g. Angular, Backbone, and React), curious to see where they might take us.
Ultimately, for this team, we’ve found that nothing beats the long-term maintainability, developer accessibility, and robustness of a solid open-source PHP framework. We still use JavaScript frameworks here and there, but primarily for frontend interactivity rather than the unifying structure of our builds.
All of this is to say that the decision to use Laravel didn’t happen overnight. It has been the culmination of decades of experience, experimentation, and more than a few hard-learned lessons about what works, and more importantly, what doesn’t.
The Spaghetti Code Era
In the beginning, there was chaos. Though they were simpler times, PHP development felt more like the wild west, especially compared to more structured languages like Java or C#.
We started building with PHP back when the language barely knew what objects were. Almost everything was procedural: A tangle of includes, global variables, and sometimes even database logic mixed directly into markup. If you’ve been in this industry long enough, you might know what we’re talking about. Here’s a classic real-world example from that era:
<?
/* Render region info page */
$intRegionID = $_GET['regionid'];
$thisPage = array('regionid' => $intRegionID, 'type' => 'regioninfo');
include($_SERVER['DOCUMENT_ROOT'] . "/include/header.php");
include($_SERVER['DOCUMENT_ROOT'] . "/include/nav.php");
if($intRegionID != "") {
$db->Select("select med_desc, region_text from "
. " lkp_regions where id='"
. $db->custom_escape_string($intRegionID) . "'");
?>
<div id="banner-wrapper">
<div id="banner">
<h2>Region: <? echo $db->RecordSet['med_desc']?></h2>
</div>
</div>
<div id="content">
<? echo $db->RecordSet['region_text']?>
</div>
<?
}
else {
$gbls = new Globals();
$gbls->GoBack(4);
}
include($_SERVER['DOCUMENT_ROOT'] . "/include/footer.php");
?>Sure, it got the job done, but it created massive headaches as codebases grew. Maintenance? Modularity? Consistency across projects? All very lacking. Still, we managed to ship fairly sophisticated projects. And we learned; we kept our eyes open for better ways to build.
The Symfony Revelation
When we discovered Symfony, it felt like someone had finally turned on the lights. Here was a framework with opinions, and we mean that in the best way possible. When a framework has strong opinions, it leaves less room for ambiguity and inconsistency. Symfony’s opinionated architecture gave us the guardrails our previous projects so badly needed. It provided development patterns we could easily replicate across projects, making our codebases more traversable and orders of magnitude easier to maintain.
For the first time, we had a framework that actively elevated our capabilities. Developers new to a project could get up to speed quickly and immediately understand its structure. Context-shifting to different projects, an unavoidable reality of agency life, no longer left us completely disoriented. Symfony had shown us what a well-architected framework could do. By wielding it, we were able to build increasingly more complex applications with a confidence we hadn’t felt before.
When Symfony 2 Missed the Mark
Then Symfony 2 arrived.
Don’t get me wrong, Symfony 2 introduced architectural improvements and features that would benefit the PHP ecosystem for years to come, but for our team and our clients’ needs, it felt like a huge step backward. The framework had shifted from opinionated cohesion to a buffet of decoupled components. Many of those individual components were great (YAML became popular during this era), but the overall build experience suffered for it. While the new flexibility might’ve appealed to some, we found it had a largely negative impact on long-term maintainability across multiple projects.
More critically, Symfony 2 was much more difficult to learn, train, and use. The onboarding time for developers increased dramatically. The tidiness we’d valued in Symfony 1, the very thing that made our codebases so clean, had evaporated. Worse still, the upgrade path between the two versions was basically nonexistent, requiring an entire rewrite. I remember worrying at the time that if we put in the work to upgrade, we’d end up in the same boat a short few years later.
It was clear that we needed to go in a new direction.
Building Our Own Minimal Framework
In 2010, we started an experimental side project called ScratchMVC. By 2011, we’d refined it enough to release officially as Dinkly, a nod to Peter Dinklage and his portrayal of Tyrion Lannister on Game of Thrones. The name reflected our philosophy: small but mighty.
Dinkly was everything we’d loved about Symfony 1, distilled down to its essence. It was minimal but extremely extensible. Opinionated but not restrictive. Easy to pick up, lightweight, and blazingly fast. For years, we used it alongside WordPress and SilverStripe, depending on project requirements.
We were proud of Dinkly. It solved our problems. But by the late 2010s, we were hitting its undeniable limitations.
Modern web applications were evolving rapidly. Features that had become standard in other frameworks (sophisticated queue systems, smooth authentication flows, advanced caching strategies, etc.) were absent in Dinkly, often requiring significant custom development. The flexibility and extensibility we’d built into Dinkly became a double-edged sword. Sure, we spent less time “fighting the framework” and more time building, but that time investment had started to swell. And here’s the thing about maintaining your own framework: you’re competing against frameworks with communities of thousands of developers. Our small team, no matter how talented, couldn’t keep pace. It was like flying an airplane while adding new features to it mid-flight.
We needed to find Dinkly’s grown-up analog.
Enter Laravel
After discovering Laravel a few years before, and building a number of exploratory prototypes with it, we officially adopted it in 2018. It didn’t take long to recognize we’d stumbled on to something special.
Laravel provided exactly the kind of cohesive, opinionated architecture we’d loved so much in the first version of Symfony and built into Dinkly, but with the maturity and features of a modern framework. It shipped out of the box with authentication, queues, caching, logging, and countless other utilities we use in every build. These weren’t bolted-on afterthoughts, they were thoughtfully integrated parts of a well-designed machine.
The result? Supercharged development. For real, what came next were fun, efficient builds. And most importantly, codebases that would stand the test of time.
Three Reasons Laravel Became Our Framework of Choice
1. Cohesive, Opinionated Architecture
Laravel strikes a nearly perfect balance. It’s opinionated enough to provide consistency and encourage best practices, but flexible enough to adapt to wildly variable project requirements. Every Laravel project has the same basic structure and conventions. Configuration is easy without being heavy-handed, and there’s plenty of room for custom flourishes when needed.
There’s a noticeable thoughtfulness to the framework. The creators did a wonderful job anticipating the needs of real developers. Authentication? Built in. Job queues? Ready to go. Caching? Multiple drivers, unified interface. There’s even an impressive middleware layer that makes it easy to inject application-spanning behavior.
The overall cohesion of its internal ecosystem is second to none. It gets points not just for quality, but style.
2. Developer Approachability
Laravel’s documentation is exceptional. Clear, comprehensive, and actually helpful. It’s not just an API reference dump, and this goes beyond the official docs. The Laravel community has created an ecosystem of training resources, tutorials, and packages that make the framework remarkably approachable. There’s even a beautifully maintained set of video tutorials called Laracasts that make onboarding new developers a breeze.
Impossibly, Laravel is just as approachable for frontend developers as it is for the backend developers, granting immeasurable impact on our ability to collaborate.
There’s something deeper happening that I want to call attention to. It’s something I’ve noticed over the course of my career, that different frameworks attract different types of developers. Laravel’s commitment to quality and accessibility seems to attract well-rounded developers who in turn care about the same. They build quality packages, produce elegant tutorials, and contribute ironclad code back to the ecosystem. It’s a self-improving cycle that makes the entire community stronger and more supportive.
For our team, this means faster onboarding, easier troubleshooting, and fewer roadblocks.
3. The Long Haul
Modern development sometimes feels like coding on an Etch-a-Sketch, where every new version means shaking it and starting over. Laravel projects, on the other hand, don’t actually require massive rewrites every couple of years. In an industry where that’s shockingly common, our codebases age gracefully. It’s not uncommon for one of our projects to be actively maintained and enhanced for a decade or more!
Instead of facing wholesale rebuilds with every major version release, we perform yearly incremental upgrades that keep applications modern, secure, and performant. Laravel version upgrades always come with clear documentation and migration paths that minimize disruption. It’s an admirable devotion to evolution (not revolution) that means our code ages like wine, not milk.
For our clients, this translates directly to better bang for their buck and lower total cost of ownership.
Delivering Enterprise Quality
We’ve rebuilt national-scale advocacy and fundraising platforms from the ground up, redesigned complex healthcare management systems, and developed sophisticated e-commerce solutions — many handling thousands of users daily, all built on Laravel and running like well-oiled machines.
These builds consist of mission-critical software that handles complex workflows, high traffic, sensitive data, and usually multiple API integrations. Laravel has proven incredibly adaptable to these diverse responsibilities while maintaining security and performance at enterprise levels. Our spartan team is able to build with an efficiency, quality, and attention to detail that would make teams many times our size blanch.
Looking Forward
Having attended our first Laracon in Colorado this past summer, we can confidently say our enthusiasm for Laravel and its future has never been higher. The community is thriving, the framework continues to evolve in extremely cool ways, and we’re building bigger, more sophisticated applications than ever before.
The journey from spaghetti code, to Symfony, to building our own framework, has finally led us to Laravel. It embodies everything we learned to value: opinionated architecture for consistency, comprehensive features for efficiency, excellent documentation for approachability, and a commitment to longevity that respects both our work and our clients’ investments.
Combined with our multi-industry experience, this translates to predictable timelines, maintainable codebases, and applications that perform well under real-world conditions. We work in focused iterations, keep clients informed throughout the process, and consistently deliver on schedule.
Our shift to Laravel development recently became official when we joined the Laravel Partners program. This partnership gives us direct access to the Laravel team, early visibility into upcoming features, and deeper connections within the Laravel community. It reinforces what we already knew: Laravel is the foundation we want to build on for years to come.