Actionable Tips to Avoid Software Outsourcing Disaster

Over my professional experience I have been a CTO for several startups. I've worked on both small apps for the local market, and big international systems running on multiple platforms. I used to make a lot of IT/management mistakes, but I gradually found a way to overcome those problems and, eventually, my team started to build better software.

In this article I will explore some of the most common problems I came across and suggest practical solutions to solve them. I will also assume that you have no advanced IT/Tech knowledge.

Typical problems startups usually have with their software?

So what are the most typical problems in startup life in terms of the software?

Frequent changes break your app

If you are a startup, you probably know that changes are critical for the success of every startup. Without soft/business model adjustments, your product is based only on your (and your team’s) vision, which usually doesn’t match actual market needs.

So, that’s OK, you have to adapt. But changes usually break your app. For example, adding a simple field in registration form could destroy accounts removal or entire order logic - which is a serious problem.

Was this new feature deployed?

If your team member tells you he has just finished an awesome new feature, it usually doesn’t mean that the app will have the feature in 10 minutes when you have a presentation for your potential clients (believe me - I’ve been there).

Your users face the problems in their homes

Of course they do, and the problem is that you are not there with them to help and at least identify the bug.

How to avoid them

We know the issues so now let’s see how to prevent them.

Automated tests

First and most intuitive cure for breaking software problem is to hire a tester. Unfortunately, startup has to change fast and often, which means one update per day is not enough and our fellow tester won’t be able to click through all functionalities multiple times per day.

This problem could be easily solved by implementing Automated Tests in your application. It means that a script will launch your app, go through all its features and check if they work as expected. Usually entire process of building thoroughly tested software is called Test Driven Development and it means that developers first create tests, those tests fails, then they build entire logic, and finally tests pass.

What you have to remember:

  • automated tests are a must for a startup, not an option
  • if your team finds a bug – write a test for this bug, and then fix it (this way the same issues will not persist)
  • don’t go nuts - more tests means better quality but also longer delivery time. My approach is to make test for each user story, but not necessarily for each programming function.

Continuous integration (CI)

OK, your app has automated tests but what if someone doesn’t run them before an update - your app could also break. So, the next part is to set up a bug firewall.

Continuous integration is an automated testing process for your application. After each update of your production code, a continous integration server:

  • sets up a virtual server,
  • runs the tests,
  • stops the process if tests fails,
  • deploys the app on your production environment,
  • rolls back the changes if something goes wrong.

To be more specific, Continuous Integration is only two first points. The entire process is called Continuous Delivery.

Nowadays, CI servers are super easy to set up and it takes literally 15 minutes to get Continuous Delivery working. My favourite CI’s are codeship.io and travis-ci.org (it can also run mobile apps).

DoD

DoD stands for Definition of Done - those are sets of rules in your organization which should be meet to consider a task "done".

It is super important when you are working with remote team of developers. Having Definition of Done eliminates situations like:

  • Situation 1
    • YOU: the feature you told me you finished is not there!
    • DEVELOPER: Of course it's not working, I haven’t deployed it on production.
  • Situation 2
    • YOU: Guys! (to remote company) What you provided is not working!
    • REMOTE COMPANY: Of course! Because we are still stabilizing the software.
  • Situation 3
    • YOU: Man (to a developer), why is there no “accept terms and conditions” checkbox in the registration form?
    • DEVELOPER: Of course there isn’t one, nobody told me that it should be there!

To see an DoD example lets read my other article about it.

App monitoring

A fresh startup will definitely have some bugs even if it has CI. Your users could forgive you errors in the beta stage, but only if those errors are fixed fast.

To fix something fast, you have to identify the problems instantaneously. Tools for app monitoring may come in handy. My favourites include:

  • airbrake.io (or its free counterpart errbit)
  • new relic rpm (it also measures app performance)
  • kadira.io (performance measuring for meteorjs apps)

Don’t forget to set up a notification system. When something happen for one of your users, you and your team will receive a notification with the details, so you can even write a message to that particular user after the issue is fixed.