How we built the new

We recently deployed and open sourced a new version of our splash pages. We've had some great feedback on how fast the site is so we wanted to give a high level overview of our technical approach in the hope that others will find it useful.

In this post we'll cover both how we made the site so fast and what our development setup looks like.


When browsing you'll notice that after the initial page load navigation around the site is super snappy. Until you leave our splash pages, or choose a different locale, all your browser is requesting are new images. If you happen to be on a slow connection, or you have disabled JavaScript, the site still works fine.


Using React to render on the server means that we can deliver not only a fully rendered page to the browser, but also the rest of our splash pages too. Once the initial page is displayed, a request is made to fetch the rest of the site as a React application (only 250kB). All subsequent navigation within the splash pages is blindingly fast, not suffering the latency of HTTP requests since the browser already has the whole app.

If the user has disabled JavaScript, or they are on a poor connection and the JavaScript takes a while to load, they still experience the fully rendered page and only miss out on the fast navigation.

Static deploy

While we develop against an Express server, we don't deploy that. Since is entirely static, we're able to deploy and serve static HTML. One huge benefit of this is that we can host the site off an S3 bucket and not have to worry about a running web server and everything that goes along with it, such as exception handling, monitoring, security issues, etc.

In order to generate our static HTML we need to know every available URL. Since we're keeping all of our routing configuration in one place, this is trivial; we're able to easily extract the paths for all pages in every locale. Once we have those URLs, we simply crawl our locally running Express app and write the responses to disk ready for deployment.

Development tools


