Backpack Is 8 Years Old Now š„³ Hereās Some History
I had this realization the other day - and it blew my mind. Eight years is a lot of time! To put that into perspective: 20% of new bus...
Cristian Tabacitu
Share:
I had this realization the other day - and it blew my mind. Eight years is a lot of time! To put that into perspective: 20% of new bus...
I had this realization the other day - and it blew my mind. Eight years is a lot of time! To put that into perspective:
We're almost there, at the 10-year mark! More relevant perhaps is that most Laravel admin panels don't survive their first 2 years (we'll follow up soon with an in-depth article, it's super-interesting). But not Backpack, we've been around for 8 years now and we're still alive and kicking! š
Weāre very fortunate to be here, writing this post. I want to thank EVERYBODY who bought a Backpack license, everybody who contributed to our codebase and everybody whoās told people about our software. I am perfectly aware itās thanks to YOU we get to do this, and weāre very VERY grateful. We literally couldnāt do this without you. š You rock!
To celebrate these 8 years of Backpack, weāll do two things:
So here goesā¦ hereās The Story of Backpack, including the 3 years that preceded it:
āā
In May 2016, on my birthday, I distinctly remember my sister coming overā¦ and me ignoring her for hours. Why? Because I was in a very productive coding spreeā¦ I had been so for a few weeks, ever since I decided to fix āmy admin panel problemā, once and for all. You seeā¦ my web dev agency was small back then - we were doing mostly small websites and web apps. We were starting a new project every month, if not multiple a monthā¦ and every freakinā time, we had to build the same stuff all over again for the admin panel: auth, datatables, forms. I had a new project coming up, and if I remember correctlyā¦ my CTO back then (Eugen Tudorache) gave me the green light to build an admin panel library. So I absolutely ran with it. We were using CodeIgniter, and there was this great library called GroceryCrud which solved a lot of the problems we were having. So I put those together, did a lot of wiring so they matched what we usually needed, and boom: Cornel was born. We loved it, cared for it and used it for years, butā¦ we never open-sourced it. Not from some evil plan of having an edge over competition (hell no), but becauseā¦ like many devsā¦ we were afraid to make our code open-sourceā¦ and to be frankā¦ we didnāt even know how!
Fast-forward a few years to 2014, and we decided to move from CodeIgniter to Laravel. It was my colleague Cristian Toneās job to rewrite the whole thing, in Laravel. He did - and we called it Viorel. And with that, the core of the Backpack you know today was born. Hell, a few years ago I found a few comments in the code that made me realizeā¦ that bit of code is from back then, from 2014! The comment read something like "sync function, only Tone know how this works" š It was truly a blast from the past. We used Viorel for a while, until we got the courage to finally polish it, generalize it and open-source it.
In 2015, after making the decision to rewrite and open-source it, I remember talking to my partner (and CEO of our web development agency) Andrei Iordache about itā¦ heās a world-class copywriter, and functioned as our creative directorā¦ so naming was kind of his thing. We did some back-and-forth when he finally came up with a brilliant name. He saidā¦ āFuck it, letās call it Dick! I bet people will like itā.
You see, back then the admin panel wasnāt a Composer package. It was an entire Laravel 5 repoā¦ and we had the unique opportunity to ask people to do git push dick and git pull dickĀ š It sounds immature, doesnāt it? Well for a couple of 20-year-oldsā¦ ok fine itās immature for that age tooā¦ but we had fun, ok?! š I especially remember how much fun it was to write the website copy for it (see the old Dick website here). I have NO REGRETS over that name. In fact, I think itās thanks to that name that some people tried it! And people did try it! Turns outā¦ some people liked dick! And some people absolutely LOVED dick. They couldnāt get enough of it!
So yes, Dick started growing. Seeing people actually care about and use my softwareā¦ that was enormous step ahead. You see, I had been trying to move from Ā« servicesĀ Ā» to Ā«Ā productĀ Ā» for years by then. I had built and launched about 7 productsā¦ all failed miserablyā¦ some stillborn, some died within months, some took years of work and still failed. So I had lot of experience of failing at a productā¦ not much experience running a Ā«Ā successfulĀ Ā» product. And at the timeā¦ and for our levelā¦ it was a successful product! People contributed, used it and promoted it. Apparently people got a taste of Dick, they couldnāt get enough of it. Told their friends to try it!
But as happy as I was with Dickā¦ there were troubles that needed to be addressed:
Problem 1. Devs loved the name at firstā¦ but then got sick of it fast. In fact, multiple people said they love it in passion projects, but canāt use it for clients, because of the name. They were scared their clients might see it, and think they put it there themselves to mess with them. It wasnāt a professional name.
Problem 2. It was a Laravel installation, with a lot of things - the CRUD library, UserManager, NewsManager, LogManager and more. You couldnāt pick and choose what you want. Plus, updates were pretty difficult to getā¦ and it sometimes overrode your custom code. Ouch! By then, Composer had proven itself and I was eager to split it up into distinct packages, one feature each.
Problem 3. Time! I was all nice and dandy that people were using my software, but it turns outā¦ collaborating with dozens of people every dayā¦ takes a lot of time. For a year or more, i was working 16h daysā¦ first 8h for web dev clientsā¦ then 8h for Dick, for free. I was lucky I was in my prime - I definitely couldnāt do that now. But after a few burnouts I realisedā¦ this isnātĀ sustainable. And it isnātĀ fair. We need to find a way for Backpack to make some money, and become more professional.
So I thought if a different nameā¦ and I came up withā¦
Seemed like the perfect name for a collection of PACKages that help you build BACKends. Plusā¦ I wanted Backpack to truly represent its physical namesake - to be useful, versatile and feature-packed. To have everything you need in your journey.
So I launched Backpack with the differences aboveā¦ and after a lot of deliberation with a few heavy usersā¦ decided to charge for it too. Since our audience was now also professionals who build stuff for clients, we had dual-license:
Some napkin math told me that would be enoughā¦ that 100 paid projects per month would basically cover my time spent on it (I didnāt value my time back then š ), and that was good enough for me.
And with a lot more work and patience and care, Backpack took off. We were fortunate enough to get A LOT of help from the community - and I do need to give a big shout-out to Owen Melbourne, David Lloyd and Abby Jansen here, who really helped out almost daily, for months or years. Felt like PRs and issues were coming inā¦ faster that I could read them. Our charts for number of downloads was going up only. We were talked about in all Laravel-related communities, despite some choices our stack being despised by some (ehemā¦ jQuery). We were doing something VERY right.
And yetā¦ we were doing something very wrong. We were making a few hundred bucks per month, at most. People were using Backpack a lot (we had download stats now) but they werenāt paying for it. Lesson learnt: if you donāt force someone to pay for a productā¦ theyāll find a way not to pay.
So as good as Backpack v3 wasā¦ something had to change. Sure, we needed a version bump in our dependenciesā¦ and to push some fixes that contained breaking changesā¦ but more than anythingā¦ we needed a business model change. We needed to actually start making money. I had years of 16h workdays by now, and enough burnouts that I stopped counting. And despite not making enough money to cover my time... we were being judged as a paid product.
I donāt quite remember what it was that v4 brought new in terms of features (later edit: it was Bootstrap 4, Widgets and more) but I remember what it did have in terms of business: We kept the dual-license, but we started actually enforcing it. Both free and paid users needed to have a license code, for their software to work. Free users could get it by filling in a formā¦ paid users could get it by purchasing it (it should have been $39/project by now).
Fun fact: the license-checking mechanismā¦ only checked that there was a license keyā¦ not the actual license itself š Itās ok to say that now, right? I thoughtā¦ if there are people who are upset for us forcing this license-check mechanismā¦ Iād give them an easy way to hack itā¦ and continue using it for free.
That doesnāt sound very smart, does it? I just said a lesson I learned in v3 was that Ā«Ā if you donāt force people to pay, they wonātĀ Ā». Alas, I didnāt learn it well enough. But... it worked! More people paid, because it wasnāt public knowledge the licensing system was a ruseā¦
We could grow our team a bitā¦ this is where our oldest core team member (outside me) came in - Pedro Martins. Pedro had fallen in love with Backpack and was submitting contributions anyway, so I was eager to ask thim to come onboard, and help me carry the load.
But our licensing system also generated another problemā¦ we were manually approving free licenses! Every day, dozens of people were applying to get free licenses. So it took me hours every day to go through themā¦ judge themā¦ and issue the licenses. We had automated it as much as possible, but it wasnātĀ feasible for us to keep doing this. Every free user was costing us time to acceptā¦ so much time in fact, that we ended up hiring someone to do this alone - part time.
Sounds like a bad system? Thatās because it is! So bad in fact that we were covering our small (very small) salariesā¦ but thatās about it. We couldnātĀ think long-term or do any useful things to level-up our software, because we were spending all of our time on the free users.
Did we try other things? Of course we did. We tried consulting. We tried ads. We tried many things. Nothing worked. So after 2 years of grinding itā¦ we saw it for what it wasā¦ a bad business model. So we decided in the next versionā¦ weāll do things differently.
We finally took the leap, and changed our business model form dual-licenseā¦ go open-core. Our most used features would be part of the open-core, which would be MIT-licensedā¦ and our other features would be addons - some free, some paid.
This was a HUGE boost in revenue. It provided the financial security we needed, to know we can do this for living, and lead decent lives. It allowed us to increase the team again, bringing in first Antonio Almeidaā¦ then a year later Karan Datwani, Jorge Castro, Mauro Martinez, Mohammad Emran and Munjal Mayank. Add to that Vali Dumitrescu for the admin stuff andā¦ yes, we tripled our team in one year š¤Æ We were on a roll! And thought it didnāt work out with all of the people here, we were pretty proud of what we had achievedā¦ and the amount of stuff we were able to put out. For the first time everā¦ we were doing things we had only dreamed of: videos, blog posts, Twitter posts, new features every month š¤Æ
Did we need to change anything at this point. Yes. We wanted to refactor everything. To modernize it, and lose some tech debt we had gathered over the years. But we couldnāt do that. Our customers were very clear with their feedback - the v4 to v5 upgrade was brutal to those who had complex projects, so going forward we should keep breaking changes to a minimum.
Needing to do some breaking changes anyway and bump dependenciesā¦ we took advantage and polished a lot of our code, removed old versions and refactored what was needed, in order to be able to build the most-requested features.
We added themesā¦ which was a flop. We expected people to create custom themesā¦ but noone did. We added custom operationsā¦ which was a flop. We expected people to create custom operations, not a lot of people did (though itās really powerful feature).
So one thing we learned in v6 was that sureā¦ customers can request featuresā¦ but that doesnāt mean you must build them. A lot of timesā¦ itās better to help customers scratch their own itch in their projects, rather than build and maintain a feature for everā¦ because 1% of your users might use it a few times. Going further, weāll be much more careful with doing BIG features and rewrites. The way we see it, Backpack is feature-packed alreadyā¦ in fact, thatās one of the reasons people love Backpack - because it offers out-of-the-box most features an admin panel will need.
So weāre happy to considerā¦ Backpack has reached maturity. Yes weāll still add features - in fact weāve been launching new features every month - Antonio and Pedro make sure of it š But we wonāt be bringing any major changes any time soon. In fact, the direction is the opposite - for Backpack to become a Ā«Ā boring technologyĀ Ā» like PHP, Laravel and jQuery. Technologies you know you can rely on, because theyāre battle-tested, time-proven and stable.
And that takes us to today. In 2024ā¦ Backpack is doing good. Sure weāre not becoming millionaires any time soon. Sure we have a lot of stuff to do, optimizations, refactors, restructuring, recalibrating. But overallā¦ weāre proud to be in the position of still being here, 8 years later. And having no doubt weāll be here to celebrate 10 years and 15 years and more. Weāre a small but sustainable software companyā¦ and we expect to grow a few times over after we learn some marketing šš¤.
Thank you for being part of this journey. Thank you for contributing, with your money, time, ideas or attention. Weāre super-grateful to serve customers that are just like us - itās a dream come true. And thank you for reading my rambling so farā¦ I did NOT expect you to š But if our history was interesting to youā¦ so will our future. We have BIG plans, so keep an eye on us.
To end, yes, weāre doing a huge promo campaign next month. Subscribe to our weekly blog digest to find out when it starts, and grab yourself a hugely discounted admin panel. And feel free to buy years in advance at that discount, weāre not going anywhere.
Thanks for being a part of this. Cheers!
Subscribe to our "Article Digest". We'll send you a list of the new articles, every week, month or quarter - your choice.
What do you think about this?
Wondering what our community has been up to?
