As an agency owner, businesses
will
sometimes ask for
your
advice, and with
y
our knowledge and resources in the digital space, these conversations
can
sometimes lead to equity or sweat equity opportunities. That’s exactly what happened to us.
My now-partner came to us to help develop
a digital insurance solution that, more than three years later, has been adopted nationally by multiple agencies.
Sounds great, right? But it wasn’t always so easy, and it still isn’t. In an effort to help software entrepreneurs, and other agency owners who face similar opportunities that involve taking on new roles, here are some lessons I’ve learned along the way:
Developers will burn out, so keep them engaged.
Developers are awesome when you find the right ones. They work hard around the clock and come out of the gates swinging. But don’t get too accustomed to the excitement and rapid-fire coding you see at the beginning of the dev cycle because it slows down.
We were moving quickly, pushing out new code sets almost daily, with a ton of progress — until we got our first bit of critical customer feedback. We had to re-code features that we had already spent a lot of time on, which was frustrating. Our developers lost their excitement.
Sure, it comes back, but eventually, the train slows down. Be cognizant of that and reward your employees to keep them engaged. We found that buying new hardware for them helped boost morale far more than any pizza party.
Refactor your code and clean house.
This is absolutely key: You develop a ton of code, change features to work in a realistic setting, and when logic starts to change, all the old code is still sitting there.
After three years, we learned that refactoring — going through code files and removing old logic or unused code — saves a ton of time when you have to search for bugs that aren’t possible. If you’re using a system like GitHub, the code is always saved historically.
Back up your code.
Version control is critical when starting a project. Make sure you back up code and have a revision history. When introducing new developers to the team, you’ll want accountability for who did what and where, so there’s no deflecting blame for mistakes. It also helps in the “developer disappeared” scenario when you’re scrambling to see if you have everything backed up but can’t read code yourself.
Be clear about expectations.
Working with developers, I learned never to rely on the words “easy” or “simple.” Sure, sometimes things are indeed easy and simple, but when you add 100 “easy” tasks to your list, your deadline definitely gets harder.
My partners and I would often come up with great ideas, and the developers would say, “No problem, that’s easy.” To us, “easy” meant two minutes. To developers, easy meant two days. Understanding the culture and communicating clearly about expectations are key to successfully meet deadlines.
Don’t get lazy when it comes to testing.
Every time we updated our website in development, we felt like we were moving one step forward and two steps back. The reason? Negative testing code.
We assumed the code we’d tested 100 times would always work. But that’s not always the case when you add new features, which can wreak havoc on an older, “perfect” feature and stop it from working. We learned the hard way that being lazy in testing and pushing out new features risked the backlash of our clients when their systems collapsed.
Beware of the ‘cool.’
In strategy meetings, we’d often hear the line, “It would be cool if it did this.” Well, cool doesn’t always make you money. In fact, it’ll probably cost you time and money.
In the beginning, we were moving fast, building everything under the sun. We figured everyone would use every feature, only to learn that nobody wanted them. We learned the hard lesson of KISS: Keep It Simple, Stupid. People want something that’s easy to use and functional, not to be overwhelmed.
Not every customer is right.
One of the early mistakes we made was not including multiple customers in our conversations. Instead, we made assumptions and decisions for them. In hindsight, we would’ve saved a ton of time had we sampled 50 of our best users and asked them what features they would use. Instead, we just built everything that any customer ever asked for, until we realized certain features were starting to contradict others.
Sometimes it pays to slow down.
Nothing drives developers crazier than wasted time. But when racing against the clock, beware of half-baked ideas. We often conceived great features that were completed exactly as requested. But once we saw the end product, we realized how many scenarios could break it. We had to shelve or completely re-write some features that we spent lots of time on. Better to take time on the front end than to endure frustrating fixes later on.
Get help exterminating bugs.
In software, bugs suck. There’s nothing worse than when a customer emails support to say, “the system is broken,” without offering further details. Early on, we scrambled whenever a bug ticket came in, wondering why it worked on our computer but not for the clients. What browser were they using? Are they on AOL 3.0? We wasted so much time and mental energy until we found a tool to identify bugs. Look for a tool that provides valuable data about browser type, computer, location, API or URL path, etc. We are able to fix bugs much more quickly now, sometimes before the customer even calls in.
It’s been a fun road building software, and every day brings a new surprise. If nothing else, I hope investors and other agencies that get into the software business can learn from our mistakes and save time and headaches.
