A few days ago we were at WMF2026, in Bologna. Everyone is talking about artificial intelligence, and building software or a website has never been faster: the tools, AI included, do a good part of the work. The question we carried with us was a different one: how many, really, do it with care? We spoke with several companies. Solid products, good ideas, sharp people. With one of them, at the end of the day, the conversation opened up, and we left it like this: “try our platform and tell us what you think.”
That same evening we looked at two things calmly. The first is their corporate website, the first place you land. The second is the platform they had offered us, their best idea. Not to nitpick, but out of curiosity, and because an outside eye sometimes sees what whoever builds it has grown used to.
What we found (and what happens to everyone)
The site was well made: careful copy, clear structure, no clutter. The platform too: a solid idea, well presented. Yet, looking under the surface, a few things came out. None of them is an “incompetent” mistake: they are things that slip through when you move fast, and they can slip past us too. We tell them as classes of problem, not as a recipe, because the point is not the single case, it is learning to recognize them. Let's start with the site.
A consent banner that blocked nothing
The cookie banner was there, with its buttons. But the analytics scripts fired anyway, before the user chose. The banner was there, the blocking was not. It is one of the most common things you see around, because “putting up the banner” looks like the hard part, while the real one is actually blocking tracking until consent arrives. On why a banner that is only for show is not enough to be compliant, our cookie policy is written with exactly this rule in mind: no tracking before the yes.
Links pointing to the test environment
Still on the site, some links in production pointed to the staging environment: the working copy where everything is tested before publishing. It happens when you copy and paste in a hurry, or when a build drags along an address that should have been changed. From the outside it looks like a detail. In practice it exposes a part of the work that was meant to stay internal, and it confuses whoever is browsing: two versions of the same site, and no sign of which one is the real one.
Data you could not see, but could reach
Now the platform. Looking at it calmly, we noticed that some personal data (first name, last name, email) did not appear in the interface, but was still reachable in a few minutes by anyone with a bit of technical know-how, on a public portal. “You cannot see it” does not mean “it is not there”: hiding a piece of data on the screen is a different thing from protecting it. We are not writing how you got to it, and you do not need to know: the class of problem is this one, real data within reach of someone who should not see it, data someone could have collected and used for their own ends. It is the most serious one, because it touches real people.
Stale data, and a skipped check
Still on the platform, another thing stands out: a lot of the data it shows is clearly outdated, frozen some time ago. It is not a cosmetic problem, it is the sign of a skipped step. When you bring in data from another source, the first job is not to move it, it is to check it: data quality. Integrating without verifying means dragging old or wrong data into production, and then making decisions on top of it. It is the step that, in data integration, comes before the transfer: first you check what you are moving, then you move it.
Why it happens, and why it can happen to anyone
It is not a matter of skill. Today's tools make it easy to reach something that works and looks finished. The part that has not been automated is doubt: stopping and asking yourself “what if this data were reachable from outside? what if this link went online just like this?”. The first check is not the code, it is the critical thinking of whoever builds. The same tools that make us fast are afraid of nothing: they do not know which of your data is sensitive, nor what happens downstream. That awareness is carried by whoever knows the problem and answers for the result.
The difference between a demo and production
A demo has to convince: it shows the idea, and it is perfectly fine if underneath it is a shell. Production has real people inside it, real data, real consequences. The same screen, in a demo is a promise, in production it is a responsibility. And when you open a public portal, anyone can look inside: those details you do not notice in a demo become the door the problems walk through. The dream of a platform, there, can quickly turn into its opposite.
We told them in person, and they thanked us
The next day we went back to them, at the fair, to carry on the conversation, and we told them in person. Not to play the good guys, and not to sell anything: because that is what you do. They thanked us, and they were glad of the report. It went the way it should: whoever notices says so, whoever receives it fixes it. Not “look how others get it wrong”: things slip past us too, and we would be glad if someone told us the same way. Doing things well is a shared responsibility of those who build, not a grade on a report card.
A checklist before going to production
None of these questions requires you to be an expert. It requires not switching off doubt when the tool says everything is ready.
- Does cookie consent really block analytics and tracking until the user accepts? The banner alone is not enough.
- Do all links and addresses point to production, and not to the test environment?
- Is personal data protected upstream, at the who-can-access-what level, and not just hidden in the interface?
- If you imported data from another source, has someone checked its quality and freshness before bringing it into production?
- For a public portal, has someone who did not build that part tried to look inside with fresh eyes?
- Is there a moment, before launch, when you calmly review what you are about to publish?
Building fast is easy. Building well is a choice.
The tools have lowered the bar: reaching something that runs is within everyone's reach. Doing it well, though, is still a choice, and it shows in the details nobody will notice until they go wrong. It is the same method we work by, on a website as on custom software: understand first, then build, and before publishing, look twice. If you like, we can take a look at your website or your application and send you a report, no strings attached: sometimes an outside eye, before or after you publish, is all it takes to catch what you have grown used to. Tell us how you work.