Priorities: What matters most

First make it work, then make it right, then make it fast.
– Kent Beck

This is something I wrote a while ago. I think it still hold true to this day.

Last week, I had a rather interesting and illuminating discussion with someone. Our discussion bothered on some core concepts that almost every startup will deal with at some point; over engineering and time to market.

While I argued that getting your product quickly out of the door and testing market fit should take priority for every single startup, especially the ones venturing into new territories, my friend was of the opinion that getting engineering right from the onset before anything should be the focal point. His concern was simple, fix the engineering problem and save yourself from technical debt.

In the startup world, especially in emerging markets like Nigeria, getting your product out fast and testing it in the marketplace cannot be over emphasised. The whole idea of technical startup and digitisation, while not exactly new, our counterparts in the West have had over 20yrs head start before us. In this market, you have to, not just build, but also reorient people on why they should abandon their old, tried and tested ways of doing things to embrace this new shiny idea of yours. Getting to the market fast shouldn’t be taken lightly.

Reid Hoffman, the founder of LinkedIn now a partner at Greylock Partners, once said, "if you are not embarrassed by the first version of your product, you’ve launched too late." Speed and first mover advantage will win always. Not surprised he (Reid) is currently teaching a class on Blitzscaling at Stanford.

We have all heard it time without number that the customer doesn’t care what is happening under the hood. He or she isn’t interested in knowing if your data store is an RDBMS or a NoSQL data store. If your operating system is a Unix flavoured OS or a Windows server. He isn’t even interested in knowing if you wrote your stylesheet in vanilla CSS or you did go the Sass or Less route. He is interested in 2 things. 1. Does it work? 2. Will it solve my problems?

While writing scalable software and code cannot be ignored, it is imperative to note that if your product doesn’t gain market acceptability you are doomed. Dead. Your super sleek MEAN(Mongo, Express, Angular, Node) based app that runs on 4 Amazon M3 large instances with an elastic load balancer in front of them all using a MySQL RDS and a read replica will come to nut. Nothing. Nobody cares.

Product before engineering

Every hyper-growth startup today all started with less over engineering and in some cases monoliths; Netflix, Uber, Spotify, Dropbox, Twitter etc all ran really large systems and in most cases all in one machine. They were all super focused on the products. They all bothered about sleek engineering after they got a strong foot hold in the market. Today, all of these startups have broken things down in favour of micro services (smaller units of systems). You could argue that Travis Kalanic, CEO of Uber, isn’t an engineer, but I don’t think he bothered so much on how the first commit of the Uber codebase looked like. He just wanted a service that can/will allow users hail taxis using their mobile phones. Uber today is a ~$40B company, they can afford a star-studded engineering team. Heck, they poached almost all the scientist/engineers working on the self-driving car project at Carnegie Mellon University.

Why am I pro-product?

When Konga launched in July of 2012, we had one simple goal; retail. Our stack then was a simple Rails app that ran on a single 4GB machine. We didn’t even write the underlying e-commerce software, we used an open source solution called Spree and built upon it. No one cared. No one knew about it. We sold stuff, we were fighting an uphill battle, e-commerce, unlike today, didn’t have so much acceptability. We needed to prove to people that they can trust us with their money and we will deliver their item as promised. Today that one machine now spans fleets of servers and we are more than anything, favouring micro-services over monolith. Why? The time is right. We have gained to a greater extent, acceptability and we can afford to settle in now and build a rock solid infrastructure.

Does awesome engineering matter?

I understand why my friend favoured micro-services and doing things right from the get-go, for obvious reasons.

1. Micro services enable separation of concerns. No need to deploy an entire application when you only worked on a subset of it.
2. Scalability is easier
3. Deployment is a lot easier.
4. No single point of failure.

While all of these things are awesome and nice to have/do. For a brand new spanking startup, I still favour, speed, product market fit, acceptability(read as revenue) over awesome Google-esque engineering.

I live by this quote by Kent Beck - “First make it work, then make it right, then make it fast.”

A friend of mine just got into Techstars, his startup has a lot to prove. Awesome engineering skills isn’t one of them.