Introducing Larahawk - Simple log monitoring for Laravel applications

An alternative title for this might be "How I Learned to Stop Worrying About Stiff Competition and Launch Anyway", and I'll explain that below.

Want to learn more for yourself? Check it out at larahawk.com.

Prelude

As with a lot of good side projects, it all started by scratching my own itch. Over the last couple of years I had been developing and launching more than a few Laravel-based projects, but I had no real way of keeping track, or getting notified, of any issues that would pop up from them once they were in production. Even when I did get a hint about one, my usual path to start decoding the issue was along the lines of:

• ssh into the server
• tail storage/logs/laravel.log
• start investigating backwards from the last entry + trace

Definitely cringe-worthy. While sure it worked for my small projects, the problem was that I wasn’t being proactive with my investigation. I usually had to wait until someone came to me and told me “Hey, this is broken” before I started doing any of the steps above. It’s generally not a great idea for your customers to discover issues in your codebase, so I started thinking maybe it was time to find something a little better.

The requirements weren’t this laundry list of things I needed. Essentially, I wanted an app to watch my Laravel logs for any changes, and my application for any exceptions thrown. It should then record the details, and ping me through text or email. So I started doing some digging to see what was out there.

Options Galore

Unsurprisingly, there’s a massive amount of options for log monitoring and error reporting apps. You have large well-known brands like BugSnag, Sentry, and Rollbar. Then there’s some slightly more obscure ones like Understand and Inspector, which are aimed toward mostly Laravel developers. It also goes without mentioning that Flare was recently released and partially added to the Laravel core framework just a month before writing this article.

After going through these options, I wasn’t really left that satisfied. I felt like there were either too many features that I wouldn’t take full advantage of, or that I couldn’t justify the price point based on how small the projects I was concerned about were.

In all honesty though, this might have just been an excuse for me to build a full-fledged SaaS app, a realm I’ve always wanted to get into but have never really taken the steps to enter. I decided to do just that, and started work on building what would become Larahawk.

The good news is that I already had a bit of experience in this particular area before. Last year I developed and launched Larametrics, a self-hosted notifications and metrics package to give you insights about your app’s model, log, and route usages. I practically had the scaffold all set up for an external package to watch Laravel apps and handle log events. The rest was contingent on getting a good dashboard developed for the data coming in.

All Mine

I set out to build something that, first and foremost, I’d want to use. I started out, like most people probably would, by sitting down and writing out this complicated list of features and attributes for the app. It would make my project a powerful player in the field, and give a better chance to stand out among the competition. After all was said and down I looked down at what I had come up with, and knew that I wouldn’t be able to create something that ridiculous in a reasonable amount of time. My scope was too large, too feature-rich, and wouldn’t have gotten completed in anywhere near a reasonable timeline.

I decided to whittle my focus down into an MVP I could have developed in a few months. So I thought, “What are my absolute needs at launch?”, and came up with the following list:

• A central dashboard to see the health of multiple apps at a glance
• Log entry details saved and organized in an easily-digestible layout
• The ability to notify me via SMS, email, and Slack
• A ridiculously simple installation process
• Affordable at $5/app/month

That’s it. That’s all it should do, but it should do them all well. What I took away from both the development process and by talking to other makers producing their own SaaS apps, is that you don’t have to be better at everything your competitor is good at.

You can take just one small aspect and try to do your best at it, release it into the wild, and iterate over it again and again as you gather feedback from the people who use it.

Larahawk didn’t need to be an all-in-one solution for error tracking, task management, resource gathering, database monitoring, etc. I needed an app that would watch my Laravel installs and report back to me anytime a log was written to, and I think I created something that does that pretty well.

Next Steps

Once you’ve released your project into the wild, it’s important that you don’t just up and abandon it. Without your growing support, it’ll likely shrivel and die before it can even get an inch off the ground. In my experience, it’s important that after you’ve pushed out an MVP, you have a decent-sized todo list of features, bug fixes, and other additions that you want to implement into your app.

It could be small things like a simple layout change or a color shift, to extensive feature additions, accessibility implementations, or a robust public API. These items, along with an outward social media presence, can not only provide traction for your product, but also serve as a nice historical log for what’s been added to it through time.

I have plenty more to say about this subject, but that’s for a different article!

The point is, that’s what I’m doing for Larahawk, and it’s the primary reason why I’m writing this article as we speak. I have a Trello board of bug fixes and features that are a mix of things I’ve thought of, or that users have come to me requesting, and I plan on getting through each one at a regular pace. The reason being that I don’t care if 100 people end up using my app, or just myself; I want to iterate over it, and grow it, just like someone trimming a bonsai.

Even if it’s small, it will embody the vision that I see for my project.

Thanks for listening! If you’d like to connect more, learn tidbits about web development, or see my progress on other projects, feel free to reach out to me on Twitter.