Beating the Startup Paradox: Just Do What Every Good Pragmatist Does

Introduction

If you're a Star Trek Voyager fan, you may recall the series finale where the starship's captain wrangled with the Borg and a puzzling time travel paradox. A future Admiral Janeway faced the present danger of giving future technology to the Borg—yet if she succeeded in her efforts, it would alter the past (and future) for the better. How to decide? The Borg Queen told Janeway to "Do what all good pragmatists do, admiral. Compromise." Janeway did precisely that—and in doing so, created a new, brighter future for the Voyager crew and a very appreciative Federation.

Star Trek isn't the only place paradoxes occur that can make (or break) the future. Tech startups here in the 21st century face a conundrum of their own when engineering the software they need. A startup with a unique value proposition can rarely select COTS software for its underlying platform. (If they could, someone else has probably beaten them to the punch.) So, to become the next Amazon, Netflix, or Facebook, it needs a big team of the brightest engineers to build the biggest, baddest, most scalable software platform the world has ever seen, right?

That's a bad idea—and it could mean the difference between becoming a profitable company and being just another footnote in history.

The paradox most tech startups face on day one

What is this startup software paradox, and what can startups do to avoid it?

Startups with visions capable of changing entire markets attract and hire brilliant software and engineering folks. These people are excited at the chance to build a cutting-edge system to support the millions of customers that will undoubtedly flock to the company's banner. But to be candid, even with the best of ideas, a typical startup won't become the next Netflix. With luck, they'll make it to $20 million or even $50 million, but it's a rare breed that turns $10 million into $10 billion. And those that do certainly don't do it overnight.

The trap is that these talented engineers set out to build massive, bullet-proof, often over-designed systems for millions of users that don't yet exist. Worse, a cash-strapped startup can't afford to dish out the bucks for such a platform, nor does it have time to do so. Such projects are often way over budget, way behind schedule, and don't do everything they were supposed to. As a result, they miss the market opportunity, and the company's future hangs in the balance.

Cracking the startup software paradox

For your startup to succeed, it has to do two things: get to market quickly and then pivot when the time is right. You'll launch your product, realize why it didn't hit the value prop you expected, then change it. So instead of trying to build something mammoth right out of the gate, just build what you need today. Get the product out there, and when the money comes rolling in, you'll have the resources you need to pivot and take things to the next phase.

Here are some tips to avoid getting caught up in the startup paradox.

• The latest, hyper-modern programming language may not be the best

When building the-next-big-thing from scratch, it's tempting to latch onto the hottest new programming language. But there are problems with selecting a hyper-modern, functional programming language like Go or Rust—and it isn't their capabilities. When you pick an esoteric language, it's much harder to find people with experience writing in that language. You end up hiring inexperienced developers you hope can come up to speed, or you overspend because the talent pool is too thin.

Instead, pick a more popular language, one with more frameworks, open-source packages, and libraries built around it—and yes, with more experienced developers available. You'll not only save lots of money, but you'll reduce time to market. You can always pivot and change languages when the time is right.

• Pick an architecture based on today's reality (not a distant future)

The latest in modern software architecture is to decompose every functional domain into very small microservices. When starting with a clean slate, it's tempting to be a "purist" and define hundreds if not thousands of microservices—a bad idea. What startups fail to realize is that with a team of only two to five engineers, the ratio of microservices-to-developers will be impossible to manage. And on day one, when you have only a handful of customers/users, the actual usage of most of these services will be negligible. It's not worth it to decompose the problem to the nth degree.

Remember that Netflix has hundreds of millions of users and thousands of engineers. Even with 1,000 microservices, they can afford multiple engineers working on each one. You are not Netflix—not yet. Consider writing a monolith or two or three mini-monoliths. There's 30 years of computer science literature on how to write a well-designed monolith that scales. Again, be pragmatic, get to market quickly, and pivot later.

• What's wrong with SQL??

Like programming languages and architecture, everybody wants the database flavor-of-the-month. After all, why would you want to use old technology like SQL? Frankly, it's because SQL databases are really fast and really reliable. They don't lose data, and you can scale a SQL database to millions of users without having to touch it.

The perception that SQL is slow or that NoSQL is fast only comes into play when the data volume and number of users skyrockets. Remember, you're a startup, not Facebook or Amazon. For now, pick a safe database like Postgres or MySQL. You can refactor your database code later—or perhaps just double your database capacity on the cloud for a few extra dollars per month.

• On-premise infrastructure or hosting with a provider?

These days, startups shouldn't even think about spending precious time and capital on buying servers and building a server room (or a datacenter). A hosted solution makes more sense to get things moving.

Use whatever hosting provider you like but pick one that makes sense for today—for getting to market quickly and cost-effectively. There are numerous cloud PaaS solutions (such as Heroku) that let you upload your code and forget about the infrastructure altogether. However, it's hard to beat Amazon in terms of feature set, functionality, services, libraries that support them, and (yes) price. Just remember to keep it simple—most startups shouldn't even think about multi-cloud or multi-region issues right out of the gate.

• Staffing the startup beast: Full-time vs. consulting vs. hybrid?

Full-time employees can be expensive because they often expect equity in return for the long work hours required (with no promise of a return). Also, you're taking a risk that a new team with a new leader will come together quickly and deliver before someone beats you to the market. You might not know for months (or years) that your technical team simply wasn't the right mix of people—and then the market opportunity has passed.

Hiring all consultants can avoid some of that risk, but it comes with its own problems. You get a mature technical organization with people who have worked together, one that trains and certifies its employees and has specialists to consult. The obvious downside to the pure consulting model is that you're beholden to the consultants for their knowledge of your systems.

A hybrid model is usually best. You should provide the leadership and vision and hire a core team, of course. Consultants can then provide the additional technical design expertise, implementation experience, and best practices you need to deliver the product quickly and efficiently. Just make sure they act as an extension of your team and bring your team's expertise up to their level so that you can take over from there.

Do what all good pragmatists do. Build what you need today and pivot tomorrow.

A startup needs more than just a vision for the "next big thing." It has to be nimble and gets its software and product to market quickly and cost-effectively. It can be exciting for an engineering team to build from the ground up using the latest tech and architectural design patterns. However, startups can't afford over-designed products that take years to create or to spend far more than necessary to implement. After the money starts rolling in, you can design and build anything you want.

Remember, like Admiral Janeway did, that your decision today to build pragmatically will largely determine your chances for success. It might well determine whether you have a future at all.

Want to learn how to get the "next big thing" designed, developed, and launched without waiting for years of engineering time? Contact us to see how JBS Custom Solutions can help.