My name is Povilas Korop and I'm a backend PHP developer from Lithuania. I have 15 years of experience, the last five specifically with the Laravel framework. My product QuickAdminPanel is an admin panel generator for Laravel.
It's cool to build a product for yourself and then realize there is a market for it. It's every developer's dream to start a new Laravel project and pre-generate some part of the code quickly, saving time and delivering the first version of the project faster.
QuickAdminPanel was first released in 2016, and slowly grew into steady income of $3,000–$4,000 per month (before taxes). We have around 1,000 paying customers.
About five years ago I was doing a lot of freelance work with Laravel, which then grew into a small team with friends. Almost every project we built for a client had some form of admin panel to manage the data. When we decided to write a script to generate part of the code, it saved us hours of time.
We thought it might be useful to others, so the next phase was releasing the project as an open-source project on Github, where it gained some popularity. Only then did I decide to try using it as an online-builder, like a SaaS version of the generator. The first payment from Stripe came even before the official release, and that's when I realized we were onto something.
It helped that I was actively blogging about the Laravel framework for all those years, and got some traction and a base of 5,000 Twitter followers. Every Thursday I sent a newsletter with new Laravel-related articles. Audience subscribers became the first potential customers of QuickAdminPanel, and it slowly grew from there.
During that time, our main source of revenue was still client work. We saw QuickAdminPanel mostly as a way to help deliver projects faster and with a bigger profit. I personally didn't believe it could be a primary source of income. But since then we've raised our prices 3x (twice), and revenue has grown significantly. Currently my personal goal is to switch from client work to product — if not fully, then at least a smaller number of clients.
Between our three person team, we divided the time between client work and QuickAdminPanel almost 50-50. It all depended on the demand from clients and the level of urgency. In our "downtime" we spent more energy on the product.
The first version was created in six months, but we polished it for another three months before calling it "official version 1.0." At first it was a CRUD menus and fields generator. Over time the feature base grew to consist of modules, table and form customizations, etc.
My advice here would be to launch as early as possible — when the tool actually provides value. In our case, it generated simple admin panels.
We started listening to the users and customers and they told us what they needed. I highly recommend having a live-chat widget on your website. Everyone wants help now these days; no one will take time to email you or report issues. If they don't get an immediate answer they will leave.
Answering these questions personally was one of the biggest drivers of our most loyal customers. Currently, I'm getting around ten live-chats per day, and am not planning to delegate this work to anyone else at the moment. That real-time feedback from customers is invaluable.
We prioritized our work based on the popularity of requests as well as what made sense for us, since we were still using QuickAdminPanel for our own client work.
Some time in 2018 we realized that the system had started to have performance issues and became more buggy, especially when users started creating bigger projects with it. So we had to re-create the system from scratch. That took almost a year, and released a totally new version in Summer 2019. Here are my 15 Lessons From Re-Writing Big Project From Zero. TL;DR: it's freaking expensive.
This one is simple. We used the same technologies that we generate code for — the PHP Laravel framework, while adding some Vue.js where needed.
We haven't had too many technical challenges with languages; the biggest trouble we had was actually with disk space. If we generate an admin panel with all its dependencies by running the "composer install" command, it might take around 100MB of disk space. Multiply that by the amount of generated panels, and you're in a danger zone with a simple DigitalOcean droplet. So we had to be creative with cleaning up unused panels and also pay more for additional disk space.
As I mentioned, my own follower base helped a lot — I was just blogging and tweeting about the progress of the product, mentioning it on my weekly newsletter, and slowly getting traction.
After a while I switched blogging for my Laravel blog to the new QuickAdminPanel blog, and six months later SEO results started to grow.
We didn't do any active advertising, because no one on the team was a marketer or a business guy at all.
Probably the biggest success in our content marketing (though we don't really call it that) were live-coding videos that took off quite fast. On my YouTube channel "Laravel Business", I was shooting screencasts of myself building stuff with QuickAdminPanel and adding custom Laravel code on top. That attracted an audience who wanted to learn Laravel.
This video alone received 33k views on YouTube: Calendar project with Laravel + QuickAdminPanel. My advice to other indie hackers here: video is the key to describing what your product is about. People like visual, they understand visual.
I also experimented a bit with Google and Facebook ads, but it didn't get any results. Perhaps because I'm not good at choosing all those target keywords and other parameters. Maybe one day I'll come back and try again, but it doesn't feel "natural" to me, when I have my own Laravel audience on my own channels, which are still actively growing.
We experimented with it quite a lot in the beginning. The first pricing model was $9.99 per project. You could generate the code online and view it in your browser and copy-paste for free, but downloading the full project was premium.
Then we raised price to $29.99 per panel. We thought we'd lose customers, but it actually did the opposite — it attracted people who used to think we were not serious about the project.
After a year, we switched the model to a proper SaaS-subscription based business. With a twist — only yearly pricing. So you can have unlimited projects for a year for the price of $99.99 or $199.99, depending on some modules that we decided to separate into more expensive plan.
We actually came up with logical names for these two plans: Developer and Agency. It reflects our customer personas pretty accurately. The Agency plan contained features that are actually needed for bigger teams, like Whitelabeled code, Team accounts, integration with Github, etc.
Then at some point, we were forced to get a "per project" price back in the form of a separate plan — we called it "One project" and priced it at $49.99. There were just too many potential customers who didn't want any subscription and wanted to just create one project. Ironically, quite a lot of them later came back and subscribed for the Agency plan. So you could call "One project" plan a "premium trial on steroids," I guess.
The final (for now) switch was in 2019, when we released a new version of the generator and decided to remove the barrier between Developers and Agencies by ditching the $99.99 plan. To be honest, it was mostly because I became tired of explaining to people all the differences between plans as it wasn't very clear.
Now customers can choose one project for $59.99 or the Unlimited plan for a year for $199.99. Currently I'm pretty happy with this model, but we will probably keep experimenting.
It's hard to talk about typical SaaS MRR because our model is only yearly pricing, and the "One project" plan doesn't make calculations easier.
Year | Revenue |
2016 | 415 |
2017 | 14000 |
2018 | 27000 |
2019 | 42000 |
In terms of expenses, it's mostly about the work of developers. I'm spending around $1,000 a month, so profit margins aren't big. I wouldn't be able to live off just QuickAdminPanel. Yet.
As I mentioned, I want to switch to product as the main source of revenue if possible. I just enjoy working on a product much more; it's a different kind of stress compared to client work.
To do that, we need to grow our revenue at least 2x. For that, I think it won't be enough to "just blog about the product." As they say, what got you here won't get you there. So I need to come up with some ideas for outbound marketing, or maybe some twists in my content to attract the new audience.
That said, with our $199.99 pricing we don't need that many new customers. Even 100 new customers would make a significant difference.
Probably the biggest challenge was the day when Taylor Otwell, creator of Laravel framework, released Nova — an official Laravel admin panel.
I thought we were screwed. How can you even compete with the tool supported by creator himself? But as the time went by, surprisingly, our revenue didn't drop. And then we realized we were just serving a different kind of target audience. Nova was for more professional developers who wanted to dig deeper into customizing the code, and QuickAdminPanel was more like drag-drop editor for more junior Laravel developers. So my advice: if you're competing with bigger players in your niche, try to find your own angle with your own sub-audience.
If I had to start over I wouldn't do much differently, to be honest. So far it's been a slow and steady growth — both as a product and as a business. I didn't want to raise any money, or grow too fast by "faking" the numbers, so it's all pretty natural, and I like it so far.
I read a lot about business and am also a big fan of podcasts; but the more information I consume, the more it comes down to just a few points of advice. I've even written an article about this.
If I had to summarize it even more, three words: JUST DO IT. Cliche I know, but no amount of external advice or motivation would actually do the job for you. And only while doing the work and when talking to your customers will you then discover the insights about your particular niche.
Looking back, a very smart decision was to start blogging early. Yes, it takes time. But hey, I enjoy it! I like sharing Laravel tips or any other tips I can give, and helping people. The audience-building wasn't even a strategy or a tactic, I just did what I enjoyed all the time.
I think that success is a weird combination of hard work, business model, timing and luck. But without hard work at first, nothing else matters. So my advice would be to start real work. And I don't mean building the product (the sexy part for us indie hackers), I mean talking to potential customers, doing market research, releasing some articles to proof the idea, and scoping the actual features for MVP. Then start building. Or, maybe, you will find that idea isn't worth pursuing — saving time is also a win.
Also, stop reading Indie Hackers. Weird advice, right? :)
By that, I mean stop consuming any and every piece of content you find on how others do stuff. It will give you a false sense of accomplishment. For example, it might feel like you're doing meaningful market research, but in reality you're just procrastinating and looking for some kind of proof or permission to act from someone else. You don't need any permission. I personally allow you to go do stuff. Including posting on Indie Hackers. But not just reading.
You can check out our product at QuickAdminPanel.com. If you're interested in Laravel, check out my blog or YouTube channel.
On a personal level, if you like my thoughts about web-dev business, productivity and indie hacking, follow me on Twitter or connect on LinkedIn.
Feel free to ask any questions or comments below, will be happy to answer.
Very inspiring. :) I'm a PHP dev too! I grew tired of doing CRUD over and over again so I created a simple crud.js which handles datatables crud operations. :D
Povilai, ačiū!
Glad to see fellow from Lithuania:) was wondering how do you scale? Do you use digital ocean managed kubernetes :)?
Hey hey neighbor :)
We don't need THAT much scale at the moment so it all fits on a few Digital Ocean droplets without kubernetes or anything more sophisticated. For now.
Yes, thanks for share, You will have more success!
Very interesting read!
Thanks Peter, I hope it will inspire fellow IndieHackers. If you have any follow-up questions, I'm here :)
Nice. Thanks for sharing Povilas!
It was a pleasure, Peter. Let me know if you have any more questions :)