Note: I am not naming this company because I do not wish to be harassed by the owners of the company, as they have done more for talking about less. I also think that the lessons learnt are widely applicable across various companies at myriad levels of incompetence and toxicity.

When I joined the company, I was told that there would be a lot of work to get done. Now I'm not one to shy away from work, and when I joined, I was looking to prove something to myself - that I could build something to completion. Before working here, I had built several proofs-of-concept, minimum viable products and hackathon projects, but nothing that I felt particularly proud of as a developer - nothing that stood as a testament to my abilities or what I felt was an accurate representation of what I could do. The coming four months were about to change that.

I feel like this would be a good time to mention what I was getting myself into. My task for the next few months would be to rebuild an existing platform - a platform with search capabilities, a marketplace, the ability to create shortlists, a recommendation engine, making bookings, requesting quotations, a messaging platform, integrate payments and authentication. And that was just on the end user side. I also had to build the admin dashboard and a super user dashboard. And I'm the only front-end developer on the team.

Any reasonable or experienced developer would have said no to this request out of hand. No way was this possible. And yet, here I was, filled with all the determination of someone with something to prove, and the naiveté of someone who hadn't yet proved anything. And so, I accepted the job and set forth.

Within a week, I was designing the tech-stack. I had barely understood what the business does at this point and I was already being asked to make design decisions (This, in retrospect, was mistake #1). I had been persuaded and not incorrectly that SEO was critical and hence had decided to use Next JS, a technology that I was not really familiar with and therefore was not able to implement properly (mistake #2). However, the rest of the tech stack I was pretty familiar with - React, Redux for the front-end and a Bootstrap framework to make designing easier.

If you're wondering why I didn't use the existing framework and decided to build from scratch, there's a good reason for that. The old site was a monolith of code encompassing front-end and back-end built in ASP.Net and was just incomprehensible with no documentation or consideration put into it. In retrospect, I may have been too harsh in judging it and in my estimation of what my own code would look like. It was naive, although I do believe that despite my naiveté, the current codebase is a lot cleaner and a lot easier to follow.

It was around a month into building the project that we started getting requests to redesign some of the pages in order to make them easier to use, prettier, responsive on mobile, etc. All necessary and reasonable requests in a normal timeframe. However, this increased the scope of the project without changing the deadlines. An already ridiculous project had just got more ridiculous and we went along with it (mistake #3).

A brief non-sequitur here to talk about the changes that we were supposed to be making. First of all, there were not supposed to be any changes to design or flow at all. V2 was supposed to be a rebuild to improve the tech stack, not the design. So from the perspective of the end user, they should have had no indication at all that we had just had a major system overhaul. However, in the somewhat paraphrased words of Ulysses S Grant, mistakes were made. There was no CTO, neither task board nor Jira, nor scrum or agile or any sense of project management whatsoever. And thus, there was no accountability or any way of keeping track of what the engineering team was doing, or a clear way of reporting it to rest of the team. So the product management side was completely botched. In addition to this, however, the designs were not tested to make sure that they were intuitive. They were pretty, they were responsive, but there was no user testing done until after the designs were pushed to live if they were actually a better user experience (mistake #4). I cannot emphasise how much of a no-no this is. As a result, we ended up changing the homepage and flow every week. On live. So put yourself in the shoes of a user. Every time you come back to the site, you see a different version. I cannot imagine something more disorienting for a user than that.

Anyway, cut to a couple of months into working on the project. Things are clearly being delayed but no one wants to change the deadline, because we are paying an offshore shop to maintain the live site. It's something that infuriates me still - imagine being on the Titanic and having the foresight to see that you're going to hit the iceberg and doing nothing to course correct because you don't want to use more fuel. Yes, it is that ludicrous. So instead, we keep building and building. By this point though, I think some glimmer of sense prevailed and they hired a remote front-end developer on contract. Great. That is somewhat helpful, since I don't have to build the entire thing myself. We start making some progress, but it's not quite enough. The other dev can only work a couple of hours a day, which is not a lot. So what do we do? We hire another developer (mistake #5).

As you can see by the fact that I've labeled it mistake #5, I do not agree with this decision. There are benefits to parallelisation, definitely, but there is a limit to how much you can parallelise things. Parallelising things is very rarely, if ever, less overall work. There is the overhead of introducing someone to a new project, making sure they understand what they're working on, ensuring that the code is of a certain quality and consistent with the style of the application, ensuring they're on track, and even with a decent programmer and a normal schedule that's a heavy workload. But now I not only had to finish all the work I had to finish, I also had to introduce a new programmer into the fray and get them to work on things. Some things can be parallelised. Others can't. For some reason managers think nine women can give birth to a baby in a month. Surprisingly, they quit within a week or two. Not that I blame them in the slightest.

Ultimately, we're down to a couple of weeks before launch, and this is when people start taking a look at the system and go, everything is wrong. We have to rebuild parts entirely, major overhauls of other parts and honestly, even 2 months after launch, we're still picking up the pieces of what we should've done right. But we got it done. It wasn't working 100% the day of the launch. We had major live bugs and page crashes for weeks after, and things still keep breaking. However, kicking and screaming and crying, v2 was born.

So how do you build a web platform in 4 months? The short answer is: don't. Seriously. Don't do it hoe. Here's what you should do:

1. Know what you're building before you're building it - Make sure you know exactly how something is supposed to work, down to the copy, every error state, the flow. Know as much as you can about the product before building it. And I know this isn't always possible. Things change, and if they do that's okay. Just as long as everyone recognises that things have changed and will need to be rebuilt and will take longer as a result.

2. In a time crunch, use the tools you know best - This is of course assuming you know the tools. If not, you have to pick up things on the fly, which is fine - that's how you learn. However, a time crunch is not the best time for experimentation. This is one of the things I mostly did right and I'm glad I did. I did have to pick up things as I went along and that's part of learning. I just wish I had more time to really do it right.

3. Avoid scope creep like the plague - So this is something where you need a product manager or a CTO on your side who can stand up for the engineering team. We didn't have anyone, unfortunately. I wish we had someone who would. As a relatively junior developer scared of getting fired and needing to prove to himself that he could actually build something for a change, I didn't put up much of a fight. I've learned my lesson the hard way. Developers really get treated like shit a lot of the time by people who don't understand tech. But as developers, we really do need to learn to stand up for ourselves.

4. Test designs before you build them - Before, and after. Test, test, test. Do UI/UX tests, flow tests, QA tests, unit tests. The more tests you do, the less it's going to break when you put it out there. We put a completely untested site into live, which was a big mistake. Yes, it would have taken more time. But we could have avoided frustrating users with a broken product, and not had to rush out hotfixes to every issue and fixed them right.

5. More people doesn't necessarily mean things move faster - There is a fine line here, but beyond a certain point, having too many people just meant more conflicts, more management instead of development, more inconsistency in the codebase due to different styles, more explaining the product and more bugs. I think adding people once we had a chance to come up with a standardised process or from the beginning would have been the way to go.

6. Communicate, communicate, communicate - This is something I wish I did not do enough of and I wish I had done more. Communicating early, communicating often and communicating in entirety. We might not have discovered things so late had we done a better job of getting everyone on the same page about what we were doing.