10 Quick Lessons from 6 Laravel Product Reviews

Those who follow this blog or Twitter account know that last week I did some Laravel-based products reviews. Totally 6 of them, all in one week. I've published them one by one, and now it's time to recap and talk about main conclusions, takeaways and lessons. What have I learned from those Laravel products? First, if you missed it, here are the reviews:

Now, let's dive into lessons learned.

Disclaimer: those mini-reviews were done with selfish goal - to gather some ideas for our QuickAdmin product. So I didn't spend too much time on the projects - approximately 1 hour per project. And if installation failed for some reason - I didn't spend too much energy to make it finally work.

Lesson 0. Make your product install-able

Originally I planned to review 10 products. Guess what - 4 of them didn't pass through installation stage on my local Homestead. For various reasons:

Incompactible PHP version (mine is 7.0.2)
Some weird PHP library needed
Installation worked but the result website didn't work properly
Needed additional .env parameters which I had to guess from somewhere

Here's an example. screen-shot-2016-11-14-at-5-10-25-pm

Whatever was the reason, it doesn't matter. I mean, I could have spend additional time on actually making it work, but, come on, ain't nobody got time for dat. So, please please please - if you publish a package, make sure the install works. Run the install on different machines/environments, ask your team/friends to do so. And don't push for some fancy library/package/version dependencies - only if you really-really need it. Otherwise you limit your potential audience.

Lesson 1. First impression: quick start and documentation is everything

Rule of thumb: the quicker your user achieves the first results, the better chance they will actually use it. So-called "customer onboarding" and first impressions are important even if your app is free and open-source. Some of those reviewed products had really awesome documentation, or their installation was just default and straightforward. It really helped in quickly understanding how things work.

Lesson 2. Too complex documentation - no one will read it

Ok, remember lesson 1? There's another side of the story - if your app or project has a separate documentation page with 20+ menu items, guess what? No one will read it. Make as many things self-explanatory and easy-to-use within the project itself. If there's an installation script, provide all the information after the script launch, don't make users search for info somewhere outside.

Lesson 3. Install your app yourself from time to time

Of course, all the projects have version 1, and then are upgraded and maintained. That's fine, but while building new functionality, owners often forget the basics - installation and onboarding process. It is really useful to install your app from scratch after half-year working with it - not only to check that it's working, but to look at it form the eyes of a new user, you will have some ideas how to improve the process.

Lesson 4. It's not about launch. It's about support and maintenance.

While reviewing the products, I judged them on a number of criteria. One of them was the age (time since the first version) and amount of Closed/Open issues (or, in fact, the ratio of them). I've noticed that the projects that actually took off, like Invoice Ninja, are usually already a couple of years old. With already improved functionality, hundreds of closed tickets, expanded customer base and broader vision. So if you launch something and think that you've reached the goal, I have bad news for you - it's only the first milestone. Important one, of course, but only the beginning. Those who stay on the road for longer, survive.

Lesson 5. Start small.

If you have an idea for a project, that's awesome. Now, don't spend months and years on building "the next Facebook", launch something small just to test if the idea is actually interesting to anyone. I've seen countless times when developers try to polish and architecture their app, then refactor it even before the actual launch. Even we suffered from it with QuickAdmin. Buzzwords like "Agile", "Minimum Viable Product", "Lean Startup" - they all apply to open-source software as well. Start small. Sometimes even stay small if that's all you need to be successful.

Lesson 6. You can build a business from open-source. Kind of.

There's a constant battle - people are arguing that open-source software means available for free. It is only partly true, and there are actually many stories of businesses that started as open-source, but then grew into a profitable income machine. One of examples here is the same Invoice Ninja - they offer a premium paid hosted service, and open-source version for free. And have clients for both. Though you shouldn't be too optimistic as a developer. Projects that make it as businesses usually transform into businesses. What I mean by that - they are run not by developers, they have business minds in the team: sales, marketing, advertising, business strategy etc. So whether you want to dive into that world - ask yourself that. On the other hand, such open-source projects available online are a great way to get customers for your web-development services. They serve as part of your CV, as a proof that you actually can build (and support) something online.

Lesson 7. There are million ways to code the same thing.

By analysing the code of those Laravel projects, I was trying to find some patterns. And came to a conclusion that it's all a matter of preference of developers. Whether to use fancy design patterns, whether to create a separate folder for Models, whether to use Datatables with AJAX or without it etc. Millions of ways to achieve the result. Therefore if you read somewhere that you need to code this or that way - take it with a grain of salt. There's no universal recipe for a "perfect" code - as long as it works for you and it easily maintainable, go ahead.

Lesson 8. Think about future versions of framework / dependencies

If you're building something and relying on some framework - for example, Laravel - and also include some packages in your composer.json, think upfront what will you do when they release new versions. In some cases of those reviewed apps, they were started as Laravel 4, and now were upgraded to Laravel 5.x only partly and with nasty workarounds here and there. Perhaps I would raise a question whether it made sense to upgrade at all. The rule of thumb here, I think, is to choose - whether you upgrade often, with every version of the framework, or otherwise at some point it will be just too painful/expensive to upgrade.

Lesson 9. Reading other people's code is the best way to learn

Guys, stop reading theory tutorials on "How to write Hello World in 3 minutes". Read the code of REAL projects that solve REAL problems. I'm sure you will find a lot of interesting things, unexpected solutions, nasty workarounds and things you didn't expect. Of course, not all of that is positive - you will also find some legacy code, undocumented parts, hard-to-maintain architecture, bugs etc. But that's also part of the real world. And you don't want to stop at "Hello world", do you?

Lesson 10. You have to do marketing for your free code too

So you create that awesome project and release on Github for free. You are a rockstar, probably everyone should be using it and be grateful that you spent your valuable time. Nope. You need to tell the world why they need to spend their time on using your product. First, you need to tell the world that it exists - write a blog, Tweet about it, share on Facebook, ask or a guest-post on some popular portal etc. But even then - you need to convince potential users that their time is worth it. Cause time is probably the most valuable asset in 21st century. So, in a way, they pay for your project. Respect that.

So these are my takeaways and lessons. What would you add or comment? What was your path, if you released your own IT project? Anything rings a bell?