Building Blue Canoe · 3 of 3
Prepare to Be Wrong: What the MikroTik Installation Actually Taught Us
How incomplete information, a wrong assumption and a simple cooling fix reinforced Blue Canoe's evidence-led engineering approach.
Originally published on LinkedIn on 27 August 2026. This is the permanent Blue Canoe edition, with dated technical updates where the work subsequently progressed.
The MikroTik installation went well. That does not mean we were right about everything.
One of the most useful lessons came when a perfectly reasonable assumption sent us in entirely the wrong direction.
Incomplete information is still incomplete
The information supplied by the ISP was not complete enough to describe everything the existing Arris was doing. We had to reconstruct parts of the behaviour from the network we could see and from observing the Arris itself.
That is dangerous territory because a plausible explanation can very quickly start behaving like a fact. We built a model, started troubleshooting against it and discovered that the model was wrong.
The fix was not more elaborate reasoning. We simplified.
Start with the smallest thing that can be proved
We reduced the network to the most basic useful configuration and built functionality back up one piece at a time. Prove the link. Prove routing. Prove addressing. Add the next function. Test again.
That method is slower than firing ten configuration changes at the problem. It is considerably faster than discovering three hours later that change number four was wrong and you no longer know which of the other nine changes are masking it.
The first successful traffic through the MikroTik was the turning point. Once the foundation was proven, the rest moved surprisingly quickly. I had expected perhaps a month of trial and adjustment. We were live in two days.
Then it got hot
Very early in production we hit a thermal warning from the 10Gb WAN hardware. The RB4011 and its MikroTik S+RJ10 copper module needed more airflow than the installation was providing.
The eventual engineering solution cost less than £20: a pair of USB fans underneath the router.
The fans were installed on day two and have remained part of the production setup ever since. There have been no further thermal warnings. In the later five-host load test the router stayed between 27°C and 31°C, while the S+RJ10 module ranged from 63°C to 66°C. They are different sensors on different components, and recording both removed the ambiguity from the earlier remembered figures.
The cooling units are cheap enough that I keep two spare sets. Cheap components; important function. Cheap insurance.
The lesson was not 'buy fans'
The broader lesson was to solve the problem actually observed.
We could have redesigned the installation, replaced hardware or disappeared into specifications and theoretical thermal limits. Instead we supplied more airflow, watched what happened and kept measuring. The warning disappeared and has stayed gone.
Plans are allowed to change
I tend to carry plans in a deliberately incomplete state. They become more concrete as evidence arrives. That sometimes conflicts with AI assistance, because an AI is very good at seeing enough pieces to propose an immediate complete answer. It can collapse an idea into a solution before I am ready to stop exploring it.
Learning to resist that has been important. The plan is a framework, not a commandment. Real output wins.
The phrase I keep coming back to is simple: checking is cheaper than fixing.
And when the evidence says the plan is wrong, being prepared to be wrong is not a failure of the process. It is the process working.