Your software has an opinion about your business

The model before the software

Every management software embeds a vision of how a business should work. It defines what a customer is, which stages an order goes through, how a warehouse should be organised, what deserves to be measured. Whoever adopts it receives these definitions along with the product, often without realising it, because they present themselves as technical choices (fields to fill in, workflows to follow, reports to consult) when in reality they are choices of meaning.

The point is simple and uncomfortable: most commercial software is designed to model the business, when good software should model itself on the business. The direction of the deformation is opposite, and with it the purpose of the entire operation is reversed. In the first case the business becomes a particular instance of a generic model; in the second the software becomes the formalisation of a specific model that already existed within the business, even if only implicitly.

A CRM that classifies every contact as lead, prospect or customer has already decided that the commercial relationship follows a linear path. A warehouse system that reasons by average stock has already established that all references follow the same rotation logic. The consequences of these decisions accumulate slowly. The business begins to adapt to the software, to work around it, to create parallel spreadsheets to capture what the system cannot accommodate, to use notes fields as makeshift containers for information that finds no proper home. A year later, the business has rearranged itself around the management system, and what was born as a tool has become the reference.

The more sophisticated systems promise broad flexibility: custom fields, configurable workflows, automations you can build at will. In practice the picture is less generous. Seriously configuring an enterprise management system has a cost that operates on two different levels. The first is economic and immediate: it almost always requires external integrators, produces fragile assemblies that break with software updates, and that few people can maintain without calling back those who built them. The second is about design and the longer term, less visible but more insidious: each configuration is a layering of customisations inside an architecture that was not designed for that business, and this layering accumulates over time as debt. Changing course becomes more expensive with every intervention, and the business finds itself tied not to the software but to the collection of adjustments that made it vaguely compatible with its own operations. Even after significant investment, the level of precision achieved almost always remains below what the business would need to express. Surface flexibility rests on a deep rigidity that reasserts itself every time something important changes in the way work gets done.

The cost of this deformation is entirely in attention. Every day, a share of time and focus is absorbed by bridging the gap between the software’s model and operational reality. A small but constant share, subtracted from everything else.

For decades this cost was part of the price of having a system, and it was accepted as such. In recent years it has become negotiable: alternatives are opening up that until recently required resources beyond most businesses’ reach, and with them a new field of choices and risks that did not arise before.

Software as an act of understanding

The preliminary question before any software choice is to understand your own business with enough precision to distinguish where a generic model is adequate and where it is producing silent damage. It is a step that is almost always skipped, because it seems obvious to those who manage that business every day, and almost always it is not.

Building an internal operating system starts here, from mapping what actually exists. How processes work in daily practice, not how they should work. Which information serves decisions, which gets produced and never looked at, where the flow gets stuck. The software comes later, as the formalisation of knowledge that previously lived distributed among people, habits, spreadsheets, and which for that very reason was fragile.

The first result of this exercise is usually less gratifying than those who undertake it expect: most of the processes that a business feels are its own are in fact standard, reducible to patterns shared with a thousand other companies of the same type. The true specificity, the kind that justifies particular attention and, possibly, a system built around it, is almost always narrower than internal perception suggests. Recognising it precisely is the real value of the work of understanding: it separates what is worth building from what simply needs to be chosen well.

The current narrative about artificial intelligence applied to development tends to skip this step. It implies that the bottleneck is the ability to build, when in reality the difficulty lies in knowing what to model. A business knows how to do its own work, but knowing how to describe it with the precision needed to turn it into a system is a different exercise: it means making explicit structures that work precisely because nobody has ever had to formalise them.

The value lies right here. Formalising an operational flow into software forces decisions that previously remained implicit or were deferred: what makes a customer good, when a product needs reordering, which information must reach whom. These are decisions the business already makes every day, by intuition or by habit. The process of building brings them to the surface, where they become objects of discussion instead of remaining invisible assumptions.

