We entered Fixathon as hackers. We left as winners.
Usually I show up to a hackathon as the organizer, the mentor, or the judge. This time was different. Helder, Henrique and I decided to do something we hadn't done in a long time: sit on the other side of the table and build, just for the fun of it.
We always play to win. But honestly? We did not expect this one.
The room at Fixathon, hosted by Impact Hub Porto on TAIKAI, was stacked. Real maturity, real engineering, teams from CEiiA, INESC TEC, universities in the Netherlands, serious people solving serious problems. That level forced us to level up. We got more demanding with each other with every hour that passed, and a lot of that pressure came from the outside too: the organizers, the BluFab by Casais team, and the judges who kept pushing every team to do more and raise the bar.
Thank you to everyone who supported us. This one meant a lot. 馃挋
The challenge
BluFab industrialises off-site construction. Homes, buildings, and the modular bathroom panels at the center of this challenge. Production time feeds every commercial proposal and every plan they make. The problem: that time is estimated from manual references and tacit knowledge living inside one person's head. When the estimate is wrong, the cost compounds into misaligned proposals, broken planning, and credibility lost in front of clients.
So we built Cadence.
What we built
Cadence is an auditable operational layer that turns panel drawings into defensible time estimates, with video from the production line continuously training the model underneath.
The product itself is simple. You enter a panel's characteristics, dimensions, metal frames, drillings, cladding type, finish, and Cadence returns the total production time plus a per-micro-operation breakdown, with confidence intervals and the reason behind every single line.
Three things made it ours:
A glass box, not a black box.聽Every prediction breaks down into something a human can read: "+10s from +33% vs reference frames". The reasoning lives in the interface, not buried in model documentation. Change a panel's characteristics and the estimate recalculates with the deltas visible. Every estimate is stored in an append-only audit log with features, model version and timestamp, designed for ISO-grade auditability from day one.
It learns from the line. Video from multiple camera angles on the line, overhead and at the operator's eye level, gets segmented into micro-operations automatically. A reviewer fine-tunes any boundary in seconds, and every confirmed segment becomes a validated label that re-trains the predictive model. The line teaches the estimator, continuously. The estimate is the product. The video is the mechanism that keeps it honest.
Radical honesty about what it knows. Operations with insufficient data get flagged low-confidence in amber instead of being faked as precise. The system knows what it does not know, and says so.
We won on evidence
We didn't want to win on a pretty demo. We wanted to win on evidence.
Across nearly 20 different panels, Cadence's time estimates landed within about 12% of the real production time on average. That's already close enough to be useful on a commercial proposal, and it gets tighter with every panel the factory produces.
The clearest example: a real panel that took 16 minutes and 7 seconds to build. Cadence predicted 15 minutes flat. That's under 7% off, and it broke the gap down operation by operation so a human could see exactly where the time went.
We also did the test most teams skip. We ran the model on panels from a completely different build that it had never seen during training. Anyone can look good on data they've already memorised. The real question is whether the system can be trusted with panels the factory hasn't produced yet, and that's the test we put it through.
All of it runs on a single local machine, no cloud required, so the factory's data never has to leave the building. That matters a lot to an industrial client who cares about confidentiality.
For the technically curious: the core is a gradient boosting regression model trained on the factory's own production data, paired with a vision-language model that turns line video into labelled training examples. We validated it the strict way, always testing on panels the model had never seen, so the accuracy numbers reflect real generalisation and not memorised data. Explainable by design, on-premise capable, no vendor lock-in.
How we actually pulled it off
A few things from the trenches that I won't forget.
We built the solution as the challenge revealed itself. The briefing came in pieces, and with every new detail we redrew the design. In parallel we were testing options for the two engines under the hood: the model that predicts the time, and the vision model that reads the line video. But the part that actually decided the outcome was less glamorous than any of that. It was sitting down and brainstorming the process itself, breaking a panel's production into the handful of characteristics that genuinely drive how long it takes to build. Get those right and the model reasons. Get them wrong and it guesses. That whiteboard session was the real turning point.
Here's the part I like most. We are AI builders, not data scientists. We design, ship and operate AI products every day, but a CatBoost-style predictive model trained on a factory's own production data is not where we usually live. That turned out to be an advantage. We came at the problem like product people: obsess over the right features, choose tools that are explainable and portable, and refuse to trust a number we couldn't explain. The data science was learnable in two days. The product instinct, knowing what to build and what to leave out, is the part you can't cram. Clear thinking about the problem beats deep specialisation more often than people admit.
We also had one team member who, right up until the verdict, never believed we were going to win. Not pessimism, just brutal realism about how strong the room was. But the same person was 100% sure we had a hell of a project. That tension, "we might not win but this is genuinely great", is honestly the best headspace to build in. It keeps you humble and sharp at the same time.
At basically the last minute we bolted a chatbot onto the project to make the whole thing more appealing and easier to interrogate. Was it strictly necessary for the results? No. Did it make the demo land harder? Absolutely.
And yes, there was a sacred snack break in the middle of it all to go grab an 茅clair from Leitaria da Quinta do Pa莽o. Non-negotiable. You cannot ship an auditable system on an empty stomach.
Thank you
This win belongs to a lot of people who are not on our team.
To Impact Hub Porto for hosting, and to BluFab by Casais for a challenge with real industrial teeth and a team that stayed in the room with us the whole time.
To the judges who kept raising the bar: Pedro Andrade (Casais), Diogo Monica (Haun Ventures), Ricardo Mesquita (Wiseverge), Thomas DiGrazia (Neutronian), and Jorge Resende (IEM4.0). The pressure you put on every team is exactly why the output was this good.
And to the team that built it alongside me, Helder Vasconcelos and Henrique Macedo. We came to challenge ourselves. Mission accomplished.
There's a lesson in this one that goes beyond a couple of days. We spend most of our time at LayerX building AI products for clients and running the infrastructure other people innovate on top of. Stepping back into the builder's seat, under real pressure, against strong teams, is the fastest way to stay sharp and remember what it actually feels like to ship something from zero in two days.
Cadence is not a hackathon prototype. It's the first auditable operational layer for BluFab, and the kind of work we want to keep doing: AI that earns trust by showing its reasoning, runs where the data already lives, and is honest about what it doesn't know.
The room raised the bar. We intend to keep it there.
