In a little house on the windward side of a Hawaiian island, I sat staring at our product roadmap, not having the kind of good time one is supposed to have on such a trip.
Our product team was struggling. It was nine months since we popped the champagne on our last major release—a release we called Big Bertha. At the time, it was a major shift forward and what we hoped would only be the beginning. Our 2015 goals were set and we were ready to tackle them.
In those nine months our product team, though still small, had doubled in size. We were working hard with lots of late nights. We were refining our processes and trying to formalize our project management. We were getting stuff done.
But nothing was changing. It felt as if our product wasn’t progressing.
The rest of the company, our investors, and our members were wondering what we were doing. Perceptually, we were sitting on our thumbs.
And it was my fault.
Of the founding team, I’m the conservative one. I’m the Liam to Mikael’s Harry. Fiscally responsible and risk-averse, I’m conservative in everything but morals. (If you want to ****-up a ****, I’ve no problem with that.)
And yet, time and again, Crew is at its best when we take on big, giant, scary projects.
Like when we decided to completely rebuild our app and launch Big Bertha (Hell, it even had ‘big’ right there in the code name).
Or when we split our focus in two and built Unsplash when we were still only a 7-person team and looking for product/market fit.
Or when we decided to move out of our modest office space, buy an old bank, and build a cafe and collective.
We excel at those endeavours that require I keep clean underpants in the bottom drawer of my filing cabinet.
So I had to fight my instincts. We had to go big on the product side.
We convened on the beach in Hawaii and laid it out.
“What does the distant version of Crew look like? We’ve talked about possibilities but let’s make a decision. Then build it.”
And we called it Dream Crew
Five months after that day in Hawaii we are releasing a brand-new version of Crew. And boy is it different. The design is completely new. It’s a single-page app. It has live-chat and Google-fast search at the core. It’s your new home for the best freelance work.
Better: It’s fresh, it’s hip (or so I’m told) and it’s fun.
This is where a picture is really helpful though, so take a look at the before and after:
Back in Hawaii, I was having an incredibly stressful trip. So much so that I asked the team to dump me at the airport some 9 hours before my flight. And while I sat in the worst airport known to man, I opened Photoshop and did a (very) rough version of the concept we had discussed days prior.
When I got back to Montreal, this was the file I handed our (very talented) designers:
So, we had the ‘what’. Now what about the ‘how’?
The biggest shift technically is that our new version is (largely) a single-page app, whereas the old one used the standard page-reload model.
The challenge, from a technical standpoint, was daunting. Rewriting the entire application from scratch would have distracted us for too long. We still had new features to release every month and if we halted those, then by the time we were finished with the new version we would’ve lost a lot of market momentum.
So while there are a lot of great tools we could’ve used, it would’ve meant re-training the team. That was time we didn’t have.
We decided the best, if not quickest way would be to attack the rebuild through a series of interim steps. Each one would get us closer to our goal, while at the same time building up the knowledge we needed, and allowing us to release new features as market demands changed.
The trick, however, is that this is an ongoing process. Even the version that goes live today, which is pretty close to being exactly what we’ve always wanted, is in itself an interim step to the even longer-term vision of product and technical nirvana.
Here’s how we did it:
Step 1: Convert each page to its own real-time app
As we attacked each page (or section) of Crew we changed the behavior of all interactions such that there was no need for a page reload.
“Changed who can view a member’s profile and converted the profile page to real-time”
The “… and converted …” became pretty common in our commit messages and release notes.
After a couple of these conversions, we came up with a standard tool set and code pattern for how they should be done. Along with the the clearly-named
ajax-form component, we had less-obvious components like
psycho-panel. Linked to a data url, the
psycho-panel would reload itself any time a form on the page was saved. It was uncontrollable, hence the name.
(Fun fact: I’m not allowed to name components anymore.)
Step 2: Ghost features
The second step was adding the features we were going to need into the old style of the app. These changes didn’t look that different to anyone using the old app but were actually very different underneath.
For example, we added real-time notifications. Before, notifications would refresh on page load. With some nifty 3rd-party integrations, we got those to change in real-time as other parties took actions.
For example: If I was running two projects and, while sending a message on one, a part on the other was completed, my notification icon would change. Pretty standard stuff if you’ve used Facebook or any other modern web app but not something we’d ever implemented.
So we did. And no one noticed. Exactly as we had intended.
The other big ‘ghost feature’ was messaging.
We completely overhauled the underside of messages back in December to support a ‘channel’ concept and enable real-time chat with websockets and graceful fallback. After the integration, the UI looked the same as if the messaging was still email-style but the backend knew differently.
This set us up for the chat-focused experience and in-app support we are launching today.
Step 3: The ‘Flip’
By January, all the necessary pages were converted and the ghost features were in place. We came back after Christmas to do what we called the ‘flip’.
Our app, like many modern web apps, is based on the MVC pattern. You can google that if you’d like, but it basically means the code is split in three parts:
- There’s stuff hidden in the back (the M, or model)
- The stuff you see and touch (the V, or view)
- And the stuff that connects the two (the C, or controller)
Normally when you add or change a feature in such a web app you touch all three parts. The model changes for the data, the view changes to make it behave the way you want and the controller changes so the other two parts interact correctly.
The ‘flip’ was basically re-doing the entire V (view) without touching the M (model) and only making modest changes to the C (controller). In reality, the biggest changes to the controller layer were deletions because our new patterns simplified a lot of logic.
More on the flip
Completing the flip was intense. Luckily, just before we got started we brought on a couple really great specialists on front and back-end to match our already great team of generalists.
Then, to do the flip, we agreed this was when we could (and had to) stop everything else and focus only on this new release. For two months, the entire team gave everything we had to bring it all together. It was a symphony of code construction the likes of which I’d never seen before.
Our deadline was Feb 29th. We added a week at the end for more polish and posted it to our staging server for the rest of the company to review on March 8th.
Today, after another month of revisions, it goes live. We hope you like it.
Advice for if you do your own major rebuild
With Bertha and now Dream Crew we’ve done significant rebuilds of Crew twice now.
Each time we vow never to do it again, but agree it was the right approach at the time. From here on out, we are moving to full continuous integration and deployment.
But that’s not the right choice for every project. So, if you’re attempting a big build yourself, here are a few pieces of advice:
1. Get buy-in from the whole company
I stressed early on in the design phase to share our progress with the company. This is made easy with the weekly updates we send anyway, but it’s very important to get everyone on board early. A major product shift will change everyone’s life at the company. They’ll want to know exactly what’s coming. Change is scary. Over-communication will reduce the amount of fear.
2. Do it in steps if possible
Doing major packages of work all at once is a gamble. Think about how much you’re spending in salaries and burn. At another startup years ago, I worked on a project for a year that got scrapped just as it was completed. That was our team’s entire salaries up on smoke—not to mention the brutal hit in morale we suffered.
3. Plan like you’ve never planned before
Good product teams can wing it when a small new feature isn’t well defined. But if you have a major project with obvious gaps, every member of the team could be mentally filling those in differently. Take the time to sit down together and try to poke holes in the plan. Then, make decisions. It doesn’t matter if they’re the wrong ones, make decisions and stick to them at first. A wrong product choice well executed will be a mistake your team can correct. A mess of varying intentions can cause tension and destroy your team’s desire to fix it.
The biggest lesson from our last major launch
Last year’s major release without the right follow-up taught us one thing: Celebrate but don’t stagnate.
Today is a joyous day for us, but you can be sure we already have plans for the next steps—to continue pushing ever forward, further than we think we can.
Today is just the end of the new beginning. And I couldn’t be prouder or more excited.