It happened to me while building the system I use to read my customers. It seemed trivial: a customer silent for more than sixty days is inactive, go and reactivate them. It is the primitive you find in any CRM and in any customer lifecycle course. When I tried to translate it into code, it did not hold. Sixty days for a customer who orders every two weeks is an outright crisis; for one who orders every ninety it is half their normal rhythm. The “active / inactive” category was not describing the customer, it was describing a universal threshold applied to customers living different rhythms. To get out of it I had to dismantle the idea that “active” was an attribute of the customer and rebuild it as a relation between the customer and their own historical rhythm. That work later became a small framework I described in another piece; here only the episode matters. What I saw, in formalising it, was a category I had taken for granted for years lose consistency the moment I had to write it out explicitly.

Two symmetrical traps

The trap of generic software is well known and well described: it imposes a model that does not correspond to the business’s reality, and over time the business deforms to adapt. There is a less discussed variant of this trap, concerning heavily configured software. A well-done configuration can be stable and functional for years; but as customisations layer up, the business begins to inherit burdens proportional to the level of intervention (perpetual maintenance, dependency on whoever built the configurations, fragility with respect to updates of the underlying software) without obtaining the main benefit of those who truly build, which is a model that reflects how work actually gets done. Beyond a certain threshold of customisation, you find yourself in a hybrid position that carries the costs of building and the constraints of adopting.

Custom software has an opposite trap, less discussed and equally concrete. When the constraint of the generic model disappears, the perimeter of what could be built becomes open. Every process could be captured with more precision, every interface could fit the real flow more closely. The pursuit of the perfect system can become permanent: the software never gets released, or gets released and is immediately perceived as insufficient.

There is an important difference from the startup logic, where you release a minimum product and adjust on the fly. An internal operating system must work well from first use, because people work on it and errors fall on daily operations. The logic of early release operates differently here: instead of releasing an incomplete product to everyone, you release a solid product to a few. The initial perimeter must be kept tight, a single process or a limited group of users, enough to contain the inevitable imperfections without letting them affect the entire operation. From that perimeter you expand, refine, correct what the first model had oversimplified. The principle that you only learn from use remains valid; what changes is how you organise the risk.

What is changing

For decades the choice was lopsided. Commercial software was quick to adopt and cheap, but generic. Custom development was precise, but required budgets and timelines most businesses could not justify. The compromise with the generic option was almost always forced. Over the past fifteen years this compromise has taken a specific form: SaaS, software sold as a subscription service, has become the dominant way businesses purchase digital functionality. The promise was reasonable: nothing to install, continuous updates, predictable costs. The flip side, less discussed, is that SaaS is the purest form of software-that-imposes-a-model: to remain economical for the vendor, it must be generic enough to serve thousands of clients with the same logic.

Artificial intelligence tools are altering this asymmetry, and they do so in ways that the current narrative captures only in part. The most visible level is the speed of construction: what required weeks can take days, and a person with operational skills can initiate what previously required a dedicated team.

The same tools help with a job that comes before building, the work of business formalisation: structuring observations and interviews, organising scattered notes, surfacing contradictions between how people say they work and how they actually work. Tacit knowledge remains where it has always been, inside the people who operate and in their habits, and that is where it must be extracted from. AI does not guarantee it will emerge on its own, and it does not replace the craft of those who know how to interrogate their own business methodically: it increases the productivity of an exercise that remains difficult, and which for all that still requires attention, time, and discipline. For an entrepreneur who knows their trade but has never had the time or the tools to describe it systematically, the most significant possibility is precisely this: making practicable a work of articulation that previously required months and a dedicated person.

Meanwhile, a market pressure is materialising that converges in the same direction. Businesses that have accumulated dozens of SaaS subscriptions over the years are beginning to wonder whether it is worth paying recurrently for functionality that can now be built internally at different costs and with greater control. The phenomenon is not just about spending: it is also about where the value sits. When a function is truly specific, keeping it inside a system that owns it becomes more sensible than renting it from a vendor who is selling it to hundreds of other companies with the same interface.

