When building tech, think like an early-stage founder

We are surrounded by tech mammoths. Take for example, Uber. Uber's engineering is fascinating. It has a complex SOA to tackle scalability, reliability, maintainability among others. It natural to fall for building something as complex for your side project, startup or even at your day job.

But what we forget is that Uber started off as a monolith and only eventually moved to having tons of microservices. So where exactly should you begin?

The trick is to think like an early-stage founder and build only when it's most essential.

If you prefer a quick read, check out this twitter thread:

Build tech to solve a business problem

I believe the very first thing you should do is to identify the core business problem. Your aim should be to solve this problem and use tech only as a facilitator.

Let’s say you decide to build user profiles in the first version of an Uber-like app. Think again. Is this something that satisfies a business need or a feature your users really need?

When you are building a service like Uber, the core problem you are trying to solve is efficiency in transportation. Your primary focus, at all points then, should be to onboard as many drivers and riders into your community and to have as many successful ride completions as possible.

In terms of the product, you should always only build the components that are most critical to achieve your business goals. When building a product or adding new features to an existing one, you should at all points question what underlying business problem it aims to solve.

Build tech smartly and efficiently

It is also critical to realise that the success of your first product doesn’t depend on how robust a tech you build from scratch. But rather how efficiently and smartly you build it.

Let me substantiate this with an example. Say, you want to build a service that provides effortless and reliable transport to the airport and you are testing it out in the city of Bangalore, India.

You should probably be spending most of your energies onboarding and screening drivers, sending the word out about your service to as many people and having maximum successful ride completions. Starting by building a set of mobile apps, a robust backend and a smart matching engine is a recipe for disaster.

Instead, why not use simple forms to capture user bookings. To start with, you will surely only have a handful of bookings to fulfil. Your matching engine (connecting drivers and riders) then should simply be on pen and paper.

You might think of this as a trivial solution but we can actually break down use-cases and point out the exact (existing) tools/ products you can use to cover these use-cases. You will be surprised to see how effectively all our problems get solved using existing solutions, which are in fact capable of tackling 1000s of users and associated data.

In effect, smartness and efficiency is in using existing solutions or products to your advantage.

Speaking from personal experience

You might wonder why am I so sure that one shouldn't build tech unless absolutely necessary. Have I done something otherwise myself and failed?

You bet I did and wasted quite some time in the process.

We made this huge mistake when building the first version of Flexiple. We were convinced that matching the right freelancer to the client basis a number of parameters is extremely critical. So, we brainstormed, figured out the parameters, attached weights to them and had the entire recommendation engine ready on paper.

It looks perfectly fine till this point, however, we went a few steps ahead and built a service on Ruby on Rails which fetched freelancer data from our DB and pushed out recommendations in priority order. Yes! We actually had a small version of SOA/ microservices architecture you read about earlier live for Flexiple, even before having a single paying client!

The right thing to do, should have been to match freelancers to clients by hand, manually, at least for the first 100 or so successful engagements. Even post that, it makes sense to leverage existing tools/ products than building something entirely from scratch.

We were busy building a sophisticated matching engine when we should have focused on having as many successful engagements as possible.

The irony of the situation is that many reputed VCs we were speaking to, at that point, were also keen on seeing the recommendation engine in action rather than the mechanics of successful client engagements!

As opposed to this, I remember being a part of the early discussions on Adobe Knowhow (consumer offering now discontinued). This eLearning platform was built to primarily deliver quality handpicked courses around Adobe’s creative suite of products.

It was decided that the platform would be launched with ~75 courses and naturally, the platform would have user recommendations. Now, it is not so tough for an engineering team at Adobe to build a recommendation engine into the product. Yet the PM for the platform was keen on having manual recommendations in the first version and the recommendations cloud was entirely hand-drawn on paper!

Closing thoughts

There's definitely a lot of sophisticated tech we see around us and it is natural to fall for building the same things in your product, even if you know something simple could work.

Hence, it is critical to take a conscious step back and rethink if you really need to build a particular feature or even the entire product. The golden rule is,

Unless you realise that the absence of a certain feature has created a bottleneck in business outcome, it is surely an unnecessary feature.

I write regularly about tech, product & startups on Twitter. You can follow my updates there.

I always recommend working on your startup on the side, while continuing your full-time job. Take the leap only when after you see initial traction. One of my friends did the same with her website, Writer Alpha.