A custom system for a company’s own calculation model
The situation
A forestry company was in the business of buying and selling forest properties.
Before making an offer to a landowner, the company’s staff had to gather information about the property, assess the value of the forest, and — using the company’s own financial model — calculate the price at which acquiring it would be economically justified.
These calculations were not universal.
They were tightly bound to this particular company’s business model, its assumptions, and the way its staff worked with owners.
A large part of the process happened in Excel.
Why custom software came up at all
This was not a situation where the answer was simply to find yet another off-the-shelf CRM or calculator.
The company already had its own logic:
- its own input data;
- its own formulas;
- its own assumptions;
- its own property valuation process;
- its own way of using the calculation in conversation with a client.
So the idea of a custom system was entirely logical.
The software could be built around how this company actually works, rather than asking the company to bend its process to the logic of a ready-made product.
What we built
We developed a specialised solution that moved a substantial part of the calculation and offer-preparation process out of Excel and into a system of its own.
To do that, we had to understand:
- what data a valuation requires;
- how the maximum acquisition price is calculated;
- which parameters change during the process;
- how an employee uses the calculation during a conversation;
- where strict business logic is required;
- and where the user needs freedom.
Technically, building a custom solution was perfectly possible.
And that is exactly the point: a highly specific company process was not an obstacle to software.
What real use revealed
Once the system was built, a different problem became visible.
Excel was already deeply familiar to its users.
It let them change assumptions quickly, experiment with calculations, and handle non-standard situations.
In part of the process that flexibility turned out to be worth more than a more rigidly structured specialised system.
So the new solution did not replace Excel as completely as originally intended.
What we would do differently today
The conclusion was not:
custom software was a bad idea here.
The conclusion was a different one:
we tested how it had to fit into a person’s real work far too late.
Back then, getting that answer took several months of development.
Today we would start with a much smaller step.
For €1000 we would build a prototype of the main working scenario:
- enter real property data;
- reproduce the most important calculation;
- allow the key assumptions to be changed;
- show the result in the form an employee actually works with.
And then put it in the hands of the people who use Excel every day.
Within a few days you could see:
If the prototype proves its value
Then the next step is no longer an abstract “big IT project”.
There is already a concrete, tested working model.
In 8–10 weeks it can be turned into a full solution for everyday work — with data storage, users, access rights, integrations, testing and everything else a production environment needs.
That changes the economics of custom software substantially.
A company used to have to invest a large sum just to find out whether a solution of its own would be workable at all.
Now that question can be tested first.
The main point
This example showed us two things at once.
First: turning a highly specific company process into custom software is entirely realistic.
Second: there is no point building all of it before testing how people will work with the solution in practice.
So today the sequence would be:
a €1000 prototype → real use → conclusions → 8–10 weeks to a production system, if it really is needed.
Does your company have a process that is too specific for an off-the-shelf solution?
Show us one specific working scenario. Within a few days we can show what a program built for exactly that could look like.