Cookies, forms, and the shared admin password: the boring website stuff nobody wants until it costs them

I am Matteo Santoro. In day-to-day work on sites and e-commerce, the part that makes people wrinkle their noses is not CSS: it is when I ask where form submissions actually land, whether that pixel was really approved, or why five people share the same dashboard password.

I am not your lawyer: if you need formal GDPR advice or contract language, you want a different professional. What I can tell you with certainty is what happens in code when these things stay fuzzy, because the outcome is not “a bureaucratic detail”, it is downtime, data scattered across tools, customers who cannot complete a field, or cookie banners that look serious but block nothing under the hood.

The site says one thing; the scripts do another

It happens often: the privacy page claims “technical cookies only”, but the homepage fires analytics, maps, chat, remarketing. That is not only a copy problem: someone added a tool “just to see numbers” and nobody realigned the stack.

During Websites, I prefer to know the integration list early (including “we might add later”). That way we do not ship a flow that must be ripped out because legal stops you at go-live, or because an ads vendor asks for an event you never wired properly.

The “contact us” form is not harmless

The classic name / email / message module looks trivial. Then you discover:

• messages land in a shared inbox across three teams and nobody owns replies;
• or they forward into Zapier / Make / a CRM someone connected on a random Tuesday without documenting it;
• or they sit for years in a database nobody cleans.

I am not saying that is automatically unlawful: I am saying it is fragile. On the web, fragile eventually breaks: staff turnover, vendor change, audit, security incident.

If you add chatbots or AI, the surface grows: a conversation is rarely “anonymous text”; it is often personal data crossing third-party servers. For the engineering side, I already wrote a practical AI chatbot checklist.

Security: boring things that work

No movie scenes: no hoodie hacker typing in a blur.

• HTTPS done properly, certificates that do not expire quietly, no sensitive data accidentally living in the URL.
• Named accounts, 2FA where possible, and retiring the legendary admin / Admin123! passed around internal chat for three years.
• Patches and backups as habits, not slogans: if you skip that, you get exactly what I described under website maintenance, something that holds until it does not.

Security “bolted on at the end” is always the worst version: patch on patch, plugins stepping on each other, and you paying for the same site twice.

Accessibility: not philosophy, traffic (and market)

I will keep this short and point you to slow or inaccessible e-commerce: the point is not moralising, it is that invisible barriers lock out real people and, in many EU contexts, put you on the wrong side of market rules.

In a proposal I do not want accessibility as a tiny line at the bottom: “if we have time”. Either it is a goal, or it is not.

What I actually need from you

No fifteen-page questionnaire. It is enough to know (or discover together): which tools run on the site, who owns inbound leads, how long you keep data, and whether you sell Italy-only or beyond. I translate that into coherent technical choices.

If you are launching something new or want a sanity pass on an existing site, see Websites and get in touch. We start from the concrete stuff, not the slide deck.