When I ask entrepreneurs what the most valuable part of their business is, I usually hear a list of physical things: the building, the warehouse, the equipment, the vehicles, the goods on the shelves. That is understandable, you can touch it and it sits on the balance sheet. But look at the most valuable companies in the world and for most of them the main wealth is not in a warehouse. The value of a search engine is not in its servers, servers can be bought. The value is in algorithms, data, the habits of billions of users and the processes that make all of it work. I am convinced that a well-designed internet project can become the most valuable asset even for a very small company. The words "well-designed" are the key here, and more on them below.
A mill that grinds for everyone
In the Middle Ages a watermill was one of a village's most valuable assets. It was built once, slowly and expensively, but then for years it ground grain for anyone who brought a sack, with almost no additional cost. The river turned the wheel for free. An internet project works in a similar way, only its river is global. You write the code once, and ten people or a million can use the result. Serving the thousandth customer costs almost the same as serving the first. Economists call this zero marginal cost, and I call it leverage that a physical business simply does not have. To sell twice as much bread, a bakery has to buy twice as much flour and probably hire another baker. To serve twice as many customers, a service sometimes has to do nothing at all.
What this asset is actually made of
When people say "internet project", many picture a website. A website is the facade, the shop window. The real asset goes deeper and consists of several layers.
- Formalised processes. The way your company sells, counts, ships and serves, moved out of people's heads and into the rules of a system. This is the most valuable and most underrated layer: a process written in code does not go on holiday and does not forget.
- Data. The history of customers, orders, behaviour and mistakes. After a couple of years, data lets you see things a competitor without it will never see.
- Audience and trust. People who know you, read your materials and come back. This is a direct channel you do not have to pay for again every time.
- Code and architecture. The mechanism itself, which can grow, change and serve new scenarios without being rewritten from scratch.
Notice that none of these layers ages the way a machine tool does. After ten years a machine tool is scrap metal. After ten years data is a treasure.
A physical asset wears out from use. A well-built digital asset gets smarter from use.
When the asset turns into a burden
Now the honest part. Everything above is true only for a well-designed project. A badly designed project is not an asset but a liability disguised as one. It is that same mill with its wheel in the wrong river, cracked millstones, and a miller who is the only person who knows how to start it and who has wanted to quit for ages. I have seen systems that companies paid for over years, only to end up with software everyone is afraid to touch, because every change breaks three other places. Such code is called legacy, and it works like a debt with interest: every month you pay just to keep it from falling over.
Another trap is an asset on rented land. Companies that build their entire presence inside someone else's platform, a social network, a marketplace, a closed cloud builder, are like a farmer who ploughed the landlord's field. The harvest is fine until the owner changes the rules. A social media audience that can be cut off by a single algorithm change is not your asset, it is your rented stall at someone else's fair. You can and should use it, but the foundation has to stand on your own land: your own website, your own customer base, your own code.
How to build it so that it is an asset
Over years of practice I have arrived at a few simple rules. First: the project must belong to you completely, including the code, the data and the access credentials. It sounds trivial, yet I regularly meet companies whose website is registered to a former contractor. Second: the architecture should be simple and uniform, without a zoo of technologies that only one person understands. Third: processes are formalised first and automated second, not the other way round. Automated chaos is still chaos, only faster.
At Ingello we have taken this further. In Fractal the value lies not only in the code but in the description of the system itself: screens, data schema and scenarios are written in declarative languages, and the generator produces the code, database, API, admin panel and documentation from them. That means the asset is not tied to a particular technology or a particular programmer. The description can be reread, changed and generated again. The mill can be rebuilt for a new river without losing the blueprints.
What to do tomorrow
Take an inventory of your digital assets as seriously as you would a warehouse stocktake. Where is the code and who owns it legally? Where is customer data stored, and can you export it within an hour? Which processes are described and live in the system, and which exist only in people's heads? What share of your audience lives on your land and what share on rented land? The answers will show whether you have an asset or, so far, only expenses that you call a project out of habit.
