When you're in the early stages of a tech startup, you're at a unique and golden moment. Flexibility and free thinking abounds because nothing has been built yet. The moment you choose a direction to take your company, and you put work into that direction, you begin to build rigidity. The increasing rigidity that occurs with more development will inevitably turn into fragility. This becomes obvious when you realize that you missed a use case. At that moment, you realize how much work needs to be done to change course.
The purpose of this article isn't to toss out some secret sauce on how to do development but really to point out how important the first moments of a startup are. Once you commit to a direction you will not easily be able to turn the ship, so let me provide 3 signs that you've done your homework.
1. You've spent a LOT of time looking at competing products/solutions
Is your idea unique? You might think it's unique but is it really REALLY unique? Have you spent at least 24 hours investigating competitive startups? I'm not saying that you won't proceed with a competitive startup, but you need to make sure you're walking into that prospect with your eyes wide open.
You won't believe how quickly your idea goes to the wastepaper basket when you take the time to ask these questions. I'm not looking to discourage you, but on the other hand I might save you a lot of time and personal money. I've seen really good ideas get way too much momentum because their creators chose to assume that they were first.
On the other hand, this can also be a startup strategy. Some of the most successful iPhone apps came about simply by studying a competitor and then making something slightly better... simple and brilliant.
2. You've dived deep into the uncomfortable coding effort
Because we like what we can control, people end up spending time on what they can relate to (or more easily describe), and we put the harder work in a parking lot to deal with later. We see this happen in our data integration consulting work all the time. It's very unnatural for business leaders to get down and dirty with code/data to answer the harder questions. So often we'll get specs that spend reams of paper talking about something which will take 20% of our time to build, but side notes on the more complex efforts which will take 80% of our time to build. And it's that 80% which really describes the more in-depth decisions on architecture, code bases, tools, and user interfacing.
Make a high-level list of all the things that must get done, even the things that you think are going to be easy, and then list them with your technical team. Then step back and ask yourself, "Have I left something off this list because we're going to do it in a second release? Or we're going to deal with that later?", then put THAT on the list. You can deal with your release phases in another exercise. NOW sort them by difficulty and explore the hardest first, and do it in the presence of somebody that knows the coding and data effort. Then step back and ask. "Can I release JUST the #1 most difficult task on this list to the market and make money from it?" This exercise alone can uncover opportunities that you didn't realize existed in your startup incubator.
3. You can justify your future fragility
You're about to make the leap from flexible to rigid when you start coding. The more you code the more rigid you become and the more rigid you become the more fragile you are to change. I wrote an entire article about this kind of fragility titled Why "born in the cloud" matters, which explores how easy it is for competitors to exploit a fragile company.
This rigidity is unavoidable if you want to scale and make money, so it's not something you should evade, but it is something you should respect. Meaning, you should be able to justify all your technical decisions. Write down and score your options and have a good reason for choosing your future databases, and back/front end code bases. Get outside help and opinions about your justifications for the decisions you're about to make. Look for opportunities to avoid getting stuck in a corner or putting all your eggs in any one basket. It might cost you money but it will be MUCH cheaper than changing gears later.
A Good Book on the Topic
One of my favorite thinkers on the topic of fragility is Nassim Taleb. He is a modern day philosopher, and I highly recommend his work. One book, in particular, speaks to the organizational structures that deal well with risk is called "Antifragile: Things That Gain from Disorder".
