How this came about?

The founder of this company, was a dear friend from high-school. Our paths crossed multiple times. He exhibited his entrepreneurial ways pretty early on. Considering it was only a handful of us from that part of town that went on to pursue tech.

When I left my previous employment, and started working on my projects, we got in touch and he kept a pulse on where I was at. Without any pressure, he always kept his hand out, if I ever needed. I would like to think that he also knew how he could fully use my expertise to take on bigger projects.

Covid lock-downs were the downfall of many event companies.

It is arguable that many businesses were hit and no one industry suffered the brunt of it. But, when you think about it, remote work became a thing, almost overnight. As did the events, evaporated into thin air.

TPI primarily dealt with events but also had a couple of tech projects with some clients. When everything came to a screeching halt, my friend went on to quickly mobilise his tech team and come up with a MVP for an online events platform.

As much as I thought it was brilliant at first, he was not the only event company looking that direction. Some big name event organizers had entirely pivoted their businesses to online events platforms. Of which, a handful were VC-backed to the tune of 10s of millions.

Even though his platform was quick to market, it still looked ages away from the big boys. Tech stack had proved to perform at same levels as them, but something just gave it a very amateur feel. It was at this point he had reached out to me again at about my year mark since leaving my previous place. This time I said ‘Lets make some magic’.

Research & Analysis.

Since the platform was put together in a relatively fast manner, it was obvious much of the effort was focused on the engineering aspects. A lot of the UI/UX and design matters were either chucked aside to address at a later time, or used some standard components that came with the template.

Trust a mechanical engineer to build a car, most of them will build for speed or power.

It is no one’s fault to want to build to their strengths. Engineers in my opinion are the most brilliant minds. But not many come equipped with an eye for design. If you do, hold onto them like a prized lottery ticket.

It took me a whole month to just understand every single workflow there was. It was pretty mangled up with many quick-fixes that were put in place just enough to make it function for the next upcoming event.

Speed was the name of the game. As much as everyone would love fancy and shiny things, he needed to close as much business as possible. So, meeting every client’s needs at the fastest way possible was what he was gunning for.

We knew time was not on our hands, especially fighting against the VC-backed big boys. Clients still came to us because of the ‘bespoke’ service we provide. To hold their hands and walk them through the event together.

Design.

As I finally got familiar with the platform, I figured the number of people using the backend system was far fewer than what was intended. As much as we envisioned a self-serving events platform tool, it was also apparent companies wanted the ‘hold my hands’ treatment.

The user-facing frontend, had a far longer reach and was where most of the eyes were. Even the companies that came to us, always only paid attention to the audience view. When given a chance, they would much rather not touch the backend of the platform on their own.

One-size-fits-all, does not work all the time.

All the other platforms tried to use the one-size fits all approach. Similar templates, layouts, colors, etc. We were headed down the same direction. But as more and more clients came, we realised it was all the customisation we were giving away, in the name of building our app, that they were really after.

Without stripping off too much of the audience view, I got to work on creating a v2. Working with engineers, I have come to learn that there is a certain threshold to the amount of vanity changes that can be done at any given time.

Threading carefully, I started making the most slightest, but impactful UI/UX changes. Things that looked so subtle, the Engineers thought I was mocking them for giving them such menial tasks.

This allowed me to size them up, see how much they can churn out and to what degree they can get it done as close to the given specs. As much as they can solve complex engineering problems, when it comes to the nuances of design, they always miss some details when trusting just their eyes alone.

Development.

The devs worked hard. My plans for the sprints were simple, 5 UI/UX related changes on the audience view and 2 other updates, deployed every Friday. Things were reviewed every Monday, and we minimised the communication so that more work can be done.

In the following month, the product already started embodying a very professional image. Although it still lacked the finesse of some of the big competitors, where they have 100s of engineers and teams of designers, we were proud of how far we came.

Tell a client you made some DB changes that results in 50% increase in performance, they will still ask you about the missing full-stop in one of the paragraphs.

Always do what the client wants to visually see first. That always allowed us time to work on the bigger tasks which they should be fretting about. It is not devious, but it is the best way to keep emotions at bay, when rushing for time.

Because the system was built by their engineers from the ground up, we had to work with some limitations that came with AngularJS. Not trying to throw shade on any language, but as a ‘non-techie’ myself, it is much easier finding references, and much cooler plugins created by the wider community for some of the newer stacks.

When development is done and our QA process kicks in, it also helps for us to fill up what, where and what we think is the likely cause. We will also try throw in some reference material we find online for how we would solve it.

Ship to customer and their reaction

As the first commits of the ver. 2 was rolled out to our new and existing clients, we received high-praises. Some changes, as expected were more well-received than others. But, there were also some surprises.

For some of the bigger clients, they felt like they liked the system as it was. From icons, to the color schemes used. At first, we were going to roll back the changes for that client. However, we also realised by doing so, we were going to end up being an events site builder rather than a platform.

We had to take a decision as a company, and thought it would be best we stuck to our guns and powered through with the platform-wide changes. We also mentioned to the clients that the customisation will be a little bit more restrictive as we grow. After all, people do not question Zoom, when they swap their icons to a new set.

Tell your customers why you are doing it, most often than not, they will understand.

By explaining our direction as a company, and what we love to do for them, most clients understood why. For those that had trouble adjusting, we allowed customisations to stretch for a longer period of time.

Today, the platform has served some very notable and honourable guests. The product was just constantly improved over time and started to require lesser and lesser of a maintenance. We progressed to other projects and features that made it more polished.

As much as we want to look like the big boys, we never copy or lift any features directly. Most often than not, we try think of every flow from the ground up with no references, and only after that do we see how the rest have done it.

That way, we preserve the honour that comes when that feature is shipped and well received. We also make sure, in the race to the top, we do not want to end up looking and behaving like every other events platform. The more similar you are, the easier for customers to jump ship when one aspect is messed up.

‍