3 Engineering Mistakes That Kill Startups

I’ve been doing engineering consulting in fractional CTO roles for about a year now. And my current work is vastly different from my previous work in corporate.

For one I work with a much more diverse clientele. At Amazon I worked mostly with other engineers. With consulting most founders I work with are non-technical.

So a higher premium is placed on communication - explaining technical issues in the simplest way possible for clients.

Furthermore since most startups build product from scratch, I thought this would make engineering easier. It turns out that’s not necessarily the case.

Many of my clients spend over 6 figures and several months of time to get an MVP built only for the project to take way too long or never get delivered.

And they come to me to figure out how to get their product back on track.

Fortunately, this situation is completely preventable. And having seen this situation play out for dozens of clients now, I’ve noticed that these projects tend to go south due to the same 3 mistakes.

It happens when startups:

Misprioritize the order in which features are built
Pack too many features into the first iteration of their product
Let perfectionism get in the way of speed

If founders focus on avoiding these 3 mistakes, they can prevent countless months of frustration, and deliver their product to customers faster.

1. The Order in Which You Build Features Matters

The first mistake that founders make is they don’t ask engineering to build features in the right order.

Often founders will bring a design doc with a list of features for their product, and then ask engineering to go build it.

However, when listing features to build, the order in which you build features matters.

Specifically, you want engineering to build the core technology first, not last.

The core technology is the part of your product that customers derive the most value from.

For example, if you’re a search engine like Google, returning the right search results is both more difficult to build and delivers more value for customers than the “I’m Feeling Lucky” button.

So the search algorithm is what you want engineering to build first.

For a ride-share product like Uber, connecting you with a driver at your door in under 5 minutes is vastly more important than any account settings pages.

So the matching process between the driver and rider is what you want to focus on building first.

Which page would you build first?

I’ve seen many engineering stories play out where agencies will spend months building a UI for example, but when it comes time to build the actual software, they fail to do so.

If an agency is unable to build a particular feature that’s critical for your product, you want to find out about this ASAP.

I saw this even in a recent call. One client was trying to build a website with a financial calculator embedded in it after spending thousands of dollars with another engineer.

When I asked what happened, they showed me what their last engineer built:

The engineer spent two months building out these two pages, but they never got to the core part of their app which is the calculator!

And when it came time to build the calculator, it turned out that they couldn’t do it because some of the calculations were too mathematically complex.

Had the client asked for engineering to build the calculator first, they could’ve uncovered this confusion faster, and determined whether building the core technology was within their previous hire’s skillset.

So as you build your product, three questions to help you prioritize features include:

What part of your app do you consider the “core” technology?
What part of the app is the hardest and riskiest to build?
What features in your app have you seen already built in other products vs. something that is totally new?

With number 3, if there are parts of the product that you haven’t seen others build before, you may want to validate that that portion is technically feasible before building anything else out.

2. Asking for Too Many Features in the First Pass

A corollary to building features in the wrong order is also asking for too many features built.

This happens when clients view engineering as building “a list of features.” For example, if they see a car they see it as the sum of all the features in it including the:

Signal lights
Heated seats
A/C

And they would view building a car like checking features off a list.

However, this will almost certainly create delays in an engineering project, as it will generate a huge list of features to build and overwhelm engineering.

Instead of viewing the product as a list of features, I often tell clients to focus more on what the problem they’re trying to solve for the customer is.

For every single feature ask, “How does this feature help solve that customer pain-point?” to help cull down the list of requests for engineering.

For example the main problem a car solves is it helps a person get from A to B faster.

For an initial prototype then, we certainly don’t need the air conditioner, nor do we need a trunk, nor do we need heated seats.

If we focus on the problem, this calls into question whether we need a car at all, because perhaps a scooter, a bike, or even a skateboard could help get a person from A to B faster as well.

I often encourage founders to think about what the “skateboard” version of their initial product is, rather than thinking in terms of features.

It will help get a prototype out the door faster, sometimes reducing engineering estimates from months down to less than a week.

Example: Building a Thumbtack Clone

I recently spoke with a founder building a website similar to Thumbtack, but where you can call-in for assistance with booking.

Thumbtack is a website to book services from local pros.

Initially, they said they wanted all these integrations in their prototype including video calls, payments, and booking systems. Each of these integrations adds significant engineering work and delays the launch of their product.

But if a customer just needs help booking stuff, perhaps they don’t need any of these features. Just a way to see the list of services, call-in to specify what services they want to book, and have someone handle the rest over the call may be enough for a prototype.

In fact, this app is very similar to the first version of the food delivery app DoorDash. Although DoorDash has a lot of advanced features now, their initial website was only a number on a website that you called to tell them what food you wanted.

The founders would then call the restaurant to order the food, pick it up, and deliver it for you. No integrations or bookings, just a phone number with instructions in their MVP!

The initial DoorDash MVP

This prototype is simple enough that they could get this out within a week. But had they tried to incorporate all the fancy integrations and incorporated the huge list of features they have now, this could’ve easily turned into a multi-month project.

So in this case, I recommended the founder consider a version of their product similar to the DoorDash MVP for their Thumbtack clone as opposed to the original version they had in mind.

Building the “skateboard” version of a product, and staying focused on solving the customer problem rather than just building a list of features will help trim a multi-month project down to one measured in weeks.

3. Aiming for Perfect Engineering Architecture

The last mistake that often leads to delays is striving for engineering perfectionism.

Founders often want their product to have the perfect architecture and be perfectly scalable from the get-go, which places a big burden on engineering to meet.

They’re often worried about an outage if they get a Facebook style launch when 22,000 people visited the first version of Facebook within four hours of launch.

Even Facebook looked very different in the early days.

The reality is that most launches are actually very quiet. Countless times I’ve seen founders launch and get far fewer visits than they expected. I know because I remember launching RecordJoy.com on Reddit once expecting to rocket to fame.

Not only did I fail to get a single upvote, I also got banned from the Subreddit for spam 😢.

Sometimes this perfectionism also comes from trying to emulate the engineering practices at the biggest tech companies. They see the clean code bases and the microservice style architecture, and assume that’s how it should be done for their startup as well.

However startup engineering is very different from corporate engineering. At FANG, the companies have already reached product-market fit, so maintainability and scale are of greater concern.

Startups however are still searching for product-market fit, and they will likely need to pivot so many times that their initial system may never get used.

Often it’s better to get something functional working, validate that this is truly what customers want before investing further resources in scaling it out.

In some cases, you may find that the “hacky” solution that you initially built may take you further than expected.

This was the case for Stack Overflow.

Example: Stack Overflow’s Monolith Structure

Alex Xu, the author of System Design Interview book, once discussed StackOverflow’s architecture in a tweet.

He pointed out how if you tried to design StackOverflow with on-premise servers and a monolith in an interview, you would likely not get the job because it is considered bad engineering practice and unscalable.

But that’s actually how StackOverflow was built!

As you can see, the “perfect” architecture for StackOverflow would involve breaking down the website into separate components, like the comments, user management, and questions, and isolating each one in its own microservice.

Yet their current system is not perfect, but is far simpler and faster to build, and has still managed to scale to over 100 million visits per month!

So, there is often a practical element to engineering as well. Instead of aiming for perfection from the get go, it’s better to take an iterative approach and get 1) something working and then 2) refactor it to make it more scalable when the time comes.

Or in Stack Overflow’s case, never refactor because their hacky prototype happened to scale well too 🙂.

Conclusion

Three different mindset shifts towards engineering can be the difference between getting stuck in a multi-month engineering slog, and getting something into the hands of your customers in a week.

As a founder, if you focus on: