I’m now almost two months into my software engineering summer internship at FreeAgent. When I was 18, I chose to delay the start of my university course for 18 months to have a go at building a ‘Software as a Service’ (or ‘SaaS’) startup with two others.

Our software, ‘trackio’, was a bring-your-own data platform that allowed sales teams to collect, connect and reconcile their disjointed data sources. It was essentially a business intelligence tool. Think of fancy dashboards and shiny reports you can use to make decisions.

Ultimately, the startup was closed for a multitude of reasons; the pandemic, for one, didn’t help. We did have some success, however. Getting trackio into a number of Vodafone franchise stores and becoming an AWS activate startup were among the highlights. 

Today I’m here to talk about some of the engineering lessons we learned at trackio as a result of our first real attempt at software engineering beyond WordPress and OpenCart.

The feature factory

A few months into the project as the business grew and the codebase became more complex, we started to receive lots of feature requests. We would add whatever our customers requested without giving it much thought, simply to keep them happy. In doing so, we unwittingly became what is known as a ‘feature factory’. 

The product development expert, John Cutler, has written some excellent resources that can help you identify whether you’re working in a feature factory. He says that one of the biggest red flags is when you are solving real problems for real users but your product or service doesn’t translate well beyond that niche use case. This became apparent at trackio when we started pitching to venture capitalists who could see that what we’d built for Vodafone franchises worked well for their sales teams but wouldn’t provide much utility in a different industry.

The main driver of our feature factory was chasing upfront revenue. To close deals we incurred technical debt by trying to implement as many features as we could, often having to pay for it in the future. Another contributing factor was a lack of retrospectives to determine how well the shipped features were received and whether they made sense for the product roadmap and overall vision. 

During my internship here at FreeAgent, I’ve enjoyed our weekly retrospectives. As a team, we’re constantly discussing the work we’ve been doing and if the impact was what we expected. There’s no shame in admitting we anticipated something incorrectly.

“Does this feel right?”

I often ask myself “does this feel right?” when I’m working on something. When my trackio teammates and I first started out we were novices at best, and we only really had Google and books to guide us. It’s great being in an internship and having a team of more experienced people to bounce ideas off and learn from. 

For me, instinctively asking yourself “does this feel right?” is one of the best indicators that you are improving as a developer. It’s the seed that often grows new knowledge. It was that very question that made us start using git for version control instead of Dropbox at trackio.

Don’t make me think

Early on in our product development, we didn’t think enough about who our users were or how they were going to use our product. With the help of user stories, we were able to start diving deep into features from the perspective of the people who would be using them.

With this, we learned our database design wasn’t going to be able to handle users editing key performance indicators (KPIs) while the figures were being calculated. We needed a first-in-first-out queue to manage concurrency and consistency.

We also learned that most of our data accuracy problems came from notification fatigue because users didn’t have time to read information modals, so we needed a user experience that didn’t require explanation.

Users don’t want to think when they’re using your software. It’s your task to build them something where they can accomplish their intended tasks as easily and directly as possible. Shoutout the author of Don’t Make Me Think and UX specialist Steve Krug. 

Iterate quickly and validate often

When we first started exploring a mobile version of our platform, we were already spread thin. The idea of standing up two native iOS and Android mobile apps using completely different languages was a daunting and quite frankly impossible job for two people. Given our hands were full with a web platform, point of sale system, and everything else startup related.

Instead, we opted for WebView containers. WebView is a way to use web technologies in a native-like app experience. Therefore, we could use the already existing mobile version of our web app and deliver it as if it was a native mobile app. WebView has its share of drawbacks which makes it far from ideal in the long term. In particular, you’ll often find yourself re-inventing the wheel and working on things that come out of the box with native app development.

But what WebView is great for is rapid development and quick iteration. In less than two weeks we had both an iOS and Android app released that was being used and gathering feedback. Going mobile gave us engagement like never before and made us completely rethink our product direction.

When you’re building a startup the faster you get things into the hands of users the better. The product will go through many iterations and nothing is set in stone. By the time we started planning a migration to native, we now knew what our mobile apps needed to do and we were improving on something already validated by our users. Without WebView we either wouldn’t have released anything. Or, it would have taken months to release native apps that were inevitably going to change based off user feedback.

Every SaaS needs its support

Support is the backbone that pushes a SaaS business forward. Once you find product market fit and have paying customers, the last thing you want is to lose those hard-earned customers to churn. I learned that it’s vital to listen to what your customers are saying and to fix the problems they’re facing as quickly as possible. But when customers have feature requests, remember the perils of the feature factory and don’t feel the need to implement everything a customer wants just to please them. When you’re an engineer, you know your product better than anyone else, giving you foresight that others might lack.

Unfortunately, support was something of an afterthought for us at trackio. It took up a lot of our precious time and distracted us from getting back to building a great product, purely because we didn’t have the systems in place to receive and manage customer issues.

My internship at FreeAgent is with the support engineering (SE) team. At trackio, SE was something that we didn’t know existed, but we definitely needed it! With a customer support ticketing software like Zendesk you can handle the customer-facing side of support efficiently, while escalating engineering problems to a support engineer. It’s what keeps the development of the product moving, while improving the experience for current users.

There’s no glamour in burnout

Thinking back to why I started programming, I wanted to build cool things. Programming felt like the superpower that enabled creation. It’s fun working on personal projects and learning new technologies. When you’re in a startup, you inevitably have a lot of roles and responsibilities at the beginning, including some that you don’t necessarily enjoy. Until you can scale a team, it’s just you and (if you have any) your co-founders.

If you were to ask me what the biggest startup killer is, ‘founder burnout’ is what comes to mind. Nothing will destroy your dreams faster and if it goes unchecked it will likely be the thing that makes you finally throw in the towel.

Engineering is a mentally intensive role. Prioritising exercise and diet can go a long way to help ensure you’re mentally ready to face the challenges that lie ahead. The times we were crushing our development at trackio wasn’t during the 20-hour work days but when we spent the greatest amount of time planning our backlog, product roadmap and constantly evaluating our in-progress work. Startups are marathons and the longer you stay in the race the greater your odds of survival.

Final thoughts

Closing a company in the tech world is almost like a right of passage. Most don’t make it and of those that do, it’s usually not the founder’s first attempt. 

Once it’s over, you might try to blame external circumstances, timing, or bad luck. But it’s a bit like failing your driving test. At the time, you might think that the world is against you. However, once you finally get back onto the road you realise you needed that first failure under your belt to guide you to later success.

Engineering is the art of problem-solving, and how you get to your final destination is your choice. Enjoy the ride and all the twists and turns it provides.