What 3 Years of Hacking for Humanity Has Taught Me About Building an MVP in a Weekend

For the last three years I’ve helped run a public interest hackathon in Sydney called Random Hacks of Kindness. The core idea is pretty simple — charities, non-profits and social enterprises (who we call ‘changemakers’) apply every 6 months with problems that could be solved by technology, and people who have the skills to solve those problems (‘hackers’) come in, form a team around each changemaker, and build some kind of solution over the course of a weekend and a few leadup events. By the end of the weekend, the team won’t have solved the changemaker’s problem, but they should have gotten enough functionality going to help with the some of it — essentially an MVP, but without the commercial aspirations.

In a perfect world every team would succeed in doing this, but sadly software is much, much harder than that. Even highly paid professionals working for years manage to fail to deliver a ridiculous proportion of software projects, and trying to get something done in a weekend with volunteers doesn’t make it any easier. In practice, Random Hacks ends up working like a bit like a startup accelerator — we start a lot of projects acknowledging that most will fail, but that a few will succeed… and those will help humanity!

With so many teams coming through and try to succeed under these tough conditions, I’ve found Random Hacks to be a bit like a proving ground for what works and what doesn’t for teams trying to quickly and cheaply ship an MVP. And I’ve found that mainly it’s about nailing basics — making sure you’re building what the user actually needs, keeping scope tight, and being comfortable cutting corners in order to ship something as soon as you can.

What follows is the simple practices that we try to drill into our teams — I’ve find that they’re not just useful for trying to hack something together in a hack weekend, but also for side-projects and for testing new features in my day job as a software engineer.

Best Practice Can Wait

Most people take pride in their work, which is great in general, but in the context of a hackathon it results in teams getting so absorbed in the elegance of their architecture or the simplicity of their UI designs that they finish the weekend with a beautifully designed but mostly non-functional collection of skeleton code.

It’s very rare to understand a problem well enough that you get it exactly right the first time, which is why we’re building an MVP in the first place. Most people understand this, but in the same way they understand that exercising every day is good for you… it makes sense, but actually putting it into practice is another story. It’s creepy to watch sometimes…. teams start out with a nice small plan, then are slowly drawn into overengineering, as if some magical force was acting on all their minds at once.

Shipping version 1 is all about being a Wizard, not an Engineer, and luckily in 2019 we’re spoiled for cheap, quick magic: products like Firebase, Netlify, Zapier, Google Forms, Surge. You can get so much done now by simply gluing existing (and often free) services together… you’ve just got to tolerate some jank, grit your teeth and not let perfect be the enemy of done. It’s easy to justify doing too much up front — “it’ll make users happy”, or “otherwise we’ll go slower later”, or “it’ll be more reliable”… but none of these will actually matter once you’re tearing all your beautiful hard work out in order to pivot your product towards the real problem after release.

The other important factor is that trying to get everything right at the start is a gumption trap — trying to get everything right leads to the members of the team worrying that they’re missing something, which saps motivation and leads to nothing getting done at all. Conversely, shipping is gumption-building — if the team can see that progress is being made, the feeling of momentum in the project builds and everyone’s willing to do more.

A classic example of doing this right were a team working for ACFID, who built… an Excel Spreadsheet. The changemaker could email it out, have their partners fill it out and return it to them via email. Sure, emailing around Excel files is far from sexy or best practice and building a big database-backed solution would be more impressive, but the spreadsheet was simple, quick and worked within the changemaker’s workflow… and as a result the ACFID team were the Winter 2017 trophy winners.

Sculpt out a Smaller Solution

Supposedly 20% of the effort will get you 80% of the way to solving a problem — while I’m not sure that’s empirically true, I have noticed that for most big problems, there’s a small solution that gets you most of the way there… it’s just often very hard to see.

Sometimes I’ll see a team commit to doing three times as much as they need to, achieving half of what they thought they would, and ending up with nothing that’s really useful at all. Sadly, the work that goes into a potential solution is like a tarpit — you only realise how deep it goes once you’re already stuck in it, and sinking.

