Reality did not validate the business case. It revealed which business case I was actually modelling.
In Part 1, I wrote that a model eventually reaches a point where another search adds less information than a conversation. The computer went with me because it contained a structured record of what I did not know.
The conversation did not fill in the blanks the way I expected.
It changed the architecture of the model.
Before the meeting, I had been treating rent as an input. Pick a number, put it into the operating model, and see whether the restaurant survives. That is a perfectly reasonable way to run a scenario, but it turned out to be a poor description of how the property owner thinks.
Rent was not really an input.
It was an output of another system.
The owner described a simple logic: the more capital that has to be invested in the restaurant building, the more rent the property has to produce. That sounds obvious once it is said aloud, but it changes the optimization problem completely. Instead of asking only, “How much rent can the food business afford?”, the more useful question becomes, “How little permanent capital does the building need before it can begin producing useful evidence?”
That distinction matters because a previous attempt at the site had moved in the opposite direction. The proposed solution became larger, more permanent and more expensive. As the building investment grew, the rent required to support it grew with it. Eventually the project became too heavy to carry.
The spreadsheet had been modelling the tenant.
Reality introduced the landlord’s balance sheet.
The second correction was more important.
I had deliberately kept the food business and the charging business in separate books. That was right. Revenue belonging to a charging operator should not quietly appear inside the restaurant’s economics just because the two activities happen on the same site.
But separate books do not mean separate systems.
The property owner does not only want a restaurant because restaurants pay rent. Food, coffee, toilets, light, people and somewhere to sit can change why a driver chooses one charging stop over another. A food operator may create value for a charging business without receiving a single krona of charging revenue.
The model had captured ownership.
It had not captured enough causality.
That creates a harder problem. If a food concept generates more charging traffic, how much is that worth to the site? If one operator pays less rent but attracts more drivers, is that operator actually more valuable? How do you measure the effect without simply inventing a number that makes the deal look attractive?
The answer, for now, is not to estimate harder.
It is to leave the relationship visible and unpriced until it can be measured.
A third assumption changed during the conversation. I had been thinking mostly about whether an operator could make the business work. The property owner was also thinking about what happens when that operator disappears.
That is a different kind of risk.
A founder-specific concept can be economically viable and still be unattractive to a property owner if the entire operation depends on one person. A known franchise, standardized kitchen or transferable format may be worth more than its immediate sales because another operator can step into it later.
The question is therefore not only whether the business works with me.
It is whether the business still exists without me.
That does not automatically make a franchise the right answer. Standardization has a cost, and a local independent concept may create things a chain cannot. But “operator replaceability” now belongs in the model alongside rent, labour, capital expenditure and demand.
That variable was not there before the meeting.
Neither was the site itself, at least not completely. I had seen the building, the parking area, photographs and maps. I knew the approximate property size. Yet my mental model of the place was still smaller than the owner’s. What I had been treating as a former grill with parking was closer to a small roadside development site with several possible layers.
That changes the design space. The restaurant is no longer necessarily the project. It can be one layer among charging, convenience, toilets, seating, unattended retail, family services or other uses that have their own operator, economics and reason to exist.
Again, the useful result was not validation.
It was decomposition.
There is a temptation after a good meeting to write that the idea “got stronger.” I do not think that is the right description. Some parts became stronger because uncertainty disappeared. Other parts became weaker because assumptions that looked reasonable in isolation no longer matched the stakeholder’s real decision logic.
That is what I wanted the model to be capable of doing.
A good model should not merely accept new numbers. It should be able to discover that it has the wrong variables.
So the next version needs at least three things it did not have before the conversation: rent derived from the capital actually required by the building, an explicit but initially unpriced relationship between food traffic and charging value, and a way to represent how easily one operator can be replaced by another.
Those are not cosmetic updates. They change what the project is optimizing for.
Before the meeting, the question was close to:
Can a food business at this site generate enough contribution to cover its costs and rent?
After the meeting, the better question is:
What combination of low building investment, useful food and service activity, operator transferability and charging traffic creates enough value for every party to keep the site alive?
That question is uglier.
It is also much closer to reality.
I went to the meeting hoping to replace empty fields with numbers. I came back with something more useful:
a different question.
