Four Start-Up Engineering mistakes that a founder should avoid.

As a mainstay in the product engineering and deployment industry, we often come across entrepreneurs building a seed-funded online marketplace. Many founders have ideation of a potential unicorn, still, we didn’t often see unicorns pop up as commonly. In my view, it is because every tech choice these abovementioned companies make was wrong considering their top priority. In simple words – “If you have more than one top priority, you have zero top priority!”. These Start-up engineering mistakes end up delaying their initial growth rate and in many cases dents the future prospect of the company.

Most importantly, the CEOs of all these start-ups believed in “empowering the engineer.” They then let their chief engineer choose the framework (Scala/Play) because it was what the engineer was comfortable with, not because it made sense for the company, their use case, or the recruiting pool. Along with outsourcing much of the technical work. Their product roadmap was widely optimistic (web and mobile concurrently) despite the fact that most of the business was still invalidated. It was a recipe for disaster.

What is start-up engineering?

Startup engineering is different from any other type of software engineering in the sense that it requires short- and medium-term productivity, relative to the “right way” of building systems. It values people who are able to adapt quickly and are comfortable with fragmented code. It requires pragmatism in technology choices versus picking the most “in the trend” — or most ‘trustworthy” — technology.

If your startup has yet to find product-market fit, here are four common Start-up engineering mistakes to avoid.

Early Expansion!

The most common startup engineering mistake is to expand too early.

The early expansion means building for a large scale when you’re still small. Expanding too early trades immediate productivity for far off, and often never realized, benefits.

Early expansion troubles are everywhere in start-ups. In the early 2010s, relational databases were shunned partly for the (supposed) infinite scalability of NoSQL databases like MongoDB and Cassandra. The start-up productivity benefits of monoliths were lost in the hype around microservices. For years, Rails has been called unfit for start-ups because it is slower than other frameworks. Early expansion wastes engineering resources. Expanding before reaching product-market fit is devastating for early start-ups who have little money and few engineers but huge feature requirements and the constant need evolve in order to suffice the market.

Why does early expansion occur so often if it is the number one start-up killer?

First, expansion is fun. The initial version of Twitter was a simple monolithic CRUD application that any boot camp engineer can now build. Just a few years in, Twitter had a panoply of interesting problems: large amounts of query data, a huge downtime costs, usage spikes, increased user base. The introduction of scaled technologies to address these needs made the job fun and more attractive to the new joiners. This initial excitement makes early scaling a rabbit-hole for engineering teams to fall into.

Why it’s important being rational while expansion.

Second, building high-performing systems seems rational. Many engineers are appalled by “glitchy” systems as if they are a moral failing. This dislike of potentially graceless solutions is especially an issue for start-up engineers who worked for large tech companies where everything must be done at scale. “Do things that don’t scale” applies in engineering as much as it does in business processes.

Technical debt hampers less number of early-stage start-ups than you think. If you’re afloat, you’ll often have the money to fix all the engineering mistakes you’ve made and the shortcuts you’ve taken.

Third, engineering roadmaps and tools are built around hyper-optimistic views of the future. Leaders are idealistic about how their businesses grow because, frankly, they wouldn’t have started the company otherwise. Even once you hit product-market fit — a critical milestone when engineering decisions need to be reassessed — the danger is that you overestimate the level of expansion you’ll require.

Trying to anticipate future needs before they arise exhaust valuable resources that should be targeted towards one thing only — building a product that people actually need.

Choosing new untested technology.

Startups hurt themselves when they rely too much on new and untested technology.

New technology is technology that software engineers bawl for. Shiny technology often makes an engineer’s work easier and more enjoyable, especially in an extremely short time. But relying on the new tech often misses what will be most productive for the long team or the medium term.

For example, MongoDB’s Javascript-like DSL and JSON data store eased writing code for Javascript developers in comparison to using relational SQL databases. But ease of use should not be the final metric when choosing a database.

Usage of the most “hyped” technology.

New technology has its own set of issues. The crash states of new tools are poorly determined, so it’s hard to anticipate how things will turn out after breakage. New languages/frameworks lack libraries or many engineers who can write in them. This lack of resources increases the development effort and makes recruiting an uphill task. It also means committing your startup’s limited engineering resources to learn something new when they could be focusing on creating features that your users will value.

Part of the problem is that developers — especially non-founders — want to implement the technology which makes them seem relevant in the market. That should be a cause of concern for a start-up. In spaces like front-end engineering, having engineers chase the current hype cycle might mean rewriting the code-stack in about every 6–12 months.

Developers early in their careers are especially inclined to using new technology instead of tools that make the most sense for the current project. They haven’t seen the downsides of choosing the latest technology. They can miss all the marketing behind what they’re seeing when listening to some tech influencer or attending hackathons/conferences.

