Lessons learned: How to develop an idea

Introduction: During my self mandated separation from technical projects and ideas last summer, I decided to try to put together a list of lessons learned during past (failed, yes all failed) projects. I quickly jotted some things down and my reasoning for them, and have cleaned it up a bit. All of it is pretty obvious, but hard in practice, and I probably emphasize areas that afflict me most.

This list mainly concerns software startups, but applies to business/project ideas in general.

What not to do:

Plan too much: Some planning is necessary. But you should plan for your immediate goals and be okay with a slightly fuzzy long term goal. You WON’T be able to see everything ahead of time. And trying to solve every problem in advance is very unlikely. You won’t completely understand what you need until you get there. So get there. Do what you can do, and work on the problems as they present themselves.
Wait to get started because of the one part that doesn’t work right: Similar to above. Unless it’s the innovation, don’t wait to get started because you’re not sure about a small part/library you should use/design pattern. Try something out, and if it’s no good, redo/refactor it later.
Wait to do anything real: Work on the feature that’s the innovation if you can. This is what sets you apart.
Not buy the domain: It would really suck if it was gone. For whatever reason, names mean a lot to projects, and are often a source of motivation for their innovation/stupidity more that the project itself.
Not look for existing applications/implementation: If people are already using a tool like yours, it’s going to be hard for them to switch. The cost of change will almost always prevent people from trying out your site if they have something in place. You must either be able to make their lives easier in a short amount of time (so you’ve got to develop what already exists + the small upgrades within the same time the small change can be expected from your competition) or have an innovation that changes the way that tool works and demands a change.
Expect immediate success: Keep your eyes on your immediate goals. Don’t give up unless there’s an obvious reason to.
Need an amazing environment: You don’t need to have the most amazing development setup ever. Spending all your time trying to make yourself more efficient only makes you efficient at thinking about how to be more efficient. Do something.
Have to use the latest tools: Unless this is your goal, or you absolutely need something from a language/library, get it out there quickly by doing it the way you know how right now. If it’s modular, you can drop in another library later.
Take forever selecting a library: Test things instead of thinking too much. The best way to learn is to start writing example code.
Expect people to care: they won’t. Almost everyone will think your idea is horrible.

What to do before you start:

Have an innovation/idea: This seems obvious, but I’m being serious. Are you actually giving something to your audience that they haven’t had before? Just because its cool doesn’t mean it’s useful.
Source control: It’s easy and quick to do, don’t wait. Invest some time in knowing the best practices. Only need to learn once.
Planning tool: Pen and paper, to do list, project management software. You need something that allows you to list what you need to do and their priority. The priority is just as important as what you’re doing. The priority should be determined by necessary dependencies and what makes your idea special. The more granular and organized your tasks, the easier it’ll be to know what to do next.
Always know what to do next: Thinking about what to do wastes time.
Set goals/deadlines: If you’re serious, you need to know when you’ll get things done realistically. It’ll probably still take twice as much time as you intend, but this will let you know what you’re in for and if you’re up for it. Make SMART goals.
Revise your plans at everyso often. Iterative development
Reuse whatever you can: Don’t make your own because you think it’d be cool. Unless there’s a fundamental reason not to, reuse. If it’s open source and there’s a change you’d like, make the change. Don’t rewrite it all.
Let people know what you’re doing: Explain to people what you’re trying to do and the problem you’re trying to solve. You’ll immediately gain insight into requirements, features, etc. They’ll probably think it’s a horrible idea, but find out why. If you can rectify this issue to yourself, then move forward. If they aren’t interested, you have a user base, and an end goal to keep you motivated.