You’ve got a great idea! You want to build a web site that saves people time and money and helps them make friends! You’ve written a rough business plan, now you want to find someone to build your site.

Software development is complicated, expensive, error-prone, regularly boring and complicated. As a programmer, here’s what I think you should know before we meet for coffee.

1. Avoid developing software

As a general rule, you should avoid doing anything you don’t need to do in a startup or new project. You have plenty of things to worry about. If you can possibly avoid writing software, do so. Need a website? Use WordPress. Intruders.tv and I Can Has Cheezburger are 2 great businesses built on WordPress. Need something like a social network? Use Ning. Prove that you can build the community, then transition to a bespoke platform to build features. Since 2004, an amazing number of high quality, free or low-cost tools have come on to the market. Tools don’t have to be perfect. Maybe half your product is already implemented by someone else’s API. Use that, build the other half. Worry about strategic risks later. You’re prototyping remember.

2. Software is complex

Software is complex and fragile. Even a simple piece of software is many times more complex than a car engine for example. Even simple web apps built with standard tools don’t tend to share that many common parts. Understanding an application later and modifying it is really a very complex task indeed.

It’s many times easier to change an idea or a document or a diagram than to change software. Try to make changes early and avoid making them late if possible. The agile methodology, building software bit by bit in short sprints, makes it more likely that you’ll change something before it’s been coded, tested and deployed.

3. Don’t make a big long list of features stretching until the end of time and space

Decide what the very core of your offering is, find out if your customers are interested and build the minimum that can solve their problem.

This approach costs less and is less risky than building your perfect dream. When you have the minimum viable product built, solicit feedback from your customers. By making the big list, you’re second guessing what they want. You’re probably wrong.

Ideas happen much more quickly than the code. An idea might take a day to think through and a week or a month to implement. If you make a list of features, those features will be irrelevant by the time the programmers get around to building them. Stay in the moment. Keep the list to what your customers are asking for today.

4. Let your developers (and designers) do their job

Cheaper development teams are great when you have a known problem and a known solution. When you’re launching a new product, you have only one or neither. Communication is critical, but it’s also important to respect the software development process. Remember that writing software is complex, boring and error-prone. This means most of the time, developers have to get their heads down and work, work, work. I find 2 weeks a good length for a block of work because it gives a good mix of regular points for communication, keeping the product connected to reality, and time to get things done.

Be flexible enough to create an environment where your team can get on with delivering a great product, and you can get on with everything else.

Bonus point: If you engage a designer, let them design. You have to be proud of the way your application or site looks, but you are not the customer, the customer is. Experienced designers are good at making things that work well and look good for the larger audience. Try not to make personal judgement, like “I don’t like that grey.” Your customers probably won’t care as long as the site or service looks professional and is easy to use. If you have A/B test data to show that the grey has lower conversion rates, that’s different (Google actually tests different shades of blue).

5. Don’t micromanage

This is kind of the same as the previous point, but it’s vitally important for software. If you’re launching a product and you start involving yourself in the minutiae of development, you will slow the process down hugely. Development takes focus, handling a micromanaging client takes time and destroys that focus, leading to mistakes and delays.

Let small decisions go. Revisit them if they really are wrong. You don’t know if your product will be a hit yet. You need to get something out there as quickly and as cheaply as possible. If it later turns out you need to change the core product (which you almost certainly will), all the time spent fine tuning before launch is time wasted.

6. Software is only part of the puzzle

Finding money, figuring out a product and having it built is not easy, but it is well understood and, given a sensible spec, can be acheived in a finite amount of time.

Most new products don’t fail because the implementation was bad, they fail because the customers never came. Make sure the customer is there before you start. Make sure you know where they will come from, why they will use your product. Make sure you know this inside out. It’s very possible that your idea, though neat, isn’t a workable business. You really want to learn that before investing time and effort in building a product. The New Business Road Test is an excellent book on evaluating opportunities.

7. Rewriting is common

Once a piece of software has been around the block once or twice, the task it’s being used for ends up pretty far from the one is was intended for. Maintaining it becomes increasingly difficult. At this point, it’s time to consider a rewrite. This is a good thing. New tools and practices will have emerged that you can take advantage of. You know more about the business you’re in and you can cut out the features you don’t need and concentrate on making the ones you do much better. Rewriting is good. Plan to rewrite. Get stuff done simply and quickly at first, revisit it later when you know more.

This is a controversial point. Trying to change software is like trying to change a car into a boat, it can be done with time and effort, but building a boat from scratch will be easier and the final boat will keep water out better, go faster, look nicer and generally be more fit for purpose. Data from NASA cited in Facts and Fallacies of Software Engineering suggest that if as little as 30% of an application needs to be changed, it is less time-consuming and expensive to start over.

And finally…

There are many great books about software engineering, but I can personally recommend none more than Robert L Glass’s Facts and Fallacies of Software Engineering. It is a mine of empirical data about what makes software projects succeed and fail. If your company’s business is making software (which it is if you’re a web business), you need to read this book.

There are also a number of great websites about startups, few are finer than Eric Ries’ Startup Lessons Learned. Read it all. Twice. Carefully.

The New Business Road Test is a great tool for stopping yourself from diving in to an ill-advised venture. Reading it may save you a lot of time and money and prevent hair-loss.