Good practices every startup should follow [closed]

Question

A couple of friends at work an me are going to set up a little startup / create our own software, probably moonlighting at first, since we cant yet afford to quit our day jobs.

Neither of us has have this experience, we've all worked for other companies before, where a set of guidelines are set, and I think this is the time to establish good practices to follow (like avoiding meeting-itis).

For people that have gone this way, what piece(s) of advice would you give us?

I'm looking more for the technical side of things, things such as:

• Is it worth to have some kind of build server or is that going to far ahead?

• Would you do extensive TDD or do you think it would be too much overhead for a small team that is not too experienced with it?

But wouldn't mind to listen to the management side of things.

---

The project is a web application done in ASP.NET MVC, I'm thinking of using Mercurial and BitBucket or Kiln + FogBugz or some other online project tracking tool, since we are going to be working remotely.

Answer 1

1. Release as fast as possible. Chances are 90% of the code you start with will not make it past the first 6 months. So there's no point in engineering it like crazy. Code as quickly as possible to get to market, then let your users decide how to develop it further. If TDD is how you code quickest, use TDD. Otherwise, just hack it. Early-adopter users are pretty forgiving of a few bugs when your product is in beta.

2. Don't waste your time being sys admins. You've got the right idea with hosted platforms for bug-tracking (e.g. FogBugz) and source control. Use an online document repository such as Google Docs. If you do store anything locally, use an online cloud backup service such as Carbonite. On your live environment, rent a fully managed hosting solution if you can afford it. Try to tend away from having to maintain your own servers.

3. Concentrate on what makes you unique. If you find yourself writing code that seems like it must've been done before, use what's already there. Become experts at solving your business problem and don't get distracted by problems outside your domain.

Answer 2

if the team is more than just you, standards matter. They don't have to be complicated ("use meaningful variable names, CamelCase, and don't break the build"). TDD rocks because it works, use it. The tests you come up with also make a great foundation for demos at the drop of a hat. A build server may be overboard, it may not; start without one and see how it goes. Tracking tools likewise; can add later as needed.

Assuming this product is to be sold, do some market research now, to make sure you're building something that people actually want. Outline a business plan to go from zero to market, divide responsibilities and equity, and hold each other accountable.

Good luck!