BUILDING A DIGITAL PRODUCT

8 tech aspects to take care from the beginning.

Well begun is half done.

Most of the time we have to deliver fast to get feedback from the market as soon as possible, and that’s true.

But the life of a product doesn’t depend just on the market response, and when we talk about digital products, the most important aspect remains the technology one.

I worked for different companies where I built different digital products.

From iGenius where I was first a full stack developer and then the front end leader of crystal.ai, to finleap where I’m working as Principal Engineer to build new startups and services for our fintech ecosystem.

During my experience, I witnessed how much is important to start thinking from the beginning about some aspects that will reduce a lot your future technical debt.

So, for those reasons, I would like to tell you what are the most important aspects I suggest to take care of at the beginning of any digital product, based on my past working experiences.

1) Invest in the right people

That’s not a technical aspect, I know, but trust me, is the most important one. What you build is built from people, and having the right team can change everything.

Hire smart people, not just good developers.

Hire people that are open-minded, able to step outside of the comfort zone, and ask questions.

Otherwise, they will never learn something new.

In my opinion, a company should attract talents, and one of the best ways to do that is already having talents.

The question is: How can I hire smart people? Well, Take the ticket and get in line.

Meanwhile, this is a very interesting article about “Hire smart people”.

2) Find the right balance to make the system work and make the system easy to change

There is no worse thing than a system that works but cannot be changed.

You are building digital products for the future and not just for the present.

If you are not able to change, how do you can scale your business?

Robert C. Martin explains very well this concept in “Clear Architecture” book:

“If you give me a program that works perfectly but is impossible to change, then it won’t work when the requirements change, and I won’t be able to make it work. Therefore the program will become useless. If you give me a program that does not work but is easy to change, then I make it work, and keep it working as requirements change. Therefore the program will remain continually useful.” - Robert C. Martin, Clean Architecture

It is important that who is responsible to set the business goals understands how much is important to take the right software architecture decision from the beginning and it is your responsibility to make it happen.

A good example of clean architecture in Node.js:

3) Testing

The majority of the people know how much tests are important, but they still have very few tests or none at all.

During the first building phase of a product, most of the time should be used to build things, I agree.

Everybody knows that the first thing after the first release is refactoring, right? So, ask yourself this question:

How can I ensure that after the refactoring the things will not break?

My suggestion is to define a set of rules on what should be tested in the beginnings. For example, on the server-side should be mandatory to have E2E tests for the API and unit testing for the business logic.

For the client-side, I prefer to have more visual testing instead and write fewer unit tests.

4) Versioning and branching model

The simplest things are the ones that sometimes can create a lot of problems and the branching model can be one of those.

Changing the branching model during development is always a bad thing to do because it forces you to take care of another aspect during a different process.

Define with the team the best branching workflow to adapt before starting to code. There are good articles that explain different branching workflows, like the following I found.

Let’s take a look if you need it.

5) CI/CD Pipelines

Have the right workflow to continuos integrate and deploy your source code helps teams to be more productive which is very important at the beginning.

This aspect is strictly correlated to the previous ones because having a very good branching model makes easier the investment in CI/CD workflows and having tests increase a lot the quality of your workflows.

If you are interested in, here are interesting articles about it:

6) Infrastructure as code

Let’s define for who doesn’t know what IaC is:

Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools

Source: Wikipedia

One of the most time-consuming activities is building, growth and maintain different environments.

Developer productivity drastically increases with the use of IaC because automating the infrastructure deployment process allows engineers to spend less time performing manual work, and more time executing higher-value tasks.

For this point, I prefer to just share one very good article, check this out:

7) Document for you and for others

Another time-consuming activity if we take it as a single block activity to do.

But if you start writing documentation from the beginning, it will pay for the long run.

If you are not able to share with your colleagues the information needed to work on what you did before, how many times do you think your colleague will waste to know how to do things?

You can have the best, functional product, but no one will use it if they don’t know how to. Documentation is the foundation for good Developer Experience.

- Keshav Vasudevan at Resource

Resources where you can take inspirations:

8) Monitoring and Logging

Debugging, monitoring for errors, and troubleshooting are essential parts of software development, both during and after release.

Perfect, you are ready to go production.

After 10 minutes the customer support text to you: “Hey, customers can’t log in, what’s the problem?”.

How do you fix the bug in the fastest way if you can’t see where the issue is?

Today, there is a lot of complexity in our software architecture that most of the time we have more than one service to monitor and log.

My advice is to centralize your logs with applications like graylog or logz.io.

Conclusion

These aspects are so obvious that sometimes we forget how much are important and they can be very dangerous during the first period of a tech venture.

Always remember:

“So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.” - Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

And you, what do you think is important to take care of at the beginning of a new digital product?

Thanks.