04 Apr How we helped a Silicon Valley startup reach its KPIs before the deadline

This will be a case study perhaps a bit different than the ones you’re used to reading. Instead of having a company share its successes, this time our success will be told from the perspective of someone who was there through the whole process. Me.

I am a senior developer, working at BDIT for years, and this is a story of how I was out-staffed to help a San Francisco-based start-up company fix issues and reach its KPIs before the deadline.

An overview:

Who did we help?

We can’t really mention any names, however, we wanted to at least share the industry: a start-up company working in the area of office management and work process automation.

I worked with them previously, a couple of years ago, on an iOS app that is great for hybrid and remote workers, while at the same time offering many important options for people who work from the office every day. It offered all-in-one solutions for both visitor and employee registration, coordinated work schedules, desk booking, allocating conference rooms, delivery handling, invitations management, etc.

This startup also helped ease work and visitations during the pandemic, as it accounted for vaccine certifications, workplace safety, health compliance protocols, and other useful innovations within the mobile app.

What was my task and how did I approach it?

Getting Familiar with the Code

When they gave BDIT a call and asked if we had someone who is willing to jump in quickly and go through all the code, I was a clear choice. As someone who already worked on the app in question, it didn’t take long for me to step in and start combing through the code.

One of the bigger challenges was figuring out why some bugs were showing up sometimes, and not the other times. I had to carefully go through every line of code that was fairly large and of a high level of complexity, including some of the client’s original tech designs. I knew that only once I understood everything, I could create proper tests.

“I knew that only once I understood everything,
I could create proper tests.”

Trying out a Third-party App

After getting started, I was tasked with testing a third-party app to see if it could help with testing. It took about 3 weeks or so before the company and I agreed that it won’t really work out between them and the third-party app.

It’s easy to take a look at this and think of it as wasted time, however – I don’t see it like that. First of all, we were now aware of the limitations of such an app. And second, we came to the conclusion that even though using a third-party app will help when you’re on a tight schedule, creating your own solution will always allow for more flexibility and fine-tuning to what you need.

Ad Hoc situations are a normal thing in the life of a software engineer, so I wasn’t discouraged and was sure we will be able to reach our targets on time.

What did our coworking look like?

I’d like to mention that, even though I already worked with this company, the process of adjustment to a different team works pretty similarly every time.

The most important thing is to agree on the time when you’ll overlap with the team you’re working with. It’s quite a difference between us and San Francisco, so we established some later hours for me and early hours for them so that we have time to go over everything in a meeting.

Yes, e-mails and messages can be effective–but calls and meetings add speed and remove space for miscommunication.

“The Time difference has this great benefit: getting things done while the team is sleeping, and getting tasks/tickets prepared for me as I clock in in the morning. This helped us move fast, and gave the impression of working on the project 24/7.”

The result we achieved:

Why did this company even need an outstaffed developer?

The answer to that is simple: time crunch and a need for someone experienced and quick to adjust.

The team I worked with was made up of wonderful, smart, senior developers. However, the project deadline was short and they were short on people who could jump right in.

That’s where we, BDIT, and I came into the picture.
I already knew the app, what the company was all about, and have years of experience.
They, in return, knew I was fast, quick to adjust, reliable, and can solve the issues they needed solving.

Who is the author?

Dušan is a senior developer with a lot of years in the industry under his belt. He has been a part of BDIT for many years and worked on various projects with a number of clients. He is someone the BDIT team is happy to learn from, and someone we know we can count on to bring his best game whenever he’s needed.

A happy senior developer, a happy BDIT.