Table of contents
Introduction
What it’s like to be a tech startup founder? And what difficulties do these people face every day to bring their vision to life? We look at 2 stories of tech startup founders, how they built their products, and what technical challenges they faced during the first 5 years of running the company.
Story 1. The all-seeing Gnatta
FM Outsource and Gnatta are two companies that complement each other. Gnatta is a social media communication tool that offers effective management of multiple channels of communication with the customer, while FM focuses on retail customer service outsourcing.
Jack Barmby founded both startups back when he was in college, 6 years ago. He had a strong marketing background and clearly saw what he wanted to build, but he lacked technical skills to back up his vision. To get his company off the ground, he had to find the right talent, manage the team and the business, and guide product development – all at the same time.
Read how Jack’s companies faced and overcame their technical challenges in his own words below.
Challenge 1. As we grew bigger we spent more and more time on support
When I started the business, there were a lot of solutions that promised to successfully bring one user to multiple accounts but not the other way around. So the product I had in mind would give businesses an easy way to communicate with the same customer through any channel that the customer is comfortable with.
A conversation can start on Twitter and then continue on Facebook, and all that data will be still tied to a single client – helping the company’s customer support team always know what was discussed where and when.
The development team started off with just Twitter and Facebook, but as they moved to email, web chats, SMS, and all those other channels – even more exotic ones like Trustpilot—they started to realize that merging the context and conversations together was becoming increasingly difficult.
As our team began to deal with more channels, markets, and languages every year, the volatility of contact and data clarity became difficult to manage. We had to make sure that every channel was aware of every other channel and that all metadata was interconnected.
We made the decision to move operationally and technically from just the social solutions to a full suite and also brought clients on board who sometimes didn’t want to use the things that we were suggesting. So we reached a place where we were supporting all sorts of different systems at once.
We needed to smoothly operate within a plethora of systems and manage the volume in a smart way because each social or nonsocial channel has its own time niches when it becomes busy. From the customer's perspective, what we were trying to achieve was a conversational approach as opposed to a tech approach.
Challenge 2. We needed to merge and manage data from multiple platforms
Our main task was to harvest data from Facebook and Twitter in real time, but the APIs available on the market served data with a delay. We wanted to bring that down to real time. But as it turns out, that was one of the easy steps.
The difficult part was determining what architectural steps should be put in place so that we could extract data from the channel and then reference that back to the data in the CRM or whatever external system that the client had. We solved this challenge by poking into all of those external systems and merging them back together.
Challenge 3. We had to tailor our architecture to support third-party platforms
We discovered one of our biggest challenges pretty early on: We needed an uninterrupted flow of data collected in one place. So the team hooked up the APIs and set up harvesting solutions that would constantly accumulate data from whichever channels they were working on.
We run our service 24/7 and have to not only keep our own core systems stable and operational all the time but also manage different dependencies like Twitter and Facebook – which of course fall outside of our own ability to keep stable. To make this happen, we had to work out an architecture where the downtime of these platforms would not affect our operations.
Dealing with Facebook and Twitter downtime was tricky. We realized that every time they dropped, we would lose all of our harvested data. We had to run constant backups and decouple these services so that if Twitter’s API was down, we could continue getting messages without receiving errors.
Hooking up Facebook was straightforward. We also got a bit of a boost from Twitter. The service offers two ways of getting the required data: the data streaming API, which allows you to see all tweets tied to a single profile, and the Firehose, which emits every single tweet in every single language worldwide just as they are.
We started off by partnering with Gnip and using Firehose to query the data we needed. Our initial service was simple; we were just doing manual assignations of queries where an algorithm would manage data and direct it accordingly.
If everything seems under control, you're not going fast enough
When we started FM, it was a team of 2 people. Within 2 years, it grew to 32. And now we are a team of 320. Because of this rapid growth, we had to restructure the company. But this turned out to be more of a mistake-riddled path than a strategic choice.
There was a lot of trial and error involved in building the business, sure, but if I had to do it right now from scratch, the biggest thing I’d change is the positioning of the business.
It’s been really unfocused – especially during the first couple of years when we were taking on any work we could. At that point, we were not really worried what that work looked like. This gave the business a sort of jack-of-all-trades feeling – which can be hard to shake off. To get out of this broad box, we needed to make an enormous effort.
Story 2. A market of whiteboards and spreadsheets
Jason Knight is the founder of miiGroup, a startup that has developed miiFile, a real world portable digital identity and a workforce management tool that is designed to help small to medium businesses with HR and team management.
miiGroup was founded around MiningLink, the initial solution of the company. But over the years Jason and his team has built a small family of related products focused on streamlining different aspects of KYC & HR activities while helping individuals carry their mobile digital identities wherever they go.
Based on Jason’s estimates, companies in the mining industry have one administrator for every 60 employees. This means that most of his customers had to pay on average $83 per person per month in record keeping-related costs. For a small company, that is an astronomical expense.
Before I built MiningLink I’d gone around and polled close to a hundred businesses. Imagine my surprise when about 10% of all businesses I contacted still managed their team resources using white boards and pins!
Close to 80% of the companies that Jason polled were using Excel to manage resources, while another 10% of business owners were using only their memory or a filing cabinet.
In the brief interview below, you’ll learn how Jason tackled his company’s technical challenges to meet the needs of these small businesses.
Challenge 1. I underestimated the complexity of my solution
One of my main problems was that I had very limited experience in web development. I used to build corporate websites – nothing as complex as a full-blown online HR management system.
I rebuilt the system 5 times to actually get things right. I had to hire a few developers to help me, too, and it was around the 5th instance that we actually got the software to work properly. And then we took it to market with an MVP.
We convinced 19 companies to adopt our MVP version. This was a success because we proved that the MVP worked and had commercial value. After the validation, we went back to the drawing table and rebuilt the system based on what we knew was working well.
We went through 5 iterations, trying different ways of connecting people, documents, skills, and qualifications together in a portable identity. We ran on a LAMP stack (PHP/MySQL) and then added JavaScript to ensure a smoother, more fluent user experience. In the later builds, we moved towards a single-page architecture (SPA).
Our older versions seriously hampered the overall speed of the system. But now that we’ve moved to SPA, it feels like you are in an application rather than a website when you are using it. It’s very fast.
Challenge 2. I didn't know how to scale out from my niche
Where we started mining was an extremely narrow vertical. And as we talked to people about our product, we found that many other industries required the same tools. Thus iCompLii was born – a cross-industry compliance tool for workers. Once we built the software and got it on the market, we started doing some testing.
The biggest technical challenge for us was being able to store documentation suitable for all industries in one system. We had to adapt the software so it would be able to manage the data of any worker in any industry: banking, engineering, oil & gas, teaching, seafaring, mining, and more.
The way hard and soft skills are documented can be very different in various industries, and we had to make sure that every use case would be valid. This took a lot of technical expertise and 5 major iterations to do it right.
Challenge 3. I had to start from scratch
There was nothing out there that we could start with as a platform. We had to build from the ground up.
I think if I had to start from scratch again, I would probably follow the exact same process. Now that we’ve learnt how to store different types of documents and made data transferrable, starting again, we would build our architecture extremely differently.
Challenge 4. I made rookie mistakes developing my architecture
We went through several different iterations experimenting with how we store data – from using straight HTML (with every single action causing a page reload) to upgrading to a full single-page architecture (where all of the work happens in the background with AJAX and with the few pages that still have to be refreshed running on JavaScript).
Making good UX was also something we seriously lacked in our early trials because of how fast we needed to ship. We tried to get to the market as quickly as possible. Although the user experience was almost non-existent, the builds were rock-stable.
It requires a sink-or-swim mentality to succeed
As a startup, miiGroup was created around a single idea and a single product, which eventually developed into a series of software solutions tailored for different business needs and use cases.
But initially, MiningLink was an extremely narrow product only designed to help mining companies reduce overhead and other costs related to team management.
Thanks to Jason’s persistence and foresight, the solution managed to outgrow its small niche (of Australia-based mining companies with less than a hundred employees) to the company it is today, serving clients globally though a white labeled product and with even more opportunities to grow.
Here be dragons
Sure, the most common challenges tech startups face revolve more around the business side of things – finding the right market fit, managing the runway, and building a team with the right expertise and skills. Nevertheless, there is certainly no shortage of technical issues you’ll encounter during your journey.
Integration difficulties, forced downtime, complex data structures, software scaling mistakes, stuff just outright not working – all this can seriously impact your business operations and impede your company’s growth.
We hope that the experiences of Jack and Jason – both of whom built something awesome only after acquiring their technical expertise through a tedious and painful process of trial and error – will inspire you to always press on.
Energy and persistence conquer all things.
