Last week, I designed an onboarding flow for Cushion that would ease people into the app, rather than dropping them right in. As I geared up for the weekend, I tried to get the design in order, so I could make the most of the two full days I’d have to focus solely on Cushion. Even after working on Cushion for six years and programming for more than 20 years, I still don’t have a strong ability to estimate with accuracy. On Friday, I figured I could finish the entire onboarding flow this weekend. As I started building it the next morning, I watched as the fractal tree of subtasks began to spawn. It became clear that this onboarding flow wasn’t a weekend project.

Luckily, I’m in no rush with Cushion, so I can afford to learn from these hiccups. The beauty of a side-project is that it doesn’t (or shouldn’t) have deadlines—it’s a sandbox where you can spend extra time before returning to reality. I think my excitement to build gets in the way of my ability to estimate. Whenever I need to figure out how long something might take, I should really have a go-to method for simply starting that thought process—even if it’s a text doc that says “Jonnie, break the task down into smaller tasks.” Instead, I’m like the casual mechanic from TV who says something like, “Eh, it’ll probably take a few days—give or take.” Even worse, from my freelance days, I respond to the question, “Can you have it done by this date?” as if it’s a challenge, which often results in me breaking my back over a fictitious deadline.

For the onboarding flow, I had the initial design, so my first thought was to build the components that I didn’t have yet—mostly form elements, like the radio button field, color field, date field, etc. I do have these in the current Cushion, but they’re not tested, typed, or documented. For any new code in Cushion, I’m committed to building them the right way, so the structure could guide me in my decision-making and leave me with a strong, confident codebase.

As I started to build the radio field, the branching started. I wondered if I should compose the component using the existing field component that I already have if the radio field’s label is laid out differently. Radio buttons are handled somewhat differently than regular input elements in Vue.js because they have a value and a shared value, so I spun my wheels structuring the component around that. Since the radio field is similar to the checkbox field, I wondered if I could take care of both in one go. Before I knew it, the morning was gone and I didn’t even have a radio button field. I feel like my estimates were still calibrated for the old way of building the app, which simply involved writing the code heads-down and making sure it worked.

I decided to take a step back and actually list everything involved in building the onboarding flow. (Smart thinkin‘, Jonnie) Instead of starting with the low-level components, I started from the top and worked my way down. I needed a view for the onboarding flow, which requires a route and a template. The onboarding flow needs to fetch the user and update it, so I’ll need to make requests to the API. The flow is housed in a modal, so I’ll need to build that, which includes an avatar, header text, a form, and a form button. The form consists of several steps, so I’ll need to break down each step. Each step has a few form elements, so I’ll need to compose and/or build those, too. Some of these form elements are special and more complex than a simple textfield, so I’ll also need to write the logic for those, but also build the additional subcomponents for them. And, I’ll need to write tests for everything.

As soon as I finished listing everything, I knew I wouldn’t be able to accomplish this in a single weekend. Now that I have limited time to work on Cushion, I really need to temper my expectations and better define what “progress” means, or I’ll only feel like I’m not accomplishing enough. While it was amazing to work full-time on Cushion for a few years, I actually prefer the structure that’s forced from this limitation. Not being able to work on it all the time really helps me slow down and think, whereas I’m usually quick to go full speed ahead. Obviously, I still have to remind myself to slow down, but this experience was a good reminder.

Now, my goal is to finish the new onboarding flow before the end of the month, in time for the monthly newsletter. Two weeks to build this onboarding flow would’ve been a joke when I was full-time on Cushion, but time is stretched now. I’m not looking for a quick turnaround. I know it’ll be a long process of slowly shaping Cushion over time. And if I continue to think about Cushion as a “lifetime project”, two weeks instead of two days is negligible. It’ll be a blip in the long run.