When I joined my new job some months ago, we had nothing, just 80% of an MVP was ready. At the very beginning, we face some insane deadlines, and lots of time found ourselves figuring out what we needed out by the end of that day. We were cutting corners, so absolutely not time for tests unless they were the hard core of the system we were building.

So how do you transition from successful MVP to a business as usual?

We managed to create an MVP with roughly around 30% of code covered by unit tests. Bear in mind we were cutting corners so the percentage is not that bad, especially if you realise that 30% is not randomly distributed across the code, but it’s the most important code we have. The process for creating tests was really hard, as we need to have test doubles for absolutely everything accessing DB. I recently came up with a mechanism to use, instead, a real DB instead of having to mock everything, so we can now avoid the hassle of writing the mocks/stubs, instead, we just created the data we need in DB, and run against it. I think this will mean in time we will be able to write tests much faster and in turn to increase a lot our code coverage. I’m asking my team to use more and more this mechanism in the future.

Ok, tests. What else?

As a team, we have a strong commitment about resilience. We want to be able to undo any critical operation we have. By now we are using complex mechanism to do that, but we think in the near future that will drive us to event driven (event sourcing, CQRS, event logging, you name it), for now, it’s just a thought in my mind, but we are looking into the best way to implement it (Kafka, Google Pub/Sub, etc.)

Scaling up is not only about tech, the business has to scale up too.

We start having users, and the growth we had so far has incredibly exceed the expectations. Growing pains happen, they are good problems to have, but they are still problems. The only thing you can do with this is to prioritise. Obviously it would depend on the nature of the growing pains you are experiencing, but finding a good balance between how you communicate unexpected situations to the users and how much time you spend making more automatic for your operation team can be the success key.

Avoid the urgent preventing you from making the important.

When you are on the peak it’s really easy to forget about thinking with a broader mind. You need to step back and figure out in a longer timeframe what are likely to be your challenge, order them by impact and urgency, and focus first on those where impact and urgency is high.