During my whole career, I underestimated the importance of logs. I was always aware that it is important to log key events to help track and solve the issues, but I never paid enough attention. In the mobile world, we tend to not log much. We rather use analytics to track the key metrics and see how successful is the feature. Additionally, we use tools like Crashlytics to get some crashes or get more insight into an existing issue.

Although it might be enough on the frontend app, it is definitely not enough for the server-side. Especially in the startup world, where we need to iterate very quickly, we need to track what is going on in the app. This could help us make the right decisions at the right moment without wasting time on the hopeless debugging and without guessing what could have happened. I think that at the beginning of the journey with the product it is best to hook up a logging tool and log as much as possible. In node js, we can log every call with some details about it (being careful about privacy of course). Very likely in the first months we won’t have a lot of traffic, so we can push a lot of logs and monitor it to see what really gives value. Active monitoring of the logs is the key here. We need to look at what is going on and iterate on the way we log, to make the most sense of it. Since many tools and platforms have their own set of logs, we can think about ways to monitor all the important parts to react quickly when the reaction is necessary.

As I said at the beginning, in my own projects, based on my mobile development experience I underestimated the importance of the proper logs. When I think about my startup journey, I am sure I would be much more confident about the quality of the provided product if I delivered it with the right amount of logs that I would monitor on the regular basis. I am sure that time invested into logs is way more important than the time invested into very detailed unit tests. Unit testing is super important, I don’t want to underestimate the value of it, but in the startup environment, that is developed over the weekend and after-hours we need to use our limited resources very wisely and do not spend them on things that have less impact on the actual product. I love the confidence when I spend the whole day in TDD mode and I end up with high coverage, but not all the things are easy to unit test without the proper abstraction. Adding the abstraction and separating the domain and hide all side-effect interactions into the implementation details is very important, but sometimes in the startup mode, we do not have the luxury of proper planning and driving it in the DDD way. So we make shortcuts, I guess everybody does. I believe it is ok, but we need to control the outcome. If we cannot rely on the proper test suite, we need to have the logging capabilities that help us deal with the problem.

Of course, having great logs in a big ball of mud won’t help us to make our software good. So composing from the small pieces, isolating experiments that might be thrown away, and logging as much as we can is something I would recommend for every early-stage startup. It would be hard to say how those things would work in a large team that develops a mature product, but based on my experience in the mobile world, it would definitely help.

In summary, I believe it is always a great idea to log. At the beginning of the project to log as much as possible and then by active monitoring to reduce the logs to not flood us with useless information and to be able to group logs into buckets and deal with them effectively when the project grows.