Many developers have little side projects they tinker with. Some may lead to a worthwhile product, but most just end up languishing away on their hard drive, never to see the light of day. I’ve had a few of these projects and figured it might be interesting to take a look at them and do a post-mortem of sorts. The first of these projects will be the LG Console.
The LG Console was something that I stewed over for months, mostly while mowing the lawn or doing other yard work. At the time, I was still a bit involved in the affiliate world, and was thinking about getting into Local Lead Generation. With lead generation (LG, hence the name LG Console), you are being paid to gather qualified leads for a company. With local lead generation, you are usually doing this for a local company, gathering leads for plumbers, dentists, dog walkers, whatever. Typically you would build a landing page, or use an existing one that a customer had, and then drive traffic to that page in hopes that the visitor would complete a short form, thus creating a lead.
What I wanted to build was a system that could manage five, ten, or fifty clients, all from a central location. If I needed to modify a form on Customer X, I didn’t want to have to FTP into that customer’s server, or request that they make the changes themselves. Also, I wanted to be able to have some insight into the leads they were receiving, so that I could tell what traffic sources and keywords were successful. And, finally, I wanted to be able to do things with the leads, like email them to customers, insert them into a customers database, and more.
With all that in mind, the LG Console started to come in to being. There were two main pieces. The first was a form builder. The second was a set of what I called Data Actions. Each action would represent a way to process the lead being submitted, whether it was emailing the lead, saving it to a database, or entering it into SalesForce or SugarCRM.
LG Console was built using:
- PHP 5.x
- CodeIgniter 2.x
- Doctrine 1.2
At the time, I was enthralled with Doctrine 1.2 and YAML, even writing an early blog post. Now I’m much happier never dealing with YAML again, as Doctrine 2 seems to have moved away from it.
The Form Builder
What Wufoo makes look so beautifully easy, isn’t. Creating a form builder is a pain, especially when dealing with the attributes for each field you’re adding. I went way way way too far down the road of hidden form fields and other mischief. Dealing with arrays of hidden input tags that you then cobble back together on the backend is no fun. I only wish I would have noticed how the guys at Wufoo handled it: with JSON. They store all the field attributes in JSON on the client side, and when you save your form, you are submitting that chunk of JSON back to the server which it can then easily parse.
Data Actions and Data Pipelines
An area that was a little more successful than the Form Builder were Data Actions and Data Pipelines. A Data Action was something that would be done with the lead once it was submitted. It started out with the obvious things: email the client the lead, write the lead to a file, save the lead to a database. But then I went off and started solving problems I didn’t even have. What if the client used SalesForce or SugarCRM? What if they had a team of sales people who wanted to get leads sent to them via SMS in a round robin pattern? What if they had some custom API that they wanted data fed into? Why I thought these local companies would have that is beyond me now, but it seemed important at the time.
Data Pipelines were simply a chain of Data Actions that would be assigned on a form by form basis. Multiple actions could be done with the same lead, so it could be emailed, written to a file, and saved to a database. Pretty straightforward idea that ended up working well.
Another thing I was working on was the ability to create new Data Actions that could be specified using JSON and then uploaded like plugins. The idea was that I could enable end users or other developers to create these plugins and hopefully save me the time from having to enable that functionality on my own. It was an interesting idea, but something that should have been left for v2 or v3.
Learning Through Failure
There was quite a bit to learn from this project. First, the mistakes:
- I spent too much time planning
If you spend a summer’s worth of lawn mowing thinking about a project, you will over engineer the heck out of it. The first part I should have gone without: the form builder. Creating forms in HTML is child’s play, so why did I need a form builder to help me do it?
- Getting way way way ahead of myself
Sure, I could have been able to sell this as a web application or SaaS, but I still was putting a ton of work before I even got to my goal of attempting to do local lead generation. I had zero clients, but was worried about the work of maintaining many of them.
- When the code got messy, I kept going
Early on, the codebase was quite clean. Once I started trying to implement more functionality, I really started to over-engineer things. That, coupled with my lack of knowledge when it came to Doctrine and CodeIgniter, really lead to some messy code and messy models.
- Exposure to new technology
Up to this point, I had not spent any time with Doctrine or CodeIgniter. In fact, most of my PHP work had been done without any real framework at all.
- Learned to start small
This project, along with the book Start Small, Stay Small, really helped me to realize that any future projects I worked on needed to be much more focused. That’s not to say that I’ve really been able to crank out any meaningful project since then, but it has stopped me from getting too involved in projects that were completely unmanageable.
- Lots to research
Among other things, I did some research and dev work with sending email and SMS programmaticly through online services like SendGrid and Amazon SES.
The End of LG Console?
And that, most likely, is the last anyone will see of this project. When I built a new computer this summer, I lost the database that LG Console was utilizing. Normally that wouldn’t be a huge issue, except for that I committed the cardinal sin of storing important application configuration data in the database without having any local copy to go by, let alone any documentation on how to recreate it. That leaves me without the ability to create Data Pipelines now, which is a shame.
I’m not sure when I will get to it, but the next “failed” project that I will feature is Clvr.io, an attempt to determine Customer Lifetime Value (CLV) for the visitors to JenkatGames.com. It was an interesting and more focused project, but one that still failed due to unforeseen issues.