What’s worse is that these developers don’t realize that just because a technology is new doesn’t make it apt for a start-up. It’s common to take a tech stack of a well-known business or large company and resettle its stack, without evaluating the fidelity of these choices. When teams are small, developers don’t always have the guidance from seasoned engineers to counter the external media they face.

The Python Paradox

Startup developers often refer to Paul Graham’s famous post, The Python Paradox, where Python increased start-up productivity more as compared to Java. Graham’s post is often used by developers to justify the implementation of new technology every latest framework and language. However, Graham’s real point was that engineers should select tools that maximize start-up productivity, rather than inertly favor the newest technology. In fact, Graham was once asked about ideal languages. He iterated, “I mean, we have had startups writing their code in PHP — and that worries me a little bit. But not as much as other things worry me.”

As an engineer, you’re taking a huge risk of joining a start-up. You shouldn’t add the risk of hyped, but unnecessary technology to the mix.

Hiring the wrong engineer

Many startup engineering problems stem from hiring the wrong engineers.

Startups often look for “rock stars” or “ninjas.” They want flashy educational degrees and the Midas touch that comes from being part of successful organizations. In Silicon Valley, start-up job posts filter for candidates who use new technology rather than favoring more practical engineers who can learn the necessary tools quickly. Once a company goes for these perceived “ninjas” and “rock stars,” it sets the tone for every subsequent hire.

Startup engineering is rarely taught discipline. The vast number of software engineers work for established IT-firms. As such, most engineers who join start-ups aren’t trained in start-up engineering and don’t have the skill set or attitude to succeed in the start-up environment. As a result, start-ups often had to rely on engineers who aren’t a perfect fit for the project.

Each of these engineers has their own risk for a start-up contributing to the eventual start-up engineering mistakes :

• Large company engineers are often exposed to scaled codes and may not feel comfortable with hacky code. They are less likely to be exposed to their users.
• Cream of the crop computer scientists gets bored by the nuts-and-bolts type engineering that typifies early start-up tasks, leading to over-engineering.
• Junior engineers, who are often attracted to start-ups, may inject too much new technology and poor systems architecture.

By contrast, ideal early start-up engineers are excited about the company’s vision. This ensures that they’ll stay when the company inevitably face challenges along the journey to product-market fit.

They have an MVP mindset and comfort with constant iteration. The best start-up engineers often have a few years of experience in the workforce or on open source projects so that they’ve learned how to maintain the systems, not just build them.

Rather than seeing particular technologies as hacks, they favor productive tools that meet the medium-term needs of the organization. Great early start-up engineers see technology as a means to solve the problem.

The Go-getter Engineers!

Engineers need to have a can-do, go-getter attitude. They rise to the paramount challenges in front of them while moderating, but not giving up, the optimism of the product owners. These engineers need empathy for their users because they often play the role of product when iterating.

Although on a more cautionary note, even among start-up engineers, the experience gained at each project is vastly different. A start-up engineer who is effective at five engineers may be terrible at 25. For start-ups hiring talent, seeing an engineer who was part of a successful start-up often overwhelms the tone of what that person actually did there.

Start-ups should look beyond the name brands and hire based on fit for the current project.

Product and Management problems

So many start-up mistakes emanate from product and management, not engineering.

Start-up founders are highly optimistic. The product roadmap often exceeds the capabilities of their small teams. This optimism therefore leads to over-hiring, too much fundraising, and eventually, burn-out. For management, this cycle seems to look like “the engineers are being unproductive” when it actually means that management didn’t set a clear and narrow vision.

The always pitch! start-up mentality of founders also gives a false sense of certainty to the engineering team about how the system should be built, despite the uncertainty that exists in the business model itself. A better approach is to support optimistic engineers and develop (internally) pragmatic business leaders, with both sides working together to find product-market fit.

Another problem for new start-ups is that management often finds engineering consultants — engineers at other successful start-ups — to guide the new company. Importing supposed “experts” from potentially unrelated companies who have no personal stake in product development often raises problems when these consultants transplant what worked at their particular company to a new start-up that they have spent only a few hours trying to understand.

Finally, management needs to understand that their engineers are a vital component of any major product decision. Ensuring a healthy product-engineering relationship is one more reason as to why it’s critical to have hired the right engineers.

Don’t let these start-up engineering mistakes stall your growth!

Even if you avoid these start-up engineering pitfalls, there could be other challenges, but by steering clear of start-up engineering mistakes such as these, you’ll have one less thing to worry about.

However, in order to better asses your idea’s viability, it’s always a wise decision to outsource the technical work to the experts, we at AppVoir understand the importance of pitch-perfect execution of a start-up idea in minimal resources and we thrive such complex business problems that require engineering solutions with minimal resources.

(Follow us on Facebook and LinkedIn to stay updated about our recent updates.)