Last summer, I had the pleasure of joining Adam & Dan from Ignighter, at Techstars.  I was their lead developer.  Techstars is a seed-stage mentorship driven startup incubator, and it was my job to get Ignighter.com off the ground, and into the hands of 20-somethings everywhere. In the spirit of passing along what I”ve learned, I”d like to share a few things I wish I”d known about starting my startup as the youngest (and, in hindsight, least experienced, and maybe the most humbled) technical co-founder at Techstars 2008. Although many of these lessons I”d learned the hard way, maybe they will serve as a checklist of action items for you, to avoid the mistakes I”ve made.

This post”s intended audience is current & future Techstars technical co-founders, though many of these lessons apply equally to any technical folks who”re launching their own consumer web startup.

These are some of the practical software-development best practices that I somehow missed during the first 3 months at Ignighter:

1. Use source control. If there”s one thing I”ve learned, it”s that sometimes, you just gotta revert what you”ve done. Sometimes, you may need branch your source code in two directions. It”s best to have source control in place now, rather than waiting until you need it. I recommend subversion, but have good things about Git.

2. Log everything. If you”re only human like me and are on an intense delivery timeframe, you”re bound to make a mistake or overlook something. 404 errors, user input, slow scripts, or any other sticks-in-the-spokes problems. I log it all.

3. Get a designer. A lot of programmers just can”t wear both the design hat and the coding hat. Myself included. I try to adopt the mantra: ”suck less every day”. But, in the meantime, find someone who knows what they”re doing, and use their stuff. I recommend Techstars Sponsor, Slice of Lime

4. Don”t open up your system to the public until you”re ready. Two words: brand dillution. Ignore it like the plague, at least until your shit works.

5. Use standards compliant patterns. I can”t tell you how many times I tried to take a shortcut at the expense of learning & using the standards-compliant way of implementing a solution. Save yourself the hassle. Just do it the accepted way, erhm, the right way, the first time.

6. Don”t get attached to your code. There”ve been a few times when a business reason developed in which a certain area of our site wasn”t needed anymore. I”ve found that it”s less painless to let go. Just… let… go. I always try to remember: Biz dev sets the strategy. Development executes.

7. A/B Test. At many times, our team would find ourselves at an impasse over the direction to take a feature or design. Sometimes, rather than a spirited debate among ourselves, implementing features both ways and testing how actual visitors respond is best.

8. Find good help. Whether it”s through the techstars mentor network, the Boulder community, or a new hire in your company. If there”s a skillset you”re missing, look to fill it. You”ll never have a better network of talented young developers than you will this summer.

9. Develop code quality standards, and stick to them. I was nearly driven insane until our team adopted a strict MVC pattern. ”nuff said.

10. Develop a rhythm. It helps build a sense of progress and a weekly deadline to shoot for. Product meetings on monday. Log review day is on friday. QA is on friday. We release on Mondays.

Good luck with everything. Oh, and don”t forget to enjoy it. 2008 was a landmark summer for me, in no small way.

I”ll see you around the bunker. Oh, and you can follow the musings of the ignighter team on twitter at @ksowocki, @danosit, @arsachs, @aycaaksu, and @nleach.

Note: Any information of proprietary value to my employer has been removed or approved, and this post has been approved by my employer.