6 days to design and build an app in Spain
Our Hackathon events are great opportunities to practise working to extremely tight deadlines. Our most recent event, held in a Villa near Granada, Spain, delivered a photo-sharing app in just 6 days. Based on what we learned during that time, here are a few tips and considerations that will help you deliver products quickly but without lots of stress or late nights.
Planning
Let’s assume, like with our hackathon projects, that you don’t have wireframes, tech specs, Jira boards and all the other prep that we usually have at the start of a client project. This time, you have nothing but a problem to solve and only six days to deliver the product.
Yes, we need to move fast and start building with minimal delay. Plus, we can accept that the end result might turn out differently to what we expect at the start. But even with just 6 days, a little bit of planning goes a long way.
When so much is unknown, how do we measure success? It's probably useful to reframe your idea or problem into a User Story or Use Case. This becomes our guide for the project and will help us decide which features are important and which we can drop. We can use it to decide if we’ve delivered on the brief even if the twists and turns along the way have shaped it into something we hadn’t anticipated.
Use Case: A group of 8 friends are going to Cornwall for a walking weekend. Instead of messy WhatsApp groups, they want a centralised pool for their photos that's easy to review and enjoy at a later date.
Brainstorming ideas and features is a great start. But don’t skip the review & prioritisation. What’s essential for the end of the week and what is a stretch goal? What can we compromise on? Perhaps not everything needs to be perfect this time. By our self-imposed rules, releasing something sub-par is better than unreleased perfection.
Sometimes analogue solutions are the best
Tasks & Progress
Some very light-touch PM wouldn't go amiss. We used Post-its on a big mirror to record key tasks and track what their status was by moving them to the right-hand edge with each update. This is also a great way to assign tasks to everyone on the team. It's simple, quick and everyone can see what's going on at a glance.
But there are lots of other approaches you could take, just try to keep it low-effort and flexible.
The progress tracking is important. You need to know when to drop or change a feature that is not working out. It's the same story for any new tools or libraries that have started to become a blocker. Re-consider the cost / benefit ratio if it's not obvious what to change.
Standups and demos
Another low effort, low time-cost tool is the daily standup. If every team member can deliver a short (<1 minute) update in turn, then you set the whole team up for the day and ensure upcoming problems can be anticipated in time.
Plan time for testing and bug fixing, but don’t leave it all to the last day. Ideally, find a way to test during the week. This implies regular releases / deploys during the week, but the extra overhead is worth it to allow everyone to review and feedback as you go.
Consider your release / deploy process. Can you quickly deploy and review code when bugs are fixed and new features added?
Tech Stack and tools
A hack is a great opportunity to try new tech. When you have a clean sheet to start from then you can look to take advantage of tools and libraries that claim to save time during production.
But be wary of over-stretching and committing to too much unfamiliar tech. If things go wrong then you can lose more time fixing than you’ve saved in speed.
A great example from our recent Hackathon event is a Password-less Auth called ‘Auth0’. This has saved a huge amount of time in development and testing. But bypassing AWS’s standard auth ‘Cognito’ was a bit of a learning curve and so the cost / benefit ratio was not clear cut.
Be aware of bottlenecks. This applies to tech choices and team members. One of the worst feelings during a tight project is realising that several of us are twiddling thumbs while we wait for a blocker to be removed.
You’re probably already aware of the power of wireframing. Arguably the fastest way to communicate ideas to a team that's all in the same place is to use pen and paper.
Mindset
Finally, it's worth thinking about how we approach the project from an attitude and mindset point of view:
- Expect that things will go wrong
- Be flexible
- Communicate with the team regularly and clearly
- Don’t let people silo themselves
- Allow everyone to have a voice
- Don’t be precious with your ideas or opinions
These are some considerations you should keep in mind when starting a project with a very tight schedule. Hopefully, you can apply some of them to your own projects and even unlock some innovative ways of working in the process.
To learn more about organising a successful hackathon, check out our previous article, ‘How to run a Hackathon’. If you have a project that you'd like to discuss then we'd love to hear from you, so get in touch.
