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.

Engineering Mistake #6. Failure to Fully Research Database Encoding and Defaults

When I had originally set up the database I just went with the MySQL defaults without too much research. I ended up with having latin1 database encoding and had no real understanding of the storage engine being used. What I really needed was to have default character encoding of utf-8, and the storage engine to be InnoDB.

If you are wondering what your own database storage engine and character encoding are, here are the MySQL commands to check that.

Check the storage engine that you are using:

select table_name,engine from information_schema.tables where table_schema = 
'your_database';

Check the character encoding of your data in each database table:

select c.character_set_name from information_schema.tables as t,
 information_schema.collation_character_set_applicability as c where c.collation_name = 
t.table_collation and t.table_schema = "your_db";

To change a table’s character encoding to utf-8:

ALTER TABLE tableNameCONVERT TO CHARACTER SET UTF8;

To change the storage engine to InnoDB:

ALTER TABLE tbl_name ENGINE = InnoDB;

Engineering Mistake #7. Lacking PHP Experience Yet Building a Live PHP Application

Prior to working on the ComeHike site, I was primarily a Java programmer. The trend with Java is fewer start-ups are using it as their primary language. New start-ups tend to choose newer and more nimble languages. If I was starting ComeHike today, I probably would have chosen Ruby on Rails. When I was starting ComeHike, I knew how to get the application up and running within minutes using PHP, so I chose to prototype in PHP.

The idea was always that if the site matures, I’ll switch to a “cooler” or trendier language. But switching languages and platforms always seems to be a lower priority than bug fixing, talking with customers, or adding new features. So naturally I have never gotten around to switching platforms or languages.

When I started with ComeHike, I knew PHP at a pretty novice level. Since my goal was to rapidly iterate and constantly improve the site with new features and bug fixes, you can imagine the problems caused by the combination of my “haste makes waste” approach and my novice level knowledge of PHP.

Many of the problems rooted by my “hacking around” still sometimes resurface on the site as users find new and creative ways to expose them.

Engineering Mistake #8. Focusing on Development Speed Rather Than Quality

Ultimately, in trying to iterate very fast, I produced many poorly made features that turned off my users. The ideas behind the features were not bad, but the execution was poor due to too much haste and at times lack of discipline on my part. The haste was natural because I was very excited to put these features out into the world and show them to potential users. But as someone trying to create a nice community and useful site, these mistakes were very damaging as showing low-quality and buggy features to users turned them off more than excited them.

Over time I had to adjust my approach and discipline myself to be more patient with features, and make up for being able to produce less features by being more selective about which of the features get built and which get rejected.

Engineering Mistake #9. Didn’t Keep SEO Up to Date

At one point, a large number of content pages on ComeHike were ranking in the top 10 of Google search results for thousands of long-tail searches. This gave the site 150% month-over-month growth in traffic coming from search. Then, suddenly, the growth stopped and actually fell quite precipitously. As a site owner, you can imagine the emotional uplift of seeing the site on which you worked so hard experience such amazing growth. You can also imagine how disheartening it was to lose most of that traffic after being penalized by Google after its Panda search algorithm update release. The road back to being de-penalized by Google is an emotionally difficult one that requires lots of work and patience.

Here is a very quick checklist for what you can do to avoid being penalized by this new Google update:

• Do not have thousands of auto-generated pages with lots of overlapping content.
• Make sure your content is original.
• Make sure your pages have plenty of high-quality content that is so good that it would be recommended by people to their friends.
• Do not have a high ad-to-content ratio.

To take the low-quality pages out of the Google index, simply add this tag to your header for those pages:

There is much more to the topic of Google’s Panda update, but for this article, I wanted to caution you not to make the same mistake with it that I made.

Engineering Mistake #10. Treating Engineering as the Means to an End

This is a more holistic point and maybe a realization that I inadvertently came to as the site matured. I faced various consequences for underestimating or undervaluing the engineering depth that is needed to create a robust site.

It was easy for me to fall into that kind of a trap because many signals indicate that technology is rapidly becoming a commodity. Putting up and maintaining a site has become ridiculously cheap. Development costs also have shrunk as now one person can do what it took a whole team to do 10 years ago. And if I make engineering mistakes, the various cloud-based solutions can accommodate my oversights.

In hindsight, I came to realize that I was mistaken in such thinking and that mindset led me to make numerous poor engineering decisions for the sake of more rapidly bringing features to market. In my impatient hurry, I did not see some tasks through until the end.