Building products: how modern IT products are born

1. “People are no longer born, they are grown”

Well then, since you are still here, let’s continue. “And I will show you how deep the rabbit hole goes” © 🐇

Let me tell you how the product development process works—we will walk step by step from the very top global level down to the very bottom: writing code. I think a few interesting discoveries are waiting for you…

Modern IT products are no longer “written”; they are built. They are assembled piece by piece from libraries, frameworks, third-party programs and products—or they simply use remote paid or free internet services 🧩.

A modern product is an entire zoo of technologies, services, solutions, and processes. Some of the work is done by people, some is automated, and the remaining 90% is generally handled by cloud services in data centers ☁️. The world is not what it used to be.

But the first thing you will notice is constant change. You no longer write programs; you make changes to them.

2. Constant change

You will come to work and join a team of 20 people that has been working on the product for 5 years. Users currently have access to its 7th version. And your task will be to make changes to this product. Small ones, so as not to scare away the current active users.

And it will not be easy, because the product is already running. It has clients, and they pay money 💰. So you cannot break anything. Making changes to an already working product is several times harder than building a new one. There are special standards, migration protocols, and utilities for this. This immediately brings to mind a joke:

Two old friends meet: one became a mechanic, the other a surgeon... Each has their own life, worries, joys... They tell each other about everything, and then the conversation turns to salaries. The auto mechanic says: "Well, I make 30k a month and I’m very happy with it—how about you?" The cardiac surgeon says: "Well, I make about 100k per operation..." The mechanic gets interested: "Strange, why such a big difference? Seems like we do the same thing—replace parts." And the surgeon says: "Well, let’s go to your car—start it up..." The mechanic starts the car, the surgeon opens the hood and says to the mechanic: "See, the engine is running? Replace it!" 😂

Even if a miracle happened and your team spent a whole year building the product from scratch and only then released it, do you know what will happen next? If your product becomes successful, the product owner will want to keep developing it. Ship a new version, add some functionality. Or at least run a few experiments. And do you know what will follow? Changes 🙈

3. Product value

From the perspective of modern development, the only code that has value is code that has already been released, and the only feature that has value is the one users actually use. If you wrote code, it is stored somewhere, it runs, but people do not use it—its value is close to zero. That is why all code should reach production as early as possible 🚀

Your code must go through stages like these:

• ✔️ You wrote it and made sure it works.
• 🔍 Your team lead reviewed it and merged it into the main branch in Git.
• 🧪 Tests during the build showed that you did not break anything important.
• 🧩 Integration tests showed that the product works as intended.
• 🛡️ A QA engineer checked this code and gave the green light for release.
• 📦 Then you need to build a new version of the product and release it to the server.
• 🐳 The new version of the product needs to be packaged into Docker images and released.
• 🗄️ You may need to run migration scripts and make changes to the database and/or other third-party solutions.
• 📊 Then you need to collect logs on the server to make sure everything works as intended.
• ⏪ In case of an emergency, if you broke something, you need to roll the build back, restore the previous state of the database, and not lose the actions users performed while working with the unstable version of the product.

In most companies, these tasks are solved now: new processes have been established, dedicated specialists have been hired, and special security protocols and quality control standards have been introduced. The larger the company, the less time passes from writing code to the moment it reaches production and turns into value—starting to benefit people.

In most companies, code goes through this path in two weeks. However, there are companies that do releases every week or even every day. Some special outliers—several times a day.

Written code is worth nothing. Only code running in production creates value.