Lessons learned from rebuilding an entire tech platform from scratch
I am Julien Balmont, co-founder and CTO of 1001menus, a marketing tool dedicated to restaurants’ online visibility. Today, I’m very proud of our tool, but it wasn’t always the case. Here the story of how we rebuilt our entire platform from scratch.
September 2013, 10pm, while having a drink at the office (ok, while having several drinks at the office):
CEO: I have to tell you something … Hard to admit it but, DAMN, I can’t stand our product anymore! Customers don’t want to use it, Support keep complaining about it, you keep saying it’s hard to maintain and don’t get me started on the design…
ME : Dude, tell me about it …
CEO : So let’s make a new version!
ME : Hmm … NOPE.
CEO : … (try to picture him with a mix between puss in boots eyes and a puppy asking for a candy)
ME : Well, you know me, I always say no for the sake of it
CEO : … (this time, picture a kid in front of Santa himself)
CEO : So … we’re doing it??
ME: Fine, let’s make a new version!
CEO : Cool. The baby will be here in 9 months!
ME : …
This is how the conversation sounded like or at least how I remember it. And trust me, I had no clue that would be the beginning of the tragedy… We should have had a meeting (or several) with the team, get some feedbacks, third opinions, and more importantly, an estimate of the time needed. But you know, we were tired of our product and wanted to change to something new. NOW. For developers, “new version” means newer technologies, brand new code, brand new database. And I love challenges…
I could say this was a difficult project, but it really was not. Launching a V2 does require a little bit of structure, preparation, and motivation. By sharing my experience on this, I hope you won’t make the same mistakes and just take some time to plan everything…
Motivation is key for a long-term project
1/ The development team has to know “winter is coming”
Depending on the product and the volume of code, a new version can take weeks, or months (or even years?) For us, it’s been months of rush and loads of stress that comes with it.
In a startup life, the development team who worked on the original product (interns, first employees, etc.) has usually changed when comes the new version. You may know what’s coming… but the newcomers don’t. And you need to prepare them.
You absolutely need to find a way to prepare and motivate the whole team, before, during and after the project.
Mistake #1: Let’s be soft with myself and say that I didn’t master this rule ;) Caught up in the stress of the project and the need to deliver in time, I didn’t take the time to brief the team, show them what they will face and do what a manager should do: make them believe everything was gonna be ok…
2/ Step by step (ooooh baby)
It’s in our DNA to produce fast, fix some bugs, have many small tasks accomplished in one day. V2 is different. It’s a long-term project, but you need to cut this big cake. One part at a time, one task, one objective. I didn’t do this. I didn’t congratulate my team, show what they created already, brief them on the next step, etc. The only meetings I managed to do were to put more pressure on them. Not a smart move…
Mistake #2: There is a reason why Scrum has been created. Agree with it or not, respect the rules 100% or not. You need to cut the project in small parts. It’s the only way to keep the motivation and end up with a better product.
3/ Listen to your team
During my whole career, — and that’s how I’ve been taught development during my first real job — I’ve always developed a sort of extremely AGILE way. You don’t write anything, you don’t prepare anything, but you make little steps working hand in hand with the product team. And until then, it always worked for me in small teams and small projects.
Meetings with my developer team? While the team was working on the new version, I was working extinguishing fires, on the old version, and all the other projects, trying to fix everything and keep things going. So I just decided I didn’t have time to do meetings and I just skipped them. My team asked me so many times to have some specifications for each new functionality, to write down at least some information. But no. They had to figure out by themselves.
A little bit of communication within the team would have led to sharing some good ideas and bits of code and could have saved so many times…
Mistake #3: I’ve been the stubborn guy and didn’t listen to the team. If they ask for meetings and information, take some time to meet their need.
Better choose wisely what you don’t control (technology & third part)
1/ Prepare to face new IT challenges
New version means new technology. And what is better than one developer looking for the best option? Many developers looking for the best option! I decided to involve the whole team to make this choice. It did include some meetings and long discussion, but it was totally worth it. This challenge became their challenge and not an order coming from their +1. Were we talking about motivation? This is a great tool to boost your team.
Smart Move #1: Make this decision as a team. Train the team. Learn from each other while you build this V2
For us, it’s been a brand new PHP framework. We’ve changed from Zend Framework 1.12 (I knew it inside out so easy to work with but let’s face it: totally outdated) to LARAVEL 4.3.
By the way, a few words for those who think PHP is outdated / so 2005 to try this framework out. The best PHP libraries have been used, rewrote, extended and gathered together as long as namespaces, closures, interfaces, a RESTful route system and so many wonderful things… In one word, AMAZING ! To try it is to love it.
Smart move #2: Being able to rely on a good framework, with a large and active community is comforting.
2/ Outsource design? Not such a good idea
Without any designer and front-end developer, we had to work with a web design agency to help us on the product UX/UI, and integration of the Javascript. We wanted a good JS base to rely on so decided not to do it internally.
Skills of the agency we worked with aside, we already knew what we wanted, but they kept pushing in another direction. They persisted in a wrong way with the UI, thinking their point of view was the best one. It’s true it is their expertise but we knew our customers. And they wouldn’t have been able to use this. After weeks and weeks of discussions, phone calls and back and forth, final new design has been sent to their integration team and the full package with JS/CSS/HTML delivered few weeks later. The result? it was incompletely done, there were missing parts, we ended up rewriting and refactoring most of the Javascript and we were already 2 months late on the original timing.
Mistake #4: Using an agency instead of internal resources. They are experts but if you don’t have time to guide them, structure them and harass them, you will end up with a “so so” result .. And late!
Go live no matter what? NO!
This is the worst decision we made about this project. And the more I think about it, the less I understand how we made such a decision.
We lost 2 months because of design issue but we still decided to go live with the new version on the D-day. Why? Because we chose this date 9 months ago. The reality? We were not ready at all. 70% of the new version was ready. Consequences? Change of plan. We had to make an incremental version upgrade, and keep using the old version. Because our customers had to go from V1 to V2, we had no other choice but modify all the V1 code to fit the new database scheme. What a waste of time!
Mistake #5: I should have put my foot down. Refused to launch the product. Said we were not ready and that the risk was too high. But I kept quiet. Because I didn’t want to admit we screwed up the deadline? Because I didn’t want to tell everyone I wasn’t Santa? Or maybe because I’m a real optimistic person and believe a unicorn will fix everything. Not sure why I shut up. But it happened.
Rule #1: If a project delivered with a little bit late will not put the company in a difficult position, a product delivered with bugs can make you customers leave and lead to an intricate situation.
What a day this D-day
To sum up the situation: 70% of the new version was ready. Old version was also ready. Bridge between both versions was ready too.
Finally the day of the migration came. Well, actually, the night of the migration. That night, I decided to take care of this all by myself. Me & My MacBook. Confident. It went surprisingly well. I tested everything, some data migration scripts took longer than planned, but no big deal
But the next morning…
Clients calling from everywhere:
- « I can’t find my pictures! »
- « I don’t understand sh*t with your new design »
- « I can’t login anymore »
- « I can’t manage my bookings anymore »
Even worth, complains arrived from our customer support team himself. Not because of the amount of calls, but because of the new product, not working, not handy…
Mistake #6: Not having the new product tested by the support team. Their feedbacks would have avoided so many problems, bad customers opinion on the company. And I’m not talking about the frustration it created on the support team. Clearly not what we call a great management decision…
So, here we are. V2 is online. Customers are complaining. We need to work well and fast. This, I can do. And so does all my team actually. But you need to make sure everyone who worked on the project is available and ready to help testing and fixing latest bugs.
Smart Move #4: Applause to my team who kept their cool and managed the stress of all the other departments of the company…
Consequences of this decision?
We spent the next two months debugging and finishing the new product. That’s why, at the beginning of this article, I said the developer team should be prepared for the after project.
After this, we decided to adjust developments, to plan better and safer.
We had a meeting with the product and the developer teams, to debrief and identify what we could have done to avoid all of this… It was THE moment to talk honestly, to accept being criticized.
We decided to use SCRUM. Not all of it, as I still have issues with the daily meetings. We still have a small team, and with all the projects we have to deal with, I believe daily meetings would only be a waste of time. But we are in the right track, we can feel it!
All the issues we’ve met may sound obvious to some of you. Or not. But if my feedbacks help at least one of you, developer, CTO, product manager, then I consider it worths it. We’re now 7 months after the launch, and looking back, this is one of best experience I had. We’ve learned so many things! It structured the team and the way we approach every project we have to start from now on. As i’m writing those lines, we’ve just launched a V2.5. A fresh new design on top of the V2. And a huge code optimization. And you know what? everything went fine ☺ 5 minutes deployment, no bug… So proud of all the team!
This article is part of the publication Unexpected Token powered by eFounders — startup studio. All eFounders’ startups are built by extraordinary CTOs. If you feel like it could be you, apply here.
You like? Hit “Recommend” and subscribe to our collection!
