Often people rush to get their product out the door. From idea to customers in a week. Although that might sound appealing at first glance, there is a big downside: it limits your startup ideas to those that are very easy to build. You can’t do any cool tech in a week, nor in a month. Good software takes 10 years, as the classic essay goes.
Any time you create an MVP there are two outcomes. Either it turns out your idea has some legs and you continue building. Or you discover that your idea was no good. This means your MVP can’t just be a couple of screenshots or a splash page. You might use that to drum up some initial interest, but it can’t tell you whether your product will be any good. For that you need to make the thing and see if people want to use it.
And if you can make the core of your product, at least enough for it to be usable, in a week (or two) then other people can as well. It means there can’t be any real tech beating at the heart of it. The startup has to be about something else. Perhaps it’s some kind of #nocode tool that links together a couple of services. Nothing wrong with concepts like that, but if you can get your startup off the ground without having to build any tech innovation then it’s not going to be a tech startup and you won’t have a corresponding competitive technical advantage. More importantly, we enjoy coding and simply want to have a startup where the technical quality of the product matters.
We’re giving ourselves closer to 4 months (80 days is 16 weeks) to build our MVP, for an idea that is as conceptually simple as it gets. We want to build something in this productivity space that hasn’t been done before. We have some rough ideas, but we can’t know yet if we can turn it into a cohesive whole. That means prototyping, and sketching, and more prototyping until we have something that we think is original, visually distinctive, and shows real promise.
Now that we’re more than a week into our startup it’s becoming evident that even if we scrap everything that’s non-essential there is still a lot left to do. We’re thinking of building our own editor environment from scratch, with real-time multiuser support, and all sorts of synchronization logic. Extensibility? Maybe. In any case, there are many design decisions to make.
We’re doing #buildinpublic because it puts us out of our comfort zone. It’s easy to adopt a “it’s done when it’s done” philosophy, but that isn’t wise. An 80-day deadline forces us to focus and hopefully that will result in us making better product decisions. It’s a tight deadline, but not impossible.
Let’s see if we can build some substantial tech in 80 days. We’re choosing the hard path and we’ll find out soon enough.
@wcools