The newest version of JavaScript, ES6 (or ES2015 as it's now known), contains numerous improvements that make building applications in JavaScript a much nicer experience. We use Babel which makes it possible to take advantage of language additions now by compiling ES2015 (and even ES7 code) down to ES5, which has much better browser support.


We use webpack to bundle our CSS and JavaScript. There are plenty of other tools which do that too, however we particularly love the development experience when using the React Hot Loader plugin for webpack. This lets us see our changes live in the browser without losing app state.


The main motivation for rebuilding our splash pages was to allow us to more easily manage pages across different locales. We wanted to be able have one place where we could see, for each page, its handler, which locales it was available in, and its route for that locale.

Having one data structure holding all of this information means that you can see the structure of the entire site in one place. A downside of this is that it can get a bit tricky querying such a large and nested structure. Since the whole application relies on this structure, we also need to be really careful not to accidentally mutate it. This is typically dealt with by lots of defensive cloneDeeping. Not doing so would (and initially did) lead to subtle, hard to diagnose bugs across the application.

Our solution to the above problems was to use Facebook's Immutable library. Using immutable data structures, such as Map and List, means that we don't have to worry about mutating the actual routes data structure as it gets passed into functions that operate on it. Immutable also has a great API for dealing with nested properties, including getIn and setIn, which we use extensively.


We're pretty happy with the simplicity of our solution and the user experience that it enables. We hope others can benefit from our experience and, of course, if you have any feedback or suggestions, please get in touch!

We're hiring developers
See job listing
in Engineering

Interning at GoCardless

I'm wrapping up a four month internship at GoCardless and thought I'd share some of the projects I've worked on.

GoCardless has a real variety of projects, which has kept every day interesting and challenging. From front-end javascript to PHP client libraries, I've worked on almost everything at GoCardless and been able to learn from some awesome developers. Here are a few highlights:

React / How I came to love React

A couple of months ago we decided to rewrite the GoCardless marketing pages using React to support proper internationalisation. I was on the team from the inception of the project, figuring out how the app would work and seeing it through to completion.

Since last summer I'd been hearing great things about React, so it was great to get an opportunity to give it a try. We rewrote the site into an isomorphic site based off of dynamic React components, and I was really impressed by the flexibility and speed of the framework - both in development and production. GoCardless is planning to open source the work, and I'll definitely use React again.

Query Counting / How hard can a count be?

While working on the GoCardless dashboard I saw a few cases where having a count in the API responses would improve search and exports. Knowing if your search has two or two hundred pages can be helpful! I chatted to the team, and set about adding it.

As it turns out, getting a precise count isn't so straightforward. The API is built for queries that could match millions of rows, and needs to quickly return the paginated collection. After a few experiments with count optimisation and estimate counting in PostgreSQL I worked with the Platform team and we settled on using an exact count up to a limit. It was great to dig a bit deeper into the limits of PostgreSQL, and to figure out a pragmatic solution.

Stubby / Hijacking XMLHttpRequests for fun and profit

Internally, GoCardless uses JSON Schema extensively - all API requests are validated against a schema, and the GoCardless Pro docs are auto-generated from it. In my last couple of weeks at GoCardless I worked on adding another use for JSON Schema - stubbing out API requests in front-end app's tests, additionally validating that the requests themselves are valid.

There's more detail about Stubby, which is our open-source solution to the above, here. It was great to build something open-source, and I learned a lot about the process (docs, tests, READMEs and config all suddenly became much more important). I'm really glad that GoCardless as a company is invested in open source and emphasises giving back to the tech community as a whole, looking beyond their own product.

PHP Library / When I thought I was done writing PHP

Finally, when I started this internship I wasn't expecting to write any PHP. Even stranger, I wasn't expecting to write any PHP in Go...

A lot of our customers were requesting a PHP library for the new GoCardless API, so I stepped up to build one. GoCardless auto-generates all its Pro client libraries using an internal tool (soon to be open-sourced) called Crank, which combines Go template files with a JSON Schema to build a library.

I'll be honest, working with PHP was a bit of a hassle! In many cases we were torn between writing idiomatic PHP and making the library consistent with GoCardless libraries in other languages (we generally chose the former, but the trade-off in maintainability is very real). Some of PHP 5.3's new object oriented features such as magic methods and namespaces allowed for decent workarounds, but it was certainly tricky to make the decision of using them. Having put a lot of thought and effort into it the most satisfying part of the project was seeing integrators using the library immediately, and being able to respond to their feedback.

We're hiring developers
See job listing
in Engineering

Stubby: better mocking of HTTP requests in client side tests

Today we're open sourcing Stubby, a small library for stubbing client-side AJAX requests, primarily designed for use in front end tests. Stubby lets your implementation code make real HTTP requests which are intercepted just before they hit the network. This keeps your tests fast and easier to work with.


Stubbing a request is done by creating an instance of Stubby and calling stub:

var stubby = new Stubby();
  url: '/users',
}).respondWith(200, ['jack', 'iain']);

Any GET request to /users will be matched to the above stub, and ['jack', 'iain'] will be returned. It is possible to match requests against headers, the request body and query params. The Stubby README fully documents the functionality Stubby provides. The repository also includes examples of tests that use Stubby.


To keep our implementation tests close to reality we wanted to avoid stubbing any application code and instead stub the requests at the network layer. Stubby uses Pretender, which replaces the native XMLHttpRequest object, meaning our request stubs don't interact at all with our application code.

JSON Schema Validation

Stubby provides an optional plugin for validating stubs against a JSON schema. When this is used, any stubs will be validated against the given schema, ensuring the URLs, parameters and request bodies stubbed are all valid. If they are not, the tests will fail. This helps us ensure our stubs are accurate and realistic, and prevents our tests falling out of date with our API. At GoCardless we've invested heavily in the JSON Schema specification for describing our API.

Getting Started

You can install Stubby with Bower:

bower install stubby

Or for further information and to report issues, you can check out Stubby on GitHub.

We're hiring developers
See job listing

How we train salespeople

At GoCardless, we are growing at a phenomenal rate. We recently passed the milestone of having processed £500m, a far cry from the £300 we processed in October 2011. We believe we have the best recurring payment system in the world, what we are trying to build now is the best sales team in the world. Crucial to our success is how we train our new hires.

