One of the most fun things about building Unsplash is the sheer size, scale, and popularity of the product.

On an average day, our API handles 10M+ requests from unsplash.com and thousands of 3rd party applications, our data pipeline processes millions of events, our feeds add 60M updates, and we serve 60 million images.

At the same time, our team is relatively small: 2 designers, 3 frontends, 3 backends, and 1 data engineer. No one is tasked with devops and everyone spends the majority of their time on experimentation and new feature development to fuel growth.

While we’ve accomplished a lot with Unsplash, we’re still at the very beginning of its journey as a product and a business. We still have a lot to prove, meaning we need the entire team focused and solving the problems unique to Unsplash, and not the ones that every company shares, like deployment, network security, infrastructure, dependency management, etc.

Over the past 3 years, we’ve developed a set of principles that allow us to focus on growth and away from scaling challenges. Unfortunately, for those of you looking for a magic bullet, there is none: just common sense and a set of principles we’ve liberally borrowed from others.

1. Build boring, obvious solutions

A.K.A. Be Pragmatic™

Before reaching to introduce a new tool, whether it’s a new database (RethinkDB, RocksDB, etc.), a new pattern (“functional everything!”), or a new architecture (“microservices to the rescue!”), exhaust the obvious options first.

On the backend, there are very few problems that can’t be made “good enough” using standard workhorse tools and a few tried-and-trued patterns, like caching, batching, asynchronous operations, and pre-request aggregation.

2. Focus on solving user problems, not technology problems

Unsplash is a product company, not a technology company. We were given a lot of money by investors specifically so that we can focus on solving a product and market problem, not trying to eek out a 3% improvement in operating costs for our application of a common technology.

Instead we focus our time on connecting pre-built technologies in a way that solves our user’s problems and expands Unsplash’s community. These are the parts unique to Unsplash and if we succeed in building something unique and of value, we can tackle optimizations and heavy customization at a later date, where those 3% optimizations may be the main sources of growth left.

This can be confusing to prospective teammates, as they’ll hear about Unsplash’s ‘scale’ and small team, usage of imagery and AI, and future features, only to realize that we use a lot of off the shelf technologies, services, and frameworks, while paying a small premium to punt the in-house development of these technologies down the line to our future teammates.

Deployment pipelines, server configuration, system dependencies, data processing, data analysis, image processing, and personalization (to name a few) are examples of areas we chose not to focus on investing our engineering resources in, choosing instead 3rd-party services to handle each of them.

3. Throw money at technical problems

The flip side of not focusing on a technology problem is paying a premium for access to a pre-built technology or 3rd-party service.

It’s become a bit of a joke within the team that my first response for any problem will be ‘Have you tried throwing money at it?’. But it’s not a joke and it’s one of my favourite approaches to problem solving.

Optimizing the costs associated with infrastructure and technology is such a common problem with simple, repeatable solutions, that no investor-backed product company should concern themselves with it until they feel that growth of a top-line metric is no longer their number one priority.

Throwing money at a technological problem frees our team up to focus on the non-repeatable, hard problems, like figuring out how to collectively grow a user base 40% in a quarter.