In the window and door industry, that difference is larger than it may seem at first. Two companies can use the same profile system, the same hardware supplier and the same glass, while their actual sales logic is completely different. One company may refuse to sell a certain construction below a defined size, another may allow it with different hardware, a third may apply a different surcharge logic for the same color, a fourth may have separate conditions for dealers, while a fifth may simply not offer some combinations even though the supplier technically allows them. On paper, all of them sell windows. In reality, each company sells according to its own production and commercial model.
That is where the difference becomes clear between software that merely stores data and a system that actually understands the business. A window or door is not a single row in a price list. It is the result of a set of technical and commercial rules that become active depending on dimensions, typology, opening method, profile system, glass, hardware, color, additional elements, services and the customer to whom the product is being sold. Individually, none of these rules may seem particularly impressive. Together, however, they form a decision system that an experienced salesperson or technician may have spent years carrying in their head.
A product is a configuration, and a configuration is a set of dependencies
With simple goods, the logic is straightforward: an item has a code, a name, a price and a quantity. With windows and doors, that is almost never enough. Dimensions affect the construction, the construction affects the hardware, the hardware affects the price, glass can depend on the intended use or customer requirements, color may carry a different surcharge depending on the system, while additional profiles, shutters, handles, services and discounts all enter the calculation according to their own rules. One component may be priced per linear meter, another per square meter, a third per piece, while a fourth exists only when a certain condition is met.
In software terms, this is a system of dependencies and constraints. In the language of a salesperson, it is much simpler: “this goes with that, this combination is not allowed, and for this kind of customer the price is calculated this way.” Good vertical software has to understand the first world so that the user only has to deal with the second.
Complexity does not disappear because the interface is simple. Quite the opposite: a simple interface is often possible only after the complexity has been placed in the right part of the system.
That distinction matters. A simple application that does not know enough about the business merely shifts the burden to the user. There may be only a few fields on screen, but next to the monitor there is still an Excel sheet, a PDF catalog, a calculator, a notebook and the phone number of the colleague who knows the exception. Formally, the application is easy to use. In reality, the process still depends on human memory and improvisation.
Much of a company’s knowledge is often written down nowhere
In many companies, the most important operating rules have never been formally documented. They are passed on through conversation, experience and habit. A senior salesperson knows which hardware should be used in a specific situation, a technician knows which combination causes problems in practice, while the owner or commercial manager knows which customer receives which terms. While the team is small, this model can work surprisingly well. People sit close to one another, questions are answered quickly and mistakes are corrected informally.
The problem appears when the company starts to grow. A new salesperson does not know every exception. Another branch is opened. A dealer works from another city. Someone is still using an old version of the price list. The experienced commercial person is unavailable. Suddenly, it becomes clear that a significant part of the company’s know-how never truly belonged to the company — it belonged to the people who remembered it.
That is one of the reasons digitalization cannot simply mean transferring a catalog from a PDF into a database. A catalog is relatively easy to rebuild. What is far more valuable is formalizing the questions that appear every day: what can be combined with what, where an important limitation exists, when something should be added, which terms apply to which customer and how the final price should be formed.
Once those rules are translated into a structure the system can understand, they are no longer merely individual experience. They become institutional knowledge.
Software should not force a company to work “the software’s way”
One of the common problems with business software appears when the application has a single predefined idea of how the industry is supposed to work. The user gradually starts adapting their own processes to the limitations of the software. In some cases that is justified — standards and best practices exist for a reason — but when it comes to the technical and commercial logic of individual manufacturers and dealers, this quickly becomes a problem.
Companies differ in their product ranges, suppliers, customer types, discount policies, pricing methods, services and in how much freedom they want to give their salespeople. Software that cannot represent those differences usually ends up in one of two extremes: it is either too rigid, forcing users to find workarounds, or too permissive, allowing practically anything to be entered into the system, including combinations the company should never sell.
Neither is a good outcome.
The real objective is for the system to be strict enough to preserve the company’s technical and commercial logic, while remaining flexible enough for that logic to change when the business changes. That balance is difficult, but without it vertical software becomes either an ordinary database or a digital mold into which every company is expected to fit.
The worst version of “smart software” is one where every rule is hard-coded
There is also the opposite mistake. It is possible to build a highly advanced system that understands a company extremely well — but only because every company-specific rule has been manually embedded in the program code. As long as nothing changes, such a system may work perfectly. The problem begins when a supplier changes a price list, the company introduces a new profile system, changes the way a surcharge is calculated, adds a new shutter model or adjusts the commercial policy for a particular customer segment.
If every such change requires a developer, the company has not truly gained control over its own rules. It has merely replaced its dependency on Excel with a dependency on the development team.
A business rule and a software feature are not the same thing. The software feature should make it possible to represent, validate and apply the rule. The rule itself, wherever reasonable, should remain under the company’s control.
That does not mean everything should become a setting. A system in which every tiny detail is configurable can quickly become harder to maintain than the business it was supposed to model. The architectural challenge lies precisely in drawing the line between a stable software core and a changeable business model. But where change is a natural part of everyday operations — price, product range, commercial condition, parameter or restriction — the normal response should not be “call the developer.”
A good system reduces the number of decisions a person has to make
When people talk about automation, they often mean faster calculation. That is the most visible part, but not necessarily the most valuable one. Far more important is the system’s ability to eliminate unnecessary decisions.
If one selection automatically excludes five others, there is no reason to show those five options to the salesperson. If a price can be derived from parameters the system already knows, there is no reason to enter it manually. If a customer already has defined commercial terms, there is no reason for the salesperson to remember the percentage. If a certain combination is not allowed, it is better for the system to prevent it from being created than for someone to discover the mistake after the offer has already been sent.
This is where the difference becomes visible between a system designed for data entry and one designed to support decision-making. The first faithfully records whatever the user enters. The second uses known rules to reduce the space in which the wrong choice can be made.
For an experienced salesperson, this means faster work. For a new salesperson, it means much more — the system provides an operating framework in which they can work correctly even before they have learned every nuance of the business. This does not replace professional knowledge, nor should it. But there is little value in making someone spend a year memorizing rules the company has already defined once.
Scaling sales is really about scaling rules
A company with three salespeople can operate through trust, direct communication and a large amount of tacit knowledge. A company with thirty salespeople, several branches or a dealer network cannot work in quite the same way.
Every new user increases the risk that the same rule will be interpreted differently. Every new location increases the distance between the person who defines the rule and the person who applies it. Add different discount levels, local product ranges, several suppliers and different commercial models, and the problem is no longer simply “how do we create an offer?” The real problem becomes how to preserve consistency across the entire sales system.
That is why the scalability of business software is not only a question of concurrent users or server performance. A much more interesting question is whether a company’s rules can scale to a larger number of people without a proportional increase in supervision, training and manual checks.
This is where a well-modeled system begins to show its real value. A new salesperson does not have to know everything. A dealer does not have to call headquarters about every combination. The commercial manager does not have to personally check whether everyone is using the latest version of the rules. The system becomes the shared working version of what the company currently considers correct.
When a rule changes, the entire organization should not have to be retrained
This is one of the most practical effects of digitally defined rules. When a business policy changes in a company that relies on spreadsheets, emails and human memory, there is usually a period in which several versions of the truth coexist. One person has seen the new price list, another has not. One dealer received the information, another did not. One computer has the new Excel file, another still has the old one.
When the system carries the rule, the change spreads differently. The user does not have to learn a new formula in order to apply it correctly. The next relevant operation already uses the new setting. Of course, people should still understand why the policy changed and what it means for the business, but correct execution no longer depends entirely on whether everyone happened to read the message.
That matters more than it may sound. Companies rarely suffer from a total lack of rules. More often, they struggle with applying those rules consistently.
Where Okvir.io fits into this
The idea behind Okvir.io is not to give a company one universal catalog of windows and doors and then expect the company to adapt to it. The starting point is the opposite: the system should represent the model of the specific company — its product range, relevant technical parameters, pricing logic, commercial conditions and the rules that determine what the user is offered at a given moment.
That means there can be significantly more logic beneath a simple configuration flow than the user ever sees. That is how it should be. A salesperson should not have to think about the order in which the system checks dependencies or how a particular rule has been modeled. Their job is to do the sales work while the result remains consistent with the company’s rules.
At the same time, rules that are business-specific and naturally change over time should, wherever reasonable, remain manageable through the interface. Changing a price, product range or commercial condition is not a new software project. It is part of the everyday life of a company.
That is one of the important boundaries in the development of Okvir.io: the complexity of the system should not be pushed onto the user, but control over the business should not be pushed onto the developer either.
Digitizing the price list is not enough
If a company loses an Excel price list tomorrow, that is inconvenient, but the price list can be rebuilt. If it loses the way it has spent years making hundreds of small technical and commercial decisions, the problem is much more serious.
That is why the most valuable part of a business system in the long run is often the least visible one: the accumulated rules, constraints, dependencies and conditions that have been turned into a repeatable process. They are what separate an “offer-making program” from a system that genuinely carries part of the company’s operational knowledge.
And that may be the most important thing to understand about simplicity in software. Simplicity is not the absence of complexity. In the production and sale of windows and doors, complexity is real and cannot simply be wished away. Profiles, hardware, dimensions, glass, technical constraints, price lists, surcharges and commercial conditions will exist whether the software understands them or not.
The only question is who carries them.
Every salesperson can carry them in their head, supported by several spreadsheets and the occasional phone call to a more experienced colleague. Or the system can carry them, leaving people to focus on what they are actually there to do: understand the customer, choose the right solution and close the job.
