It’s already the end of the first month in our series – time flies when you’re solving problems, right?

Now we’ve got the bare bones of our idea, it’s time we start fleshing things out. This week, we’ll cover:

  •     The benefits of a build pipeline
  •     Why we chose a stubbed frontend approach
  •     CircleCi, AWS services and React : our tech toolkit

First things first, we’re focusing on build pipelines.

Build pipeline evangelism

GitLab-logoImage credit: GitLab

Our COO Tom attended a talk at a GitLab event a while back. If you’re not familiar with them,

“GitLab is a complete DevOps platform, delivered as a single application”

Whether it’s project planning or source code management, or CI/CD and monitoring, GitLab is a platform that’s got you covered. They’re real industry leaders so we value their insight pretty highly.

Reassuringly, the team at GitLab place as much importance on forming a build pipeline as early as possible as we do. That way, you can start deploying code straight off the bat.

What’s the real benefit of instantly-deployed code? You can share your progress with all stakeholders at any point. In our case, that’s Slate CEO Ashley Coker.

You simply share a URL once you’ve implemented something new and anyone can see the new feature and its functionality.

We love reducing bulk and inefficient processes – with build pipelines, you see progress from day 1. You’re constantly iterating, constantly making changes.

You’re never going to be stuck building a project in a silo and updating code every 3 months after rounds and rounds of feedback.

Our stakeholder, Ashley, can give input at every minor stage, which helps keep us on brief.

Of course, we already knew all this before that talk. But it’s great to see industry leaders practising what we preach, too.

It’s just confirmation that we’re on the right track.

Stubbed frontend deployment

Next, we chose our deployment service. CircleCi is our regular go-to for deploying to Amazon S3 buckets, ready for review from stakeholders.

It’s also our best bet for applying a stubbed frontend approach.

For developers, a stubbed frontend is a firm favourite for projects like these. The frontend is the user interface of an application – basically, any part that the customer interacts with.

By stubbing the data our frontend will consume means we can focus solely on the frontend journey initially. Letting the user's needs dictate the design of our application.

When the design is  led by customer behaviour, you’re going to have a highly-functional app.

Using this process, we can build quickly, we can iterate and we can make transformational changes without getting bogged down with technical challenges too early on.

React – the final piece of kit

We’re relying on a library called React – it’s more or less the standard for building UIs these days.

All our devs at Slate know how to write code in React, meaning we can work on all stages of the project collaboratively.

Our devs can contribute anything at any point – the cost of entry is a lot lower. That’s why we chose React.

The dual customer approach

Our toolkit is brimming with excellent tech to execute this product, and we’ve got our game plan for designing the frontend.

Next week, we’ll approach the admin journey, since we’re really servicing 2 customers in this project:

  1.     The customer using the app to book the meeting
  2.     The customer using the admin dashboard from within the building society

Check in with us in a week for the next instalment of ‘The blank slate series’ to see how we push through the challenges of defining the admin journey.