This post goes through how to get from applicant to killer salesperson. We’ve split it into three sections:

  • What do we look for when hiring?
  • How do we train new hires?
  • Our 6 top tips for training

If this sounds like something you’d enjoy, please get in touch.

What do we look for when hiring?

The first thing we did in this process was identify the 5 characteristics we cared most about in applicants. Those were:

  • Smart. Our product can be quite complex and technical. To succeed here, people need to be smart enough to learn the technical aspects of the product in detail.
  • Driven to learn and improve themselves. We strongly believe that how good you are in a year’s time is more related to your attitude than your current ability. How driven you are and how motivated you are to improve are the two most important drivers of success.
  • Likeable. People don’t like to buy from people they don’t like. It is essential that anyone we employ is friendly.
  • Communication skills. The ability to explain complex ideas simply is absolutely crucial for our salespeople.
  • Coachability. Giving and taking feedback is one of the most important aspects of our company culture. The quicker you are able to act on feedback, the faster you learn.

The one obvious gap here is sales experience. We have found that being smart and having a great attitude is a much better indicator of success than previous sales experience. We believe hiring awesome people and training them in the right way is the best way to get a continual funnel of exceptional sales talent.

How do we train them?

When new hires join, they go through an intensive 4 week programme. By the end, we expect them to be a fully ramped member of the team on the same level as anyone else.

So how do we do this?

  • Week 1. The focus is to learn about the product and basic sales skills. For product knowledge, they spend time in support and do lots of quizzes. For sales skills, they do lots of role plays and start doing live sales calls from day 3. Sessions include ‘Email training,’ ‘Competitor training,’ and ‘What is an API?’
  • Week 2. The aim here is to fully prepare joiners to deal with any question that might come their way. By the end of the week they should be able to handle all inbound calls. Sessions include an ‘Introduction to partners’ and an ‘Introduction to SEPA.’
  • Week 3. This is all about getting to grips with the more technical side of our product. They also go through a call they have had every day with another member of the team to get feedback. Sessions include ‘Effectiveness’ and a more in depth look at some of our larger partners.
  • Week 4. This is about ironing out anything new joiners might still be unsure of and getting them to pass the mighty Direct Debit balloon test.

Our 6 top tips for training

If you are looking to implement a similar programme at your company, here are our 6 top tips we’ve learnt along the way:

  • A structured programme is really important. Joiners should have a full calendar for when they arrive on the first day. The worst thing that can happen in anybody’s first week is having nothing to do or not knowing what to do.
  • Get buy in from everyone involved. The more upfront effort we put in, the quicker joiners get fully ramped up, and this is in everyone’s interest. When everyone understands the importance of training, they put more effort into preparing sessions.
  • Set goals and test against them. We have a really high hiring bar. If we have excellent people, and give them specific and easy to understand goals, it ensures they will succeed.
  • Feedback is king. Giving and taking feedback is a key part of our culture as a company. Joiners are sat next to other people who’ve worked in their role previously. This way, if people overhear something they say on the phone that could be improved - they get that feedback straight away.
  • Get as many people involved as possible. Not only is this important from a social and cultural perspective, it is also really important that they learn about different parts of our business from the people who know most about it.
  • Iterate. After the 4 weeks, I sit down with the joiner to see how we can improve the training programme moving forward. This way we can iron out anything that didn’t go well and take on any new ideas for how it could work better.

If this sounds exciting to you, please get in touch. We’d love to hear from you. You don’t need any sales experience, just a willingness to learn and proof that you’ve done something awesome before.

We're hiring
See job listing

We're making payouts faster

Payments you collect via GoCardless will now reach you one working day faster.

We've been working with the banks to speed things up, and starting next week will be sending your GBP payouts as same-day payments. This means that payments will reach your bank account just two working days after your customer is charged.

We're always looking for ways to optimise our payment timings, and we'll keep you updated as we make further improvements!

Interested in collecting Direct Debit payments?
Learn more