Building a Product in a Day

A couple of weeks ago we had our first ever Made Hackathon day, where we built a product—based on an existing idea—from scratch, and had it launched by 5pm. It was great fun, and very rewarding for the whole team.

The result of our efforts was SSL Catch – a service to notify you of expiring SSL certificates for your domains.

We’ve had a couple of clients who have had their SSL certificates expire because reminders were being sent to unmonitored or old email addresses. And there’s nothing worse than getting a scary looking browser warning when visitors go to your site. Even mega-sites such as Instagram sometimes forget to renew their certificates. SSL Catch lets anyone setup automated reminders for any domain leading up to an SSL expiry.

How were we to pull this off in around eight hours?

MVP

We had a 10 minute MVP (Minimum Viable Product) discussion at the start of the day to discuss what the bare minimum features that we’d need to implement for it to be useful to users would be.

What we needed was the pure basics, with a few stretch goals if we had the time. Also, it was essential that we the product be launched by the end of the day – so any features included in the product had to be feasible within the time period we had.

The MVP for SSL Catch? A form where a user can enter their email address and a domain name to monitor, submit the form, and get notified at various intervals in the run up to expiry. That’s all we needed for the product in order for it to be useful.

Breaking it down

Based on the MVP, we used post-it notes to determine a breakdown of tasks that would allow us to achieve this, including the stretch goals. These were broken down small enough so that one person would be able to work on each.

Once the tasks were in place, stuck on a wall, we spent a small amount of time trying to figure out a priority order. This included some thought on what things would need to be in place from the very start, and anything that might potentially block the team later on in the day – it’d be best to tackle those things early on.

Based on the priority order, we went around and handed out one post-it note to each developer to take away to work on.

The tasks we committed to:

• Build a CI pipeline with automatic deploys direct to production
• Work on a library to check for SSL expiry dates
• Setup background jobs to handle the expiry checks
• Background tasks to send reminder emails
• Styling of the website, including a logo
• Email template design
• Signup functionallity

Communication is key

Communication is key when working at such a fast pace and in a team. Everyone really needs to be aware of what everyone else is working on so that everything fits together nicely, and so that a steady pace can be kept throughout the day.

We had a standup meeting every couple of hours to monitor progress. Everyone in the team would bring their current post-it note and update the group on its progress. If someone was finished with a task, they’d then claim a new post-it note off of the wall to tackle next.

If anyone was having issues, or if a task was taking longer than expected, we’d try and break it down further so that another person could help on that feature, but without stepping on people’s toes. If the task couldn’t be split up, we’d pair program to try and pick up the pace.

Only if existing tasks were completed, or outstanding tasks couldn’t be broken down/split up, would we then work on stretch goals.

End of play

By around 5pm, SSL Catch was ready to showcase internally. All of the pieces come together and we did a demo, and then let it loose on the internet with a tweet.

• We had five people working on the project.
• For most of the day, that involved 2 working on code, 2 on styling and 1 on infrastructure, though we mixed it up a bit when needed.
• We had 108 builds on our CI server, and 59 production deploys.
• Our repository has a total of 186 commits.
• Our build time is 46 seconds, with a deploy time of just over 3 minutes.

About the Author