The Engineering Startup Dilemma: Build It the “Right Way” Now, or Later?

Douyin (known as TikTok outside of China) was launched in China in September 2016. The product was developed in 200 days, and within a year got 100 million users with more than 1 billion videos viewed every day.

So, let’s do the math: 6 months to build and 1 year to get 100 million users. A year later they bought musical.ly for $1B and now they are truly a global phenomenon with hundreds of millions of users and billions upon billions of video views.

It’s an incredible story.

However, it’s promoting a narrative for many startups that they have to scale quickly just in case they get the same traction as TikTok, Wish, or many of the other growing apps.

In the past 18 months, I’ve personally seen an uptick of clients (startup and enterprise) asking for their products to scale even before the first line of code has been written.

I’m a wishful thinker. I like to think big, and I like others who think big. Honestly, if you don’t think big, you’re going to have a hard time building a company.

However, I try to remind them of how some of the greatest products we use every day looked when they first got started.

• Instagram:

  • iOS only for the first X million users
  • You couldn’t zoom in on pictures
  • Square pictures only

• Twitter:

  • 140 characters for a decade
  • No ability to do “tweet storms”
  • No threaded replies

• Facebook:

  • Colleges only
  • One profile picture and no albums or other pictures allowed
  • No ability to write on their wall.

 

The leading products didn’t have a huge infrastructure to start with. They also had real limitations to what they could build.

However, nothing gets me more excited than scaling an application.

It’s never been easier to scale a product, which causes companies to over-engineer products.

Early in the software development process, engineering teams have this struggle:

• Build it the “right way” now, which will take longer, but will save us time later OR
• Build for right now, which will help us get to market faster, but will cause issues later.

Take too long to build the first product, and everyone is unhappy. Take too long to fix something down the road, and everyone complains that it wasn’t built properly.

Cloud companies (Infrastructure as a Service), and Platform as a Service platforms are making easier than every to deploy and scale applications without knowing anything about infrastructure or servers.

Here is what I recommend:

Build for precision, traction, and speed, not scale.

Let’s talk about the app Wish. They raised over $1B in one year, have over $1B in annual revenue, and have rejected offers by many large organizations, including Amazon.

Wish started as an app where users could create wishlists of their favorite products, and was monetized using a pay-per-click model. It then pivoted to partner with other eCommerce companies to sell low-cost, off-brand products. Connecting third-party sellers to buyers through Wish.com turned out to be the business model that would sustain their growth moving forward.

I don’t have inside details, but one could only assume when they started with their wishlist product, they didn’t over-engineer it because they knew they were eventually going to pivot.

When we start with new clients, I have the same pep talk with the engineering team:

Keep the end goal in mind.

A beautiful, well-engineered product that nobody uses is a failure. Nobody, especially the client, cares about the technology stack. Whether you used Hadoop over MySQL or cloud-native serverless on Amazon vs. on-premise.

The client does care about a few things:

• Does the product do what it’s supposed to do?
• Is the product reliable (i.e., no bugs)?
• Are more people using the product today than the week before?

Because of this, our engineering philosophy has been consistent since day one

• Don’t over-engineer — We’re not building applications so our resume says we have the latest and greatest technology stack that only Amazon, Google, and Netflix use.
• Code precisely — Build exactly what’s needed in the best way you can. If you can save a few lines of code but you have to introduce two new libraries to do it, then keep the two lines of code in.
• Build QA into everything — We place a large emphasis on QA and Test Planning as part of our Agile sprints.
• Technology debt is OK (within reason) — Initially, build for speed and quality. Focus on the core features, even if that means introducing some technical debt you know will have to be fixed later. A product with zero technical debt usually means the product has been shut down. Focus on traction instead.

TikTok has 10,000 people manually reviewing content.

It was just revealed that TikTok has 10,000 people manually monitoring content. TEN THOUSAND!

That is approximately ¼ of their entire company of people monitoring user-uploaded content. We often talk about AI and machine learning, but it’s good to know that 9 times out of 10, basic technology and human intervention is still your best bet.

So, when you or your company are building the next product, it’s great to think ahead, but keep your end goals in mind and don’t over-engineer your product.

Don’t create a castle when all you need is a house.