Overview:
LeadShield was founded in 2019, because there were no automated solutions on the market that made it simple and painless to clean your email list in near real-time, without having to be a programmer or hiring a very expensive one.
The Story Behind This App
The idea behind LeadShield actually came from Brandon Shelton, which he pitched to me, and I was blown away that there wasn’t already a tool(s) on the market that solved this issue. At the time, Brandon was in Marketing/Sales working with other SaaS companies. He needed a way to clean his email campaign list of bad emails. He approached me on building a simple application and it actually turned out a lot more complex than we thought.
Technical Challenges
Like most bootstrapped SaaS projects, we started off building a Proof of Concept (POC), and then instantly recognized some of the challenges. One of the many challenges was verifying emails from different email clients and the accuracy of verification. After all, the point of the application was to scrub your email from bad emails. During our research, we discovered that not all email clients work the same and some are harder to get verification status.
Creating a near-perfect Algorithm that gives you 99% accuracy is HARD
Verifying whether emails are bad or good isn’t a simple task. No matter how much code you write, you’ll always get inconsistent results. During our research, we found that you need to have data and logic rules on the data while running your verification process. We discovered this after writing a lot of code and getting mixed results. We then learned that it was not the code, but the email client platforms that was causing the issues.
Taking what we’ve discovered, we didn’t have any data. So, like thinking outside the box, we found a workaround! It was a solution that gave us the accuracy and tolerance levels we expected, and one we can give our customers the confidence that they were using a solid product.
Moving the App out of Proof of Concept
In 2017, my son was about to be born, and my responsibilities shifted to family first. I stressed this point to Brandon, and he decided we needed to find a software company to finish the work we started. We started with a company, which I will call (Company A), and they took over the codebase I started. It was a disaster as they assigned us an Entry-level/junior Programmer who made many mistakes. During our rounds of testing, there were obvious bugs, but if they had decent QA process and tested themselves, it would have been obvious. Also, reviewing the code, there were instances where the Programmer left junk/testing code, no comments, or simply just did not understand the requirements. It felt to us our project was over their head and programmer pieced together logic without understanding the goals and requirements.
Anyway, we fired Company A and decided to pause the project. After some time, Brandon researched a new company, which I will call (Company B), and we went through an interviewing process. I was impressed with their presentation and the way they asked questions and gave feedback regarding how to make the application better. We went with Company B and were not disappointed!
Learning From Making Good and Bad Technical Decisions
We all make decisions and think the decision we made was the right decision at the time. In late 2017 and early ’18, I had a bit more time outside of my family duties to contribute to the project and coding. Brandon came to me and said Company B suggested we rebuild the application in Ruby on Rails because their programmers were stronger in that framework. At the time, I really liked Company B and wanted to work with them because they had sound disciplinary software programmers, understood SDLC DevOps, and had a great QA team and engineering processes. However, the point wasn’t to start over from scratch but to take over from where Company A left off. Company A did such a horrible job; they messed up the code base, and it really needed to be more usable for them to take over. After rounds of discussions, Company B would need to dump a lot of the logic/code Company A wrote, basically starting from the point I left off. Company B was confident they could work faster if they could work in RoR. Brandon relied on my guidance to make this decision, and I made the decision to move forward to scrap our Laravel code and do Rails. This decision turned out good and bad at the same time. The good thing is they were able to deliver on time as promised.
How was this a bad decision? I wanted to take over the project’s technical work once I got more time. My skills on Ruby on Rails were minimal, well, more like rookie status. I convinced myself that I would learn it when we decided to switch to RoR. As you know, they say, “Ruby on Rails is easy to read and learn.”
This decision would haunt me because my time was consumed with other family and life activities, and I didn’t get a chance to learn RoR as quickly as I had thought.
However, Company B did deliver, we laucned the application! I was very impressed with their speed and timing.
Over-Engineering the Architect
Another good decision and not-so-bad decision! As I stated, we started off with a POC, which was built on a LAMP stack and consisted of three VMs. We had Jenkins doing the deployments to environments (dev, staging, and prod). Company B always thinks big picture, so they wanted to put the App in Docker Containers. At the time, I was caught up in the hype over containers, and I bought into the hype, and we did it. As it turns out, that decision wasn’t the best because when small issues happen, it felt like a big challenge to get fixed. For people who do DevOps, you know you have the code pushes, merging code failures, unit test script failures, deployment scripts, running/switching containers, etc. It felt like doing multiple jobs at once. Yeah, over-engineering the architect when you only have one tech guy (me) wasn’t the best decision, and we needed to go back to Company B because they wrote custom deployment bash scripts with zero documentation. Anyway, we got it all worked out.
Great Experiences and Lessons Learned
I gained valuable experience through using this application. Brandon and I started our own SaaS venture with limited resources. I had to take on multiple roles, such as CTO, Solution Architect, Product Developer, Technical Lead, Programmer, and DevOps Engineer. I even had to conduct a cost analysis on infrastructure expenses to determine the most cost-effective infrastructure service. The experience was enlightening as it gave me a deeper understanding of creating a startup and an awareness of the technical and business challenges that I continue to carry with me in my professional life.
I would encourage anyone wanting to start a business, or SaaS, to just do it. The experience is rewarding whether it’s a big hit or not. You learn a lot from the journey.
Some advice:
- If you can avoid it, don’t be the only technical person on any technical project; however, if starting a business, sometimes you have no choice but to be the guy/gal.
- Not if, but when customers have issues or the application/server has failures in production, you’ll be the point person to fix it. Try to keep things simple. Avoid complex stacks or crazy ticketing systems. Do things that come easy to you!
- Stay in MVP until you hit your KPIs month after month. The MRR growth will determine when it’s time to scale.