Picking tech for your startup - Opbeat blog

When you’ve got an idea, and a team, and you’re raring to get started on hacking for a potential startup, a question that often comes up is, “well, what technology should we use?” (hopefully you’ve answered the necessary, “what problem are we solving and how are going to solve it” questions first).

The key issue is balancing newer components that might make you move more quickly, versus tried-and-true components that have more predictable performance and reliability. Here are a few things to consider when picking components:

Don’t obsess about potential performance

It’s very hard to tell if users will end up adopting your startup, and what their behavior patterns will be once they do. Over-optimizing early on is a mistake I’ve seen multiple startups make; I remember one founder asking me which binary serialization format he should pick for communication with his iOS app, when just a simple JSON API would have done just fine.

Your team will likely end up rewriting many parts of your stack if you gain traction; the focus should be heavily on making sure that your initial testers do have a speedy experience, but not so much on whether you could handle thousands of concurrent users.

The one caveat I’ll add: if you’re doing a big press launch and expect a wave of users, map out the most likely things new users will be doing (signing up? checking the about page? etc) and ensure you’ve got a good solution for adding capacity to those areas if needed.

Borrow instead of building whenever possible

There are hundreds of fantastic open-source projects that have been built through the hard experience of creating and scaling companies; especially around infrastructure and monitoring, there are open-source projects like Sensu, Graphite, etc, and hosted solutions (like Opbeat!) that can save you time and let you focus on actually building out your product.

When tackling a specific problem and deciding on the right tool for the job, it’s often worth it to search through recent StackOverflow Q&As to see how others have solved similar problems.

Your core data store is not the place to experiment

Quora co-founder Adam D’Angelo has a great write-up on this as a Quora answer, and said: “the primary online data store for an application is the worst place to take a risk with new technology.” While newer data stores have emerged and matured, it’s hard to beat the stability of something like PostgreSQL (and features like the hstore columns can give you NoSQL-like flexibility).

As an added bonus, more mature projects usually have very solid replication and backup workflows, which you’ll want to get in place as soon as you’re working with any kind of user data that you care about. Finally, they’ll also likely have a healthy ecosystem of good write-ups and consulting firms, which can come in handy if you require additional support.

Caching layers + denormalized data are good places to experiment

Early on at Instagram, we decided to take a chance and adopt a then-pretty-new technology called Redis for storing some of our user feeds and other denormalized data; it’s proved to be a great part of our toolset. But if it hadn’t worked out, the data would all be re-creatable from our core data store. Similarly, for caching layers like Memcached or Redis, you can gradually ramp-up traffic to new systems, see their performance, and cut back to the initial system if needed.

Prefer new features of established components vs new components outright

Especially with large, well-run projects like PostgreSQL, new features that land in a stable release have generally been well-vetted by the community. Starting your tech stack by building off the latest stable version of these projects, and using newer features, will often be a more stable / less frustrating experience than trying to use similar (or sometimes even more cutting-edge) features in less established projects.

Ultimately, the most important thing to keep in mind is that your “stack” shouldn’t define you; while some engineers are attracted to companies working with cutting-edge tech, that shouldn’t be the driving force behind your early technology decisions. Instead, establishing a solid base with mature data storage, and augmenting more exciting recent projects where they can add value further up the stack will let your team stay focused on solving the challenges you’ve set out to solve.