Good enough engineering to start an Internet company

When starting an internet company, it‘s easy to get caught up in pursuing technical perfection. You dream up an ambitious architecture, debate the merits of the latest cutting-edge technologies, and fantasize about the scale and performance you‘ll need when you‘re the next Facebook or Google.

But the hard truth is, you‘re not Facebook or Google (at least not yet). And what you need to get a new internet company off the ground is very different from what tech giants need to serve billions of users. In fact, the key to successfully launching a new web app is to keep the tech as simple as you can, and focus relentlessly on rapidly bringing a minimum viable product (MVP) to market.

In other words, you need to practice the art of "good enough" engineering.

Start with boring, proven technologies

One of the biggest mistakes inexperienced founders make is to chase the shiniest, most hyped-up new technologies for their stack. Sure, playing with the latest Javascript framework is fun, but is it really going to make your app succeed? Probably not.

Instead, bias towards boring, battle-tested technologies and tools, especially for your initial MVP. Rails, Django, Laravel, or even WordPress or no-code tools like Bubble are all great for getting a web app off the ground quickly. They may not have the buzz, but they get the job done. I‘ve seen countless apps happily serving millions of users on these stacks.

As a recent example, the team behind Todoist grew to over $1M in revenue on a simple PHP backend. When you‘re starting out, optimize for development speed above almost all else.

Mean stack

Use off-the-shelf services and tools

These days, you can piece together a fully functional web app while hardly managing any infrastructure yourself. There are services and tools for almost every layer of your stack, from DNS management to authentication to search to async processing.

Need to send transactional emails? There‘s SendGrid, Mailgun, etc. Need site search? Just drop in a provider like Algolia. Database-as-a-Service offerings like Firebase or MongoDB Atlas make provisioning and running a datastore dead simple too.

Resist the urge to reinvent the wheel and build these pieces yourself. Focus your engineering efforts only on the core components that are truly unique to your application. Outsource and use off-the-shelf services for everything else. It will be much easier to scale this way.

AWS services

Embrace rapid iteration

What‘s the most important quality for an early-stage web app? Is it elegant code? Cutting-edge tech? Blazing fast performance? No – it‘s the speed at which you can iterate and evolve based on user feedback.

Getting your MVP in front of users as quickly as possible, and then rapidly iterating based on what you learn, is the key to finding product-market fit. Don‘t waste time gold-plating your app or worrying about scale you don‘t have yet. Just ship it!

Keep changes small, incremental, and easy to roll back. Decouple components and services as much as you can. Use feature flags extensively. Make it easy to run different configurations in parallel. Instrument good monitoring and alerting from day one so you always know the state of production.

The name of the game is maintaining the ability to move fast without breaking too many things. Optimize your tools and processes for speedy development iterations above all.

Continuous delivery

Evolve architecture incrementally

Speaking of moving fast, avoid the trap of trying to design the "perfect" architecture upfront to solve problems you don‘t have yet. That towering pile of UML diagrams won‘t make your app succeed any faster.

Instead, start with something simple that works for your MVP, like a monolithic Rails or Django app deployed to Heroku. Then evolve it incrementally as you start facing real scaling bottlenecks.

Follow the "Rule of Three" – only extract something to a service when you‘ve done it three times. Wait until you actually need more sophisticated patterns like event sourcing or CQRS. Prematurely optimizing your architecture is the bane of nimble product development.

Basecamp is a famous example of a hugely successful web app that deliberately kept their architecture and infrastructure dead simple for over a decade. They started as a monolith and stayed monolithic until the app was generating over $100M in ARR. There‘s a lot to learn from their story.

Don‘t neglect security

While you shouldn‘t let security concerns paralyze you, you can‘t ignore security and privacy issues either, especially in today‘s climate. But good security doesn‘t require complicated or esoteric practices.

