Startups Anonymous: When building a startup, where do you start?
[This is a weekly series that brings you raw, first-hand experiences from founders and investors in the trenches. Their story submissions are anonymous, allowing them to share openly without fear of retribution. Every Wednesday, we’ll run one new story chosen by Dana Severson, who operates StartupsAnonymous, a place for startups to share, ask questions, and answer them in story-length posts, all anonymously. You can share your own story here.]
When building a startup, where do you start?
I struggle with this question at least a couple of times a week. Every so often as the technical cofounder, I feel overwhelmed at the sheer magnitude of what the solution to a problem could be -- or even what the problem is in the first place -- and how clueless I am on "where to start."
That's because, most often as you start working on the "next glamorous cool idea that will change the way the world works," we almost always underestimate what needs to be done to get it working. Yes, a prototype is easy, but then the tough questions arise:
What platform do you use?
What cloud provider do you go with?
Do you use a known language or pick up a framework?
Do you stick to grand pluggable design or something that just works?
When do you worry on scale/performance, when do you start on UX?
Do you just hardcode the little stuff or a whole path to get your MVP out?
Every turn seems to have options and possibilities. And because you are building the "next big thing," there is almost nobody who has done something similar -- unless you are just cloning somebody else's app or service.
As easy as it seems to find others who have gone down your path, most information does not give you a definitive answer. And as you start piecing the parts of the puzzle together, you realize your puzzle is unique, and some of the pieces need to change.
So again, where do you start?
My basic rule of thumbs that have helped:
Lean on what you know: Go with a language or a framework that you reasonably know, or think you can learn. Language familiarity helps things to move more quickly.
..,but learn fast: In totally unknown domains... read, read, read. Read developer blogs, Stackoverflow, and GitHub repos to get a fair understanding of how things can be structured. In my case, coming from an enterprise software background of 15 years, cloud services and the whole infrastructure almost stumped me. It took a lot of reading and experimenting to get my mind around what is possible in a new domain.
Dump quickly: Be prepared to dump code, framework, platform... anything. Which means your mantra should be, "just get the code to work." You will almost surely hate your design architecture unless you have done similar stuff earlier.
I think the question, "Where do I start?" even in a tech domain, has the same universal answer: "Just start and you'll find your way"
How did you overcome your hurdles?