The idea of perfection chews through us all. If you're a technical person, trust me, you have it worse than the rest.
Intro: Getting everything right.
As techies, we're accustomed to writing neat code, respecting best practices, following guidelines and asking for clear requirements each and every time.
But this shines a bad light on us when we try to go the entrepreneurial route. It doesn't matter if we're building the next <insert-social-media-network-name> or that we're building Uber but for <insert-weird-made-up-industry-name>, it has to be perfect.
If possible, it has to be even better than the thing we're cloning.
We all know those developers from Facebook store their passwords in plain text... we're going to encrypt everything thrice!
What all of this does is kill "done" and "good enough".
And more often than not, good enough is all we need to validate a market, to see if there's potential, or to serve that market directly.
What's with this article?
Why am I writing this? Because I've been through it a couple of times, either with my own idea/product or with someone else's idea upon which I've built. If you pair a technical founder with someone who has trouble focusing, you get a recipe for failure.
Can you imagine a stack of money representing the startup's initial capital, but with a hole burnt straight through the middle?
The flame burning through the stack is "perfection".
Perfection deems everything that's good enough not worthy of attention and exposure. It's what keeps you from launching your app with a good enough design, because it doesn't respect some weird design principle.
A — not that old — story.
For example, in 2017 I spent about 6 months designing, redesigning and implementing an application that would enable you to post tweets that would act like snaps, on Snapchat. It was called Ephemeral.ly.
I felt pretty good about working on it but I don't have to tell you that Ephemerally was no hit. It had two users: me, and an ex-coworker who was polite enough to sign up.
My idea was that freelancers and other professionals would love to keep a clean Twitter feed although they might sometimes want to indulge in some satirical retweets about Trump, for which they don't necessarily want to lose a contract with someone who fancies Trump. So I put my head down and plowed through.
I spent a couple of weeks browsing Dribbble and trying to get design inspiration — I'm not a designer. I ended up completely cloning one of the designs I found there.
I implemented everything, front-end and backend. I also spent time setting up infrastructure in AWS, load balancers, Elastic Container service and a ton of other services.
It has to scale, right?!
Wrong! It doesn't. It has to be used.
Once done, I realised my design (clone) was crap! So I ended up redesigning it, by tweaking some of the elements. It was still the same design, and the result was crap, too.
So I went and bought a theme from Themeforest and coded the front-end again, using the theme as a design guideline.
It wasn't the brightest bulb in the chandelier, but it was usable and from my perspective, the end product looked more like a web-app.
As I mentioned, I spent about six months working on this, all while I was also working almost full-time on contract work. I put a lot of unnecessary pressure on myself, and although I learned a lot, from a technical perspective, and later from a business/managerial perspective, I burnt myself out for no reason.
Needless to say that nobody used the app.
But there's an upside to this: the learnings were invaluable.
The learnings.
Just ship something.
If it looks decent and works moderately well, just ship it and see what happens. The fact that you're small and literally unknown allows you to ship in steps without upsetting a lot of people or tarnishing your reputation.
Look around, ask around.
Find out whether there's a market for what you're building. Preferably before you write a single line of code. Focus on asking questions and listening, more than you focus on pitching your idea and trying to "sell" people on it.
Scratch a personal itch.
If you're the first beneficiary of your product, you're able to formulate requirements, at least in the initial phases. You're also far more likely to enjoy what you're doing and be more creative with the solution.
Don't get overly creative.
It's tempting to set up a full-blown, cloud-agnostic, microservices-based infrastructure/architecture but this could quickly become a time-suck.
Remember: Your product doesn't have to scale, it has to work.
Watch it fail, make it work, make it better. This is something I learned from doing TDD for a ton of years. Think of this as the Red-Green-Refactor of product development.
Outro.
I'd love to hear your thoughts on this so do shoot an email or use the contact form. I'm open to adding people's contributions to the articles on this blog, as its primary goals are to give everyone a voice and educate whoever lands here.