How to choose the technology you use

Building Personably has taught us a lot about how to choose the technology you work with. It’s easy to become overwhelmed by the choices available when creating a product, and it’s important not to get too distracted by the lure of using something new. Your goal as a startup is to ship features quickly, and your stack should enable you to do that. Here are some reflections on what we’ve learned.

Using new tech can be a blessing and a curse

One of the attractions of working at a start-up is the chance to work on a greenfield project. There’s always a trendy new tool to use, and sometimes they can solve a real problem you’ve been struggling with. The teams releasing them can often be incredibly helpful and attentive to their users. On the flip-side, sometimes it can be difficult to keep up with churn as the technology you use gets updated.

For example, when we began writing the Personably front-end, React was the obvious choice. It was easy to work with and most of the big internet companies had adopted it. React is equally as attractive to us because of the community. The contributions in the React ecosystem means it’s rare that you encounter an unsolved problem today. We’ve used a wealth of different libraries designed for React, such as Facebook’s Draft JS rich text editor. Contributors such as Dan Abramov and Ryan Florence help to teach and nurture the community. It’s also incredibly helpful to be able to read about how React is used for products serving millions of people, such as how Netflix build TV interfaces with React or how Twitter built a fast PWA with React.

On the other hand, it can be tricky to keep pace with the regular updates to the tools you use . When we began building Personably, we were using React Router V3 (having missed out on the two major versions that came before!). About six months in, React Router V4 was released. It was a major change, with a significantly different API. When changes like this come, our approach has been to delay a couple of months before taking the time to upgrade. This allows any initial bugs to be ironed out, and usually the documentation will mature over time. Similarly, our chosen GraphQL client for React, Apollo, released a significant update from version 1.0 to 2.0, and React itself introducing breaking changes from v15 to v16. An added difficulty of this can be stumbling across an issue/Stack Overflow post about a problem you’re working on, only to find the suggested answer references the old version. It can be difficult to keep up!

Aim to get good at assessing the tech you currently use and plan to use

Over time, as you develop your product, you’ll get a better intuition for assessing what you currently use and the new things you’re considering using. In the long-run, this will serve you much better than feeling tied to anything in particular. The feeling of mastering a tool is really rewarding, and can allow you to move quickly. But it’s also valuable to look at other options that could give you a boost.

Some important questions we ask when looking at what we currently use:

Is there anything else that would be better suited to the job?
Does using this slow us down?
Are we using this in the most effective way?

Some important questions we ask when looking at something new:

Is the benefit of adopting this going to outweigh the time spent learning to use it?
Is there an active and supportive community behind it?
Are other similar companies using this? Is there anything we can learn from their experience with it?

As an example, when we started working with GraphQL, we needed to choose a GraphQL client to use with React. There were two obvious choices at this point: Relay or Apollo. Given we were already using much of the Facebook stack, Relay would have seemed like the obvious choice. However, the documentation and the API were complicated, and it lacked much community support behind it. We needed to get up and running quickly, and Apollo felt much easier to work with. Over time, Apollo seems to have gone from strength to strength.

Early on when starting Personably, we picked up Graphcool (as it was then called) as a backend-as-a-service. We were trying to put together an MVP quickly, allowing us to demonstrate our ideas and get a product out to users quickly. At first, this was a quick win for us. However, over time it became difficult to work with a BaaS. You lack control over how to manage your services, making workflows such as CI and CD difficult to implement. We began to consider other alternatives, such as building our own GraphQL server using Apollo Server. Luckily, Graphcool’s own roadmap kept pace with what we were looking for, and they switched their approach away from a BaaS. Their new offering, Prisma, lets us quickly generate a GraphQL API on top of a SQL database, whilst keeping control over our developer workflow.

If you don’t have any technical debt, you’re not moving quickly enough

Whilst it can be frustrating when you’ve picked up lots of different tools, and you’re using lots of different services, avoid the temptation to try and find the “perfect stack”. Your focus as a start-up should be building new features that delight your users. If your technical debt prevents you from doing that, address it. Otherwise, keep moving. Your users don’t care how perfect your stack is.