3 Ways to Keep Startup Engineering Simple

Over the past few years at Jelly, we’ve built a lot of stuff. Between a pivot, and the recently announced unpivot back to Jelly, there were lots of prototypes, backends, and frontends, and a few very steep traffic spikes. And through all that building (and recycling) I’ve found that the most important engineering mantra for keeping the team nimble and efficient is to keep things simple.

When I say simple, I don’t mean building products of poor quality, that are ill-conceived, or half-baked. I mean scoping down, doing less, starting basic, but still nailing it where it counts.

Here are three techniques which have helped us stay simple and keep things moving out the door.

1. Avoid bloat in your stack

As your team grows and as your product matures, the natural tide of complexity in your tools and environment creeps up incessantly and inevitably.

Fight it.

Complexity in your stack seems harmless, but it compounds rapidly, and it has so many hidden costs. Conversely, when you keep your tech stack simple, everything works better. Faster times to ship code. Less code to maintain. Quicker compiles. Shorter scripts. Less time to spin up a new team member. And, of course, easier to adapt your code to new ideas in case something changes. (Things always change).

How does this look in practice?

• You want to build a new feature
• It requires a new technology, so you start researching the many available options.
• This is key: instead of picking the sexy solution that uses some fancy new tool, you find a simple solution that doesn’t expand your existing stack and is good enough.

Sometimes this means simplifying the feature itself, or making another compromise. Don’t worry, you can always build more later.

2. Start coding

The principle of using something off the shelf instead of reinventing the wheel makes more sense than ever before. There are an incredible number of high quality libraries and services available to engineers. However, the landscape of tools and platforms is changing so fast that it can be bewildering to keep up. Don’t fall into the trap of over-analysis. I love Barry Schwartz’s The Paradox of Choice which applies to software as much as anything else.

As an engineer, it’s easy to over-optimize even the most minor of decisions. These are all time sinks that keep you from building your product and actually learning and adapting it to the essential issues that people using your service care about.

Instead of spending half a day reading blog posts about the pros/cons of 10 different platforms, just pick one and start building. Already know how to use one, and it worked fine? Use that one. Plus, if you pick early and it really is wrong, you’ll know a lot more when you go back to pick something else.

There are key times where picking the right language/tool/platform will have lots of ramifications and it’s worth digging into a bit more. We picked Go for our backend in 2013, when it was a bit unconventional, and it has paid incredible dividends. Our entire backend API is still in one language, compiles to one binary, is around 12k lines of code, yet was able to scale to support over 100k people in a single day.

3. Dream big, build small

I’ve found that very often when you start designing a new service, you dream about the biggest, best-case scenario and start building something that you hope could scale to 10s or 100s of millions of customers.

It’s okay to dream big, but the next key step is to scope things down to a smaller version that gives you a basic foundation. If you skip this step, everything will be over-engineered, take longer to build, and be harder to adapt.

The reality is nothing is really future-proofed anyway because things are always changing. It’s all software, and it will be iterated-on many, many times if things go well.

If you’re building technology at a startup, stay vigilant. Always fight the good fight for simplicity.

Ben Finkel
Co-founder & CTO
Jelly Industries, Inc.

This guest post is from Ben Finkel. My friend, my co-founder, and my chief collaborator in our attempt to fundamentally re-imagine “search.” He’s also Jelly’s CTO. Ben’s first job out of college was literally saving our planet. He wrote predictive algorithms for near space objects at MIT Lincoln. He’s not only a good guy, he’s an incredibly smart visionary with mad tech skills. I asked him to publish something in my Medium publication so y’all could benefit.