It’s just a simple CRUD app, how could it take longer than a weekend? We can’t afford to lose this data… well I guess we can add streaming backups. Users aren’t going to be able to find what they want with filters… I guess we’d better add some kind of full-text search to it. What if someone malicious finds it… I guess we’ll need user accounts and role-based access control.

… and so it goes on.

Actually getting anything done depends on being absolutely ruthless about asking questions like “can you do without that?” and “would this other thing be ok even though it’s a bit crappier” — even if you think you can still get the better solution done in time! Cutting corners takes a lot of discipline — you’ve just got to keep reminding yourself that if you truly need to, you can always redo it properly later.

A great example of this was the Janubeard team a few years ago. Janubeard wanted to build something that could give everyone a virtual beard through the device camera. Rather than trying to break out the computer vision libraries and trying reimplementing Snapchat, the team instead built a website that superimposed a selection of beards on top of a feed from the device camera — rather than trying to attach a beard to the face, people just moved their face so it lined up with the beard. This meant that people got the same pictures they would with a far more complicated solution, but with a tiny fraction of the effort.

A Bad Decision Now Beats a Good Decision Later

One of the most common traps I see teams fall into is arguing over unimportant things. When you’re trying to get a first version of a product out, the only thing really worth arguing about is scope, and how much you can push out of it to get something shipped faster. Choices like cloud provider, programming language, tabs vs spaces etc. aren’t actually important in this contexts, because if your team is creating something so complex that rewriting it, moving it or reformatting it will be too difficult once you’ve shipped it, you’re trying to do too much!

It’s depressingly common to see teams lose more time arguing over using some cool new technology than they could ever gain from the productivity gains it offers. Far more important than making the right choice is making a quick choice and getting on with actually building the product. We encourage teams to agree on someone who can be the circuit-breaker for these arguments, before a decision actually needs to be made. This person isn’t chosen because they’re more likely to be right than anyone else, but rather because they’re prepared to make a call, even if it’s not the right one.

Not Everyone Can Pull Their Weight, and that’s Fine!

At Random Hacks of Kindness we try to encourage multi-disciplinary teams — developers, designers, product and project people can all contribute massively to the success of a team.

The awkward part is that while everyone has an an important role to play, there’s often no way that they can all be equally useful 100% of the time. Developers start slow while scaffolding gets set up then get more stuck in as time goes on, designers and product people start with an intense burst of activity then find they have less to do later as their direction and designs get implemented, and project people have the unenviable position of spending most of their time sitting around, occasionally asking for updates from everyone else to make sure everything’s still on track.

This can sometimes lead to a bit of awkwardness — it’s weird to be sitting around having a cup of tea and a chat while your teammates are working themselves to the bone. I’ve seen teams attempt solve this as if it was a problem by trying to teach people to take on different roles, but this isn’t a great use of time — it’s rare that a developer teaching a designer to program, for instance, will end up getting the team closer to shipping than just that developer working on their own.

This awkwardness is far from limited to hackathon teams too — it affects most teams, be they rock bands or newly formed startups. In all cases, the secret is just to embrace the asymmetry — it’s ok that not everyone has the same level of contribution, as long as that expectation is commonly understood, and reflected in who gets credit, equity or whatever else comes out of the collaboration. In some cases it’s actually desirable that not everyone is equally involved — for instance, at Random Hacks it’s better that a project manager doesn’t spend the whole weekend with their head down working, because it enables them to take a step back and see that progress isn’t happening fast enough to ship something on time and that the scope needs to be cut.

Move Fast and Fix Things

If I had to distill this down into one piece of advice, it’d be this: focus on shipping something, ASAP! So many other problems are alleviated by focusing on getting something working as fast as possible. Morale is higher when the team can see themselves moving towards having actual impact, arguments are easier to resolve when “will this mean we get it done faster?” is a trump card, how much individual members are contributing is less important if everyone’s trying to get something shipped, and the risk of going down completely the wrong track is mitigated by having not spent that long on doing so.

So if you’re keen for a crash course in building stuff fast, I’d definitely recommend doing public interest hackathons. Random Hacks of Kindness Australia has hackathons in Sydney, Melbourne and Brisbane twice a year, and there are other RHoK chapters meeting less regularly around the works. You can find out more on rhokaustralia.org and rhok.cc.