Hack days at Feather

Nikolay Shebanov

This article is part of our internal documentation at Feather. We build our product in the open and share our learnings with the community. We’re always looking for talents to join our team check out our careers page!

At Feather, we have a tradition of hack days. This is a regular event that takes place on Mondays, every three weeks. It's the perfect time for testing hypotheses, building quick prototypes, and trying ideas outside of our daily capacities.

We've had lots of fun over the years, and numerous hacks matured into systems that we use in production and in our daily routines. We came up with a process that is affordable and doesn't require a lot of organizational effort.

It's quite different from a traditional hackathon which would require the whole company to gather in one place for a week to brainstorm ideas (although that can be great too!). Our hack days are autonomous and distributed, and they work great with a remote team.

What to work on?

The project you pick for the hack day is completely up to you, as long as it is related to Feather. This is a perfect environment to test your own ideas or learn a new skill, but it’s also a great opportunity to collaborate with others.

This type of work can be very exploratory, so it’s important to put some constraints on it. It’s a good idea to focus on projects that you can deliver in one day, from start to finish. However, it’s not uncommon to work on the same idea for a few hack days in a row, especially if you hit a wall the last time.

A typical hack day project is a proof-of-concept for a new tool, technology or approach. For example, if you believe that we will benefit from introducing a new state management library on the frontend, you can spend a day to open a PR that demonstrates the benefits of the new approach.

Hack days are also a great way to make progress on your areas of responsibility or career goals that were defined in your feedback sessions.

The hack day pot

We use Notion to organize hack day projects and ideas. Each project would get its own page, with a brief statement of the problem and suggested solution.

Anyone in the company is welcome to contribute to the pot. When someone adds a new page, you’ll see a Slack update – this is an invitation to pick this up for your next hack day.

Whatever you work on, you keep all progress and discoveries on that page in a “log” format, adding screenshots and descriptions of what works and what doesn’t.

We use a project log template to make it super easy, just click on “New” in the table below and start writing. The template suggests the structure and contains a few useful prompts:

# What’s the problem?

*Write a short summary of what you’re trying to solve*

# Explored solution(s)

*Explain the solution that you’ll try to implement. If there is more than one possible solution, list them here*

- Solution 1
- Solution 2

# Current status

*What’s the current status of the exploration?
Try to keep this section up-to-date to make it easy to know what are the next steps*

# Next steps

*What are the next steps to keep working on this exploration?*

*This section should make it easier for you or other devs to pick up where you left off.*

*You can also remove this section if there are no more steps left.*

# Log

## {{CURRENT_DATE}}

- …
- …

Hack day outcomes

If you do the maths, a team of 10 devs that runs 15 hack days a year would end up with ~150 individual hack days a year. Not all of them will be fruitful, and that’s ok. Some will only bring iterative improvements and will be used as a learning opportunity, and some will fail.

But we have had numerous hack day projects that grew beyond the proof-of-concept phase and became an important part of our product and company. Below you can find a few examples.

Dirty Swan

We built and open-sourced our design system during one of our very early hack days. You might be able to tell from our website and motto that design is pretty important to us since “simple, honest insurance” means cutting away at messy UI. You can check it out at dirtyswan.design.

Migration to Customer.io

At some point, we realized that the notifications we send to our customers are becoming hard to manage and require a developer to be involved in every change. The solution to this problem came from a hack day: we switched from Sendgrid to customer.io and moved the hardcoded email logic to a clean event-driven architecture.

Feature toggles

At any given time, there can be multiple work-in-progress features that would block the main branch of the repo from shipping new code to production. Feature toggles, also known as feature flags, are a typical solution to this problem. It took us one hack day to evaluate existing SaaS and open source feature toggle services and settle on a self-hosted Unleash instance, and we’ve been using it ever since.

Moving to an open source CMS

As the company grows, so does its SaaS bill. Sometimes it is justified, but a few times we’ve ended up in a position where it would be cheaper and easier to self-host a perfectly good open source equivalent than to pay for a SaaS tool.

Recently, this happened to the CMS – let’s not mention its name – that we’ve been using for years. After a quick hack day experimentation, we realized that Strapi is available for free, can be self-hosted and extended easily, and would provide us with even more flexibility than we had with a paid tool.

How do others do it?

Imprint Privacy policy Terms Security Introductory information

Company insurance