Do the upfront planning
Since announcing my work on Fwd:Vault, a few friends have come forward expressing interest in being angel investors. From what I’ve read, most entrepreneurs have to seek such people out, so I’ll take it as a compliment that these friends either (a) really like me, or (b) really trust my technical and prowess. I’m leaning towards (a)…
Anyway, despite my obvious flattery at the offer, I always answer the same way…
I’m not looking for investors at the moment, no. My goal is to get this thing off the ground with zero incurred debt or outside investment, and grow with revenue. That’s the beauty of a dotcom startup: depending on what you’re doing, if you put it together the right way the first time, it can largely run itself.
Think about that. After several months analyzing technical requirements, programming, support, customer service, marketing, etc., I’m confident that I can run the entire business in a solo fashion until reaching a certain point in revenue. The only reason I can do this is because I am setting myself up for a launch with as many core features and as few bugs as humanly possible. That will allow me to focus on customer support and marketing, both of which require that I not have my head buried in a computer screen 12 hours a day.
I don’t care what Michael Masterson says, “ready-fire-aim” will only create more work for you down the road. Don’t fire off projects half-cocked. Take the time to lay the groundwork, and you’ll reap huge benefits in the long-term.
Document collaboration
I couldn’t agree more with your assertion against “ready-fire-aim.” It’s always been my saying that “a little forethought goes a long way,” and in the case of technology, I’ve never heard of an instance where the time (and time is money) was put forth to lay the groundwork of the project properly, only to have it fail for technical reasons. From first-hand experience, I’ve seen “ready-fire-aim” prematurely impose requirements on software – and developers – lead to project failure due to technical issues. Anyone (even non devs) know the iterative “Think, Code, Test” cycle. It’s tried and true. You can’t skip around as you please.
I like your laser focus on building a great product first and foremost. The rest will take care of itself to a large extent.
“I’ve never heard of an instance where the time (and time is money) was put forth to lay the groundwork of the project properly, only to have it fail for technical reasons.”
Summarizes the problem and the solution. Perfect.