We never make mistakes. Our endeavors have flawless execution. That is how many of us secretly hope to be perceived in a professional environment. It's not easy to admit flaws and mistakes, but in this article, I'm going to share the top 10 engineering mistakes I made with ComeHike.com.
The errors I'll discuss may not be the most glamorous and may be only anecdotal, but they are real mistakes I made. They were often influenced by business factors, difficult decisions involving complicated trade-offs, and sometimes my own lack of discipline due to over-excitement and impatience or -- dare I admit -- lack of experience in various aspects of building a company.
Mind you, for a long time this company was just me, and I had to quickly gain proficiency in every aspect of running a company, including marketing, PR, engineering, strategy, and figuring out how to actually have the site make money. The last thing I wanted was to end up with a failed startup.
Engineering Mistake #1. Insufficient Attention to Design
The Web community has been involved in a consistent and ongoing debate over the importance of design on a website. This debate is almost as old as the Internet itself. Nearly everyone recognizes the value of having amazing design, but there also seem to be never ending arguments citing Craigslist or EBay, which are stark examples of sites that defied the apparent need for great design, and have found success by simply being useful websites.
This ongoing debate is all theory. In practice, I originally hoped that simply having OK design would be enough in at least the beginning. That was a mistake. The success stories of sites with unimpressive designs are not applicable today for a number of reasons. First, those sites got started mostly during the early days of the Web. Second, good design is simply the "price of admission" for a legitimate and trustworthy consumer website.
From the original, pretty terrible design of the ComeHike site to what now can be said to be at least decent design, users complained about the design at every step of the way. People are still often unhappy about various aspects of design and usability. The original poor design of the ComeHike site surely drove away many users who could have otherwise been more inclined to try out the site. Those users could have given the site a stronger initial-user foundation, which would have resulted in better feedback. Instead, the site immediately lost credibility in the eyes of new visitors by being so poorly designed, and the lack of design probably drove away many people who never came back.
Engineering Mistake #2. Lack of Security Awareness
One particular security flaw the site had in its early days came as a result of my being new to PHP. Whatever language you are learning, make sure you "neutralize" the input, in particular strings that come into your site from various forms or other inputs.
In PHP, the solution is to neutralize the strings like this:
$safe_for_db_insertion = mysql_real_escape_string($incoming_text);
Every language has its equivalent method of neutralizing strings. If you do not do this, the most basic hack script can insert and read data into your database, or even delete your database entirely.
During the early days of the site, this type of a hack attack happened to me. Luckily, the hacker just wrote "hello :)" in one of the tables in my database, and helped me realize just how exposed the site really was.
A general rule of thumb for protecting your site is to not trust any input. If the input is supposed to be numeric, make sure it is. If it is supposed to be of certain length, make sure it isn't longer than that length.
Engineering Mistake #3. Insufficient Thought About Session Lengths
One thing that really damaged the growth of the site was being overly cautious and allowing people to stay logged on only for periods of under one hour at a time. After one hour, the sessions expired and people had to log in again. While such a short session time helped protect users from having their accounts compromised by people using the same computer if they forgot to log out, it also annoyed many users. I received complaints about having to re-log in all the time. After numerous requests to "keep me logged in forever like Facebook does," I gave in and extended the default session time.
After I extended the user session time to be much longer, I noticed an increase of repeat users as it became easier for people to keep using the site. I only wish I had extended the session time earlier as it would have helped adoption.
Engineering Mistake #4. Building Too Many Features
One problem I created for myself was building way too many features. On one hand, the early stage of a site is when you are supposed to do the most experimenting. Mistakes are cheaper to correct and you have to try out many different things to see what works. Most experiments won't work, but a few will.
That sounds like reasonable theory, and I find myself still agreeing with it more than ever, but there is much more to be said about the kind of experiments an early-stage Web company should undertake. A big mistake I made was creating features that were a decent but not great compliment to the overall product. Features that do not compliment the core product tend to defocus the product.
One such feature that was not a great compliment to the core product was a tool that allowed hikers to indicate which wildlife or plants they saw and where. The tool sounds interesting, but that was a bit of a failed feature since it didn't add to the core product and was not completely trivial to build. The ComeHike site is for hikers. Many hikers don't really care about wildlife.
An example of an experiment that worked out is something that actually helped hikers like the maps of the hike route and carpool to get to the hike, both of which you can see in action on this hike page.
Engineering Mistake #5. Not Enough Testing
This is a start-up and there are no testers. But there are a number of things that can be done to help automate testing such as unit testing or simply devoting more time and care to testing manually. While I manually test for bugs and user experience (UX) problems as much as I can, I am embarrassed to admit that there are still no unit or automated tests.
I constantly get bug reports from the users of the site. Sometimes thanking the users for letting me know about the problems on the site and quickly fixing the problem can help forge better relationships with those users. Unfortunately, I have no way to measure just how many potential users of the site were driven away by poor design or confusing UX. That is something that can only be gauged by measuring the conversion difference between older and newer designs of the same page.
If you do have an under-tested site, one shortcut and common sense practical approach I recommend is to make a list of all the pages your users see when they come to your site. These are pages people land on from search, social traffic, or links you post on other sites. Make sure that at least the subset of your site made up by those pages are tested as much as possible. That way you significantly limit the number of bugs your users may find because the remaining bugs will be in deeper pages that fewer users will ever get to and the pages your users do see will be more polished.
Additionally, repeat the same tactic for all your "conversion" funnels. For example, one of the goals of ComeHike.com is for people to find hikes and hiking groups as easily as possible, and register for them. For that reason, the home page has a search area above the fold. The search area serves up hikes and hiking groups. It isn't perfect yet, but it is what the large majority of the site's users try out. So before I test any deep pages, I always try to test the search area. In fact, by now I know some bug may have crept into the search area if there is a drop in signups to the hikes.
But all this does not make up for not having unit tests and other automated tests. Not having these is something that has definitely hurt the site and was a big mistake on my part not to have spent sufficient time on it. It is something I will be addressing in the very near future.