The basics – using TLS, managed cloud services, encrypted databases, authentication best practices like brute force protection and good password complexity rules, keeping dependencies patched, etc. – go a long way in hardening your web app without much overhead.

Have third parties regularly audit and pentest your app. Consider pursuing certifications like SOC-2 early. Not only will this keep you honest about security, it can become a competitive advantage and help with sales as you grow. Investing in security pays dividends.

Automate all the things

Automation is a force multiplier for software teams of any size, but it‘s especially valuable when you‘re resource strapped early on. The more you can automate, the more you can focus your energy on core product development.

Use modern devops tools like Docker, Kubernetes, Terraform, Ansible, etc. to fully automate your builds, tests, server provisioning, and deployments. Codify everything. Treat your infrastructure like cattle, not pets.

Automate the development environment too with good Seeds and pre-configured containers/VMs, so that onboarding new developers is fast and painless. You want to be able to get a new engineer deploying code on day one.

Upfront investment in tooling and automation will pay off many times over in improved development velocity as you scale the team. It‘s some of the highest leverage work you can do.

Minimize technical debt

It‘s tempting to cut corners to ship features faster, especially when you‘re up against the clock and strapped for engineering resources. But be disciplined about not incurring crippling technical debt that will bog you down later.

Have strong code review processes and maintain high testing and code coverage standards from the get go. Refactor and re-architect proactively as you scale. Fight the temptation to do big rewrites – focus on evolving things incrementally.

Dedicate time in every sprint to chipping away at technical debt. Don‘t let it accrue and build up, or it will become a massive tax on your development speed over time. You have to go slower to go faster.

Automattic (makers of WordPress) famously measure "code debt" as a key engineering KPI. It keeps them honest about proactively refactoring.

Technical debt quadrants

Hire smart, not fast

When you do start hiring engineers, don‘t rush to fill seats. Every early technical hire has an outsized impact on your culture, processes, and overall technical trajectory. A few good people will far outperform a larger team of mediocre talent.

Hire for potential and ability to learn, not specific skills. If you followed the advice of using boring, proven tech, it will be much easier to find talent that can hit the ground running anyways. Look for true "startup athletes" that can wear many hats from front-end to back-end to devops.

Invest heavily in good onboarding, pair programming, lunch-and-learns, and other ways to rapidly level up new engineers. Make "building the team" a core part of every senior engineer‘s job description.

Remember product-market fit trumps all

Finally, don‘t forget that product-market fit is what ultimately matters, not technical wizardry. The perfect tech stack or the cleanest code won‘t save you if users don‘t want what you‘re building.

Over the years, I‘ve seen many technically impressive products with amazing engineering fail miserably in the market. I‘ve also seen relatively crude, "hacked together" products absolutely take off when they nail the right user need.

Always measure yourself by the value you‘re delivering to customers, not the elegance of your code. Keep talking to users and iterating towards fit. Let those insights drive your technical roadmap.

Slack is a great example of a company that prioritized customer value over technical perfection. Their early versions were downright hacky from an engineering standpoint, but customers loved it. They stayed laser focused on Product-Market Fit and became a massive success. We can all learn from that.

PMF pyramid

A "good enough" engineering mindset

Hopefully this advice has given you a sense of what a "good enough" engineering mindset looks like in practice. Remember, keep it simple, move quickly, automate what you can, and focus on delivering real value to users. Don‘t over-engineer it!

With today‘s tools and platforms, it‘s never been easier to get a web app off the ground. You don‘t need a giant team or a NASA-scale tech stack to launch something and start finding users. Just stay focused on the right priorities and don‘t be afraid to take smart shortcuts to accelerate time-to-market.

As computer scientist Richard Gabriel put it:

"The most important property of a program is whether it accomplishes the intention of its user."

No matter how elegant your code is, it‘s worthless if users don‘t adopt what you‘ve built. Getting to that critical point of adoption has to be the north star for any new Internet company. Good enough is good enough. Now go build something people want!

Similar Posts