DB
Daniel Beher
Blog & reflections
✍️ Same projects, but from inside my head

Notes from a calm problem-solver.

This is where I talk less like a CV and more like a human who likes to understand why things break and how to make them less painful next time.

Posts
Behind the scenes of a few projects
Router stories · Facewatch

How a “simple reboot” turned into a £9,000 decision

There is a special kind of ticket that says: “The SIMs do not work, can you send someone to the site?” The first instinct is to say yes. The router is far away, the ceiling is high and nobody wants to be responsible if something goes wrong.

But then you realise that every “yes” costs around £300 and it is literally for pressing a button. Multiply this by a batch of failing SIMs and suddenly we are playing a very expensive game of remote hide-and-seek.

So instead of accepting the pattern, I asked a different question: “What exactly do we need from a human on-site?” Turns out, we only needed a device on the local network that we could trust. The rest could be done from a keyboard.

That is how the iPhone near the router became our remote control. Connect it to Wi-Fi, open the right tools, SSH into the router, run the commands, bring the SIMs back to life. Same result as the £300 visit, zero time in a van, less stress for everyone.

The fun part is that from outside it still looks like “Daniel rebooted some routers”. On the inside it is a small culture shift: before we spend money, we check if the problem is actually physical or just a limit of our imagination.

Alert accuracy · Facewatch

We did not fix the AI. We just stopped feeding it junk.

When false alerts start growing, the room usually fills with words like “model”, “thresholds” and “we need a new version”. That is exciting, but also risky. Changing the core system is like doing surgery when maybe the patient just needs to stop eating fast food.

I asked a very unglamorous question: “What exactly are we putting into the database?” The answer was: everything. Good images, bad images, cropped faces, weird angles – if it vaguely looked relevant, it went in.

So we started cleaning. We removed obviously bad entries, tightened what “good enough” means and made the process of adding new images more disciplined. No fancy math, just less junk.

The result? False alerts went down. Users felt like the system “got smarter”, even though the clever part stayed exactly the same. We simply stopped confusing it.

I like this kind of solution because it is boring on paper and powerful in reality. It reminds everyone that sometimes the quickest way to improve a product is not more features, but more respect for the data we give it.

Support & processes · Facewatch

Support teams are not firefighters, they are system designers

When you look at a busy support inbox, it feels like a natural disaster: tickets falling from the sky, everyone running around, a lot of “urgent” labels and very little time to think.

The trick is to treat every ticket not only as a problem to fix, but as a vote for how the system is designed. If the same type of ticket appears again and again, it is not a coincidence – it is a product feature we forgot to design properly.

Working on our support setup, I started with very simple questions: What are the most common issues? Where do we get stuck? Which answers live only in someone’s head? From there it became a documentation and structure project, not just a “work harder” project.

We added categories that actually matched reality, created templates, wrote down steps and turned fragile personal tricks into shared knowledge. Tickets became easier, and new team members did not have to read anyone’s mind.

My favourite moment is when people say, “It feels calmer now, but I cannot point to one big change.” That is exactly the point. Many small, boring improvements, layered carefully, beat one huge dramatic “transformation” almost every time.

Operations · Amber quarry

A camera line, some rocks and £30k a month

An amber quarry is not the first place where you expect to talk about “visibility” and “dashboards”. But the logic is the same as in any tech stack: if you cannot see what is going wrong, you will pay for it later.

The production line had silent mistakes – small deviations that turned into real money over time. The simplest idea was also the most effective: give the team live eyes on what is happening.

A camera line sounds boring until you look at the numbers. With better monitoring and faster reactions, the line reduced waste enough to save around £30,000 every single month. No magic, just visibility and feedback.

I like this story because it shows that “project management” can start with something as basic as positioning a camera correctly and asking the team what they actually need to see to do their job well.