What?
Outlandish built a new web platform in just over 24 hours that allows businesses to support organisations with pressing needs during the current coronavirus/COVID 19 crisis.
Although there are already a number of such platforms, Business in the Community had a specific use case and needed a bespoke solution. Their members – who include the likes of Google, Accenture and Bupa – have very large scale operations and potentially vital resources but don’t necessarily have the ties with the (often) micro community groups and charities with the most pressing needs. BITC offers a brokering service to help these big corporations understand the needs and how their resources might help.
How did the project come about?
Tech4Good incubator/accelerator Catalyst and a number of “tech for good” agencies and some funders put together a Social tech vs Covid action group to help ensure that limited resources are used effectively at this time of crisis.
As I understand it, Eleanor Bradley, MD of Registry Solutions and Public Benefit who also chairs the Emergency Resilience Group for BITC initiated the need for a brokerage platform to connect business and community organisations. It was from this initial conversation that Nominet and the Social Tech vs Covid action group stepped up and worked together to work out who should deliver the work. People from the action group facilitated a call to work out who had the magic combination of needing the work and having the right skills and capacity in a very short time frame. Thanks to the other agencies generously pulling out, Outlandish ended up being commissioned to deliver the work.
What’s so special about it?
Two things stand out about this project and make it worth writing about:
- Co-operation over competition: a lot of other agencies would have quite liked this work in these unusual times and we worked out who would get it rather than pitching against each other.
- 24 hours: We (and I think most agencies and clients) normally expect a project like this to take weeks or months, and the deadline for this was 24 hours from sign-off!
What did we do?
The first thing we did was try to avoid doing it. Specifically, we sought to reuse what was already out there. The closest fit that we identified with the help of the action group was the brokerage platform from the SCVO which is a pretty sophisticated bit of tech powered by their well-developed backend services.With very generous help from SCVO’s awesome team (see shoutouts below), combined with discussions with the BITC team we worked out that while the brokerage platform was a great fit in many ways it was also different in some fundamental ways. For starters, it’s focussed on self-service rather than having back-office support for the needs-offers matching function, and therefore was going to introduce significant extra work for the SCVO team or fairly big feature mis-match for the BITC team. If you’re interested you can read a fuller reasoning for why we ended up building something new from more basic components.
Technical solution
24 hours is a very short amount of time to build a new product so it was important to use a very low risk tech stack that we knew we could use to:
- Rapidly prototype what we need
- Allow lots of team members to get up and running quickly
- Deliver all the core functionality without butting up against the limitations of the platform
- Deploy and host in such a way that it’s secure, fast and scalable
We identified three main approaches that might meet the above requirements:
- Airtable or Google Sheets/forms + half a mile of string
- Node/Express + Vue + some datastore
- PHP/Laravel + Postgres + Datatables
The first option is attractive because it does really well on requirement 1 and 4. Node + Vue might be what we’d choose if we had a bit longer to think about it, but PHP/Laravel and Postgres won in the end because, while it’s not the sexiest stack, it’s super robust and we’ve used it a million times before. In the end the key bits of the stack look something like:
Frontend: Datatables, VueJS, SurveyJS, JQuery
Database: Postgres (RDS) with Trigram index and JSONB datatype
Hosting/DevOps: Ansible, AWS EC2, Gitlab-CI, Git
How did it get done so fast?
We do a lot of rapid prototyping at Outlandish but we’d generally consider ‘rapid’ to be a week or two, with some time to plan and think about it first. It’s fair to say this is the fastest turnaround of a complex project in our 10 year history. Key things that helped were:
A kick-off where a goal was agreed
In the first hour of the first day we assembled the entire team (including clients) to agree the goal and basic scope of this project. Two outcomes: the goal, but also realistic expectations and clarity around how much input the clients needed to have to make this project a success. We do this exercise for EVERY SINGLE project and is one of the most valuable things to help set the project up and avoid assumptions.
This was the goal:
“For MVP (launch by Fri): Make it easier for organisations to submit requests for support and businesses to post offers, whilst making the management and matching more efficient for the admin team. All data submitted must be tracked.
(A.k.a Better then the spreadsheet)”
A large but close-knit team
Our team included three developers, a designer, a project manager and me (Jack of all trades). I think six people is about the limit of how many bodies you can usefully throw at a 24 hour project of this type without everyone treading on each other’s toes. It helps that I’ve worked with Rasmus, Matt, Mateus, Joaquim, and Kayleigh for 10, 8, 7, 6, and 5 years respectively so we know a lot about our relative strengths and how we all like to work.
Clear distribution of roles
Matt is our most experienced DevOps person so he set up the development, staging and production environments and then switched to backend tasks; Rasmus is our most experienced data wrangler so he set up the data models and business logic; Joaquim is equally happy with frontend and backend so he did the views, javascript and integrated them into the backend.
I used to code but I’m not good enough to run with the professionals these days so I drew the wireframes then turned them into functional wireframes/prototypes so that the proper developers could integrate them. It was a bit embarrassing in some ways but I helped Kayleigh wrangle the client content and requirements and everyone made me feel useful. I’d like to say I helped Mateus make the site look awesome, but that just suddenly happened halfway through Thursday, as if by magic.
Functionality first
Although we’re firm believers in multi-disciplinary agile teams there is a chicken and egg issue that either a designer or a developer has to commit to something first (after the wire-framing which we do together). On many of our projects our design is slightly ahead of development in the process as it lets clients and users get involved more easily and lets us prototype stuff (e.g. in Adobe XD) before doing a complex technical build. This (hopefully) gets us closer to user-led design, but this was firmly a case of needs-must so we built it in the easiest way possible and then “skinned” it by dropping in some fonts, spacing, colours and branding assets, largely taken from the BITC brand guidelines.
Building on the shoulders of giants
Obviously we’re all standing on the great and broad shoulders of Lovelace, Babbage, Tovald, Berners-Lee and the like, but a couple of neat bits of tech/approach made our life much easier and might be of use to other who find themselves in a similar pinch (this will probably only be useful to developers and the like):
JSONB – Postgres allows you to store arbitrary data in a binary json column which can then be queried and indexed. It allows you to store data without creating a full schema which is important if you have, for example, rapidly-changing surveys to capture needs and offers. Once you have something more stable you can extract the key fields into columns to make the data a bit more manageable. It gives you many of the advantages you get with Mongo or other NoSQL databases, but with all the features you actually need from a database like transactions, aggregations, joins, etc. (don’t use NoSQL unless you really have to – it’s a database minus the magic).
SurveyJS – making and storing surveys can be very tedious, and SurveyJS makes it less bad. The great thing about it is that a whole survey with multiple pages/questions/options can all be expressed as a single JSON object that can be rendered into an HTML form by the library. It also has a suggested data structure for storing the output of the survey and comes with a handy “form builder” which is good to get you started and help you form more complex questions. It’s an open source library designed for developers so it’s got a bunch of useful helpers and plays nicely with NPM as well as React, Vue and JQuery.
Re-use views where possible – this is an approach rather than a technology but if time is tight it’s important to minimise the number of different things you need to define, build and test. In this product it was really important that the form used to submit offers and needs was tailored to the end user (e.g. businesses and charities) so we built them a nice form and then re-used that form for the admins when they’re managing submissions (with some additional fields). The listing of all the incoming needs and offers is more vital to the admins than the end users, so we built the listing page optimised for them and then stripped it back for the end users.
End User view:
Admin view:
Admins get much the same interface as the end users when viewing a single request, with an extra panel at the top, while end users get a stripped down version of the admin interface while viewing all the requests submitted to date:
End user view:
We’ll make all the code available via Github/similar as soon as we’ve caught our breath and checked that whoever pays for it is happy for that to happen (it’s still a bit unclear who that is but we’ve been reassured that someone will). In the meantime, email (harry@outlandish.com) or call (07738536552) me if you want access to it or to discuss how we did it and why.
So did we launch the new COVID-fighting tech platform in 24 hours?
Not quite. We launched a minimum viable product to internal BITC testers in 26 hours (at noon on Friday 27th following the green light at 10am on Thursday 26th). Full disclosure – the internal testers found some fairly major bugs until about 4pm on Friday which I think we’d more honestly call the MVP. Still, getting a pretty complicated product built, tested and launched in 30 hours is still pretty good and this was the timescale agreed by the client in advance as a compromise between getting something up fast and cutting all the corners.
It turns out the comms, sign-off and content take a little bit longer even in these extraordinary times but we’re expecting the main public push to be Tuesday 31st March – three working days from start to finish.
The launch version came in at about £11,000+VAT at our standard charity rate of £685+VAT/day. It broke down like this:
| Role | Total days | Amount |
| Senior developer | 10 | £6,850 |
| Technical architect (that’s what they call me to make me feel useful) | 3 | £2,055 |
| Project manager | 2.5 | £1,713 |
| Designer | .5 | £343 |
| Total | 16 days | £10,960 |
Shout outs
This was all possible because of a lot of selfless behaviour by a lot of people. Some of the selfless people I encountered directly were:
- Jess Runicles, Patricia Mensah and Pierre de Wet at BITC for rolling with the punches and cutting presumably large quantities of red tape to get a large organisation to move so fast
- John Dunford of Developer Society, Darshan Sanghrajka of Super Being Labs and Noam Sohachevsky of CAST who set up the call
- Gemma Hampson of Hactar who didn’t set up the call but has been working magic in the background (and we need more background magic)
- Dan Sutch of CAST who facilitated it and came up with a firm outcome in less than an hour
- Sophia “Puff” Story of 3 Sided Cube, Olly Howard of Reason Digital, Harry Harrold of Neon Tribe and Steve Hawkes of Developer Society who all stood back to let us have a crack at it
- Chris Ashworth of Nominet who brokered the kick off between us and BITC and arranged to underwrite the work
- John Fitzgerald and Calum MacÙisdean of the Scottish Centre for Voluntary Organisations who bent over backwards to try to help get the SCVO’s excellent Coronavirus support brokerage service to work for this use case.