There is a further consequence, which changes the very nature of the process: the cost of getting it wrong has dropped radically. When building required months and large budgets, every modelling error was expensive to correct, and this incentivised paralysis, the attempt to predict everything before starting. Today you can try, verify whether the model holds in practice, throw away what does not work and recalibrate. The costs of iteration (which are not only economic, but also of time, attention, and complexity accumulating in the system) have fallen to the point where an approach that was once a luxury becomes practicable: letting the software evolve with the business, accepting that the initial snapshot will always be incomplete and that continuous corrections are part of how the system works. This iteration does not require writing code yourself; it requires awareness of what needs to change and the ability, directly or through a collaborator, to translate that change into the system. This is an important difference from the past, when every iteration was a project in its own right.

When the economic constraint stops discouraging rewrites, discipline takes its place: the discipline of choosing what is worth questioning. Judgement shifts from “can we afford it” to “do we actually need it”, and here knowledge of the business becomes decisive again.

The new constraint

The question a business asks itself when facing software has changed. For decades it was a question of availability: which solution on the market comes closest to what we need? Today, at least for the processes that make the difference, it has become a different question: do we understand how we actually work well enough to build something that resembles us?

The constraint has shifted from the availability of tools to the clarity with which an entrepreneur can describe their own trade. A clarity that until yesterday remained private, deposited in the experience of those who built the business and in the habits of those who work inside it, and which today can become the concrete foundation of the system the business works with. The shift is quiet but substantial: the competitive advantage of specificity, until recently hard to defend because hard to formalise, has found a channel in which it can consolidate.

A more surgical choice

The new constraint opens the possibility of a more surgical choice. Most of a business runs on processes that a thousand other companies share, and that standard tools handle adequately. The specificity lies in the subset, often small and identifiable only from the inside, where the way work gets done truly constitutes a competitive advantage. Building around that subset, and only around it, keeps construction and subsequent maintenance costs sustainable, and turns the promise of software-that-resembles-us into an achievable goal rather than a receding horizon.

Building, in this sense, does not mean writing every component from scratch. It means starting from the existing ecosystem (libraries, APIs, services, established patterns) without excluding anything a priori, and using it as raw material in the service of a model that is your own. The quality of what comes out depends entirely on the direction in which choices are made: if the starting point is the business model and the tools come after, the composition organises itself around a coherent logic and the final object shapes itself to the way the business works; if the starting point is the available tools, the composition ends up imposing its own geometry on the business, and you are back to the original deformation with a higher level of sophistication. Modern software is almost always composition; what changes is who is driving the assembly.

How the relationship with the builder changes

For most entrepreneurs today, “building” still means entrusting someone who builds. The builder, the developer, the technical consultant remain necessary figures, and the quality of the result depends to a significant degree on the quality of that relationship. The difference from the past is that the client arrives at the conversation with much clearer ideas, and this changes the nature of the relationship itself: less approximate translation of vague requirements, more collaboration between someone who knows the business and someone who knows how to turn it into software.

It is reasonable to expect that, on a not-distant horizon, part of this relationship will change shape. The direction of travel for the tools is clear: the actual construction, from writing code to deploying a first working system, is becoming a commodity. Not the entire relationship, however. On one hand, no entrepreneur can expect to single-handedly replace the full arc of competencies needed to bring a reliable system into production: tools have their own ways of failing, often barely visible to those without technical experience, and those failures are paid for in daily operations. On the other hand, the need for an external perspective does not dissolve along with the cost of code; it remains useful, and probably necessary, to have someone who acts as a mirror, raises objections invisible from the inside, brings experience accumulated on similar problems.

The nature of this figure changes accordingly. Their value proposition shifts from writing code to producing concrete solutions, and will almost certainly take the form of a combination between AI and human, where the AI does the technical work and the human stays on the level where value truly forms, that of dialogue and focus. While the technical part of construction will continue to cost less and be faster, the ability to understand what should be built and why will become the scarcest resource in the process, and the one that determines its quality.

Those who do not ask themselves how their software represents their business are better off with standard solutions, and they are right to use them. The new possibility opens for those who have already sensed that something is off, and now have the tools to do something with that intuition: to stop choosing the software that will model their business, and begin building the software that models itself on the business that already exists.