— This post, ‘develop a rhythm’, is part of a series of ongoing tips on lessons learned & experiences I”ve had as the lead developer (startup CTO if you want to be fancy) of the online dating startup, at Ignighter.com. Though these tips are focused primary at consumer-focused startups, they ring true elsewhere too. For a full list of these tips, see 10 things I”d wish I”d known as a lead developer at Techstars. —

One of the most crucial things our team did over the last year was adhere to a rhymic development schedule:

Every Monday, we release code from our development region, to our production region. For the rest of the week, we analyze our business requirements, design accordingly, and implement new features in our development region.

This allows us draw a line in the sand when it comes to prioritizing features. It allows you set firm targets and deadlines. Abstract questions like “Is feature X more important than feature Y?” become more practical. The conversation becomes: “Can you get both feature X AND feature Y into the release on Monday?” , “No? Ok, how about just feature Y, then?”.

It also allows us to break projects into manageable chunks to iterate on week over week. Iterating, measuring results, and repeat. It”s a fantastic way to stay agile. And staying nimble & agile is the goal for the development team when you”re trying to find the ~right~ product for your market.

On to the details:

What day do you release?
We”ve had a lot of internal debate on what day of the week to release. We chose Monday because it allows us to start fresh and focus on new priorities for the week (Provided there were no issues with the push).

How long should your iteration cycle be?
My team releases weekly. I”ve heard stories of many other startups who release weekly. Some release daily. I”ve found that the overhead involved with pushing code live is too great when pushing on a daily schedule. Anything over a week, and I”m concerned that we aren”t iterating fast enough.

How much effort do you contribute to QA?
Quality assurance is a major concern when you”re developing a consumer app. In my opinion, it”s best to design multiple levels of QA into your process, executed throughout the week. A suite of unit tests helps to catch bugs introduced throughout the course of a week. Next, each team member is expected to troubleshoot and certify their own features by release time. We also do a weekly QA session in which we catch bugs before we do the push.

Do you follow any ”development methodologies”?
No. For now, we”re wary of adding too much process too early in our company. Though, we do regularly study our process and evolve it as needed. Agile looks like an interesting option for the future. As does Lean Programming.

All in all, your release rhythm will probably depend a lot on your product, market, and most importantly, your team. When making decisions about your development rhythm, start with the low hanging fruit, like ”How long do we want our cycles to be?”, and ”What time of the day/week/month/quarter do we want to release?”, and move on from there.

Oh, and don”t forget to have a fun through the process. One of my favorite parts of being in a small team are the fun little events (LAN parties, dinners, lunches, etc..) that we schedule to celebrate a big release.

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