From 2019 to 2024 I worked as a Front‑End Developer on LuisaViaRoma, one of the Italian names in online fashion best known outside Italy. It was not my project: it was somebody else's product, with a team around it and rules written long before I turned up. This page is not about that website. It is about what five years in there teach you, and what of that trade ends up in the website of a beach club or a small sports club.
The problem
A fashion e‑commerce is not a website with products in it: it is a warehouse that changes on its own while you are looking at it. Sizes run out, prices move, collections come and go. Every page has to tell the truth at the moment somebody opens it, not the truth it had this morning.
When the shop is the site, a slow page does not make anyone angry: it makes them close the tab, quietly. Speed there is not a finishing touch, it is the front door, and the front door cannot be narrow.
Frequent releases, several people in the same files in the same week, features that slot in next to others written years earlier by someone who may no longer work there. In a place like that, improvising is not a risky choice: it is something the work will not let you do.
The role
I was a front‑end developer on staff, working on a product owned by someone else: new features and maintenance, alongside product, data and QA. I claim no authorship over it and will not list its features here. What I can tell you about is the way of working, the part I took with me.
1
The work never began with an idea somebody had over coffee: it began with a spec discussed with the people who own the product. First the why, then what is already there and how the new thing will sit next to it, and only then the code. That is the opposite of what comes naturally when you work alone.
2
In a living product, half the job is walking into code written years earlier by people you can no longer ring up. You read it, you work out what holds up what, and only then you touch it. That is where I learned that rushing in is the most expensive thing you can do.
3
Nothing was finished because it worked on my machine. It went past the person who asked for it, past the people who measure what happens afterwards, and past the people who put it under pressure before a real customer does. That is not red tape: it is why some things never reach production.
Spec→ Build→ Review→ QA→ Release→ Measure
What it taught me
These are habits, not technologies. Technologies age and get swapped out; these four hold the same on a huge e‑commerce and on a six‑page website.
How heavy a page is gets decided while you build it, not at the end with a plugin that promises to fix it. How many images you load and how, how much code you make people download, how much work you ask of the phone in their hand: those are design decisions, and taken late they are not taken at all.
Page weight · Images · Shipped code
A site gets used with a keyboard too, with the text zoomed in, on a beach with the sun on the screen. Writing HTML that says what things actually are, and not only how they look, is the difference between a site people can use and one that only looks good in a slide deck.
Semantics · Keyboard · Contrast
On a team, what you write immediately becomes somebody else's problem. Clear names, conventions you follow, no clever shortcuts that even you cannot decode six months later. That is the difference between a project you can maintain and one held hostage by whoever wrote it.
Conventions · Review · Naming
In a place like that, opinions about what works better last as long as it takes to open the data. Tests before release, measurement afterwards, and the willingness to find out you were wrong. It is the most uncomfortable habit, and the most useful.
Tests · Measurement · Checks
What stayed with me
That chapter closed in 2024, and you will not find figures on this page: that company's numbers are not mine and I have no business using them as a sales argument. What I can tell you about is what changed in the way I work.
I do not hand over a page without knowing what it weighs. I do not write code that only I understand, even when the project is mine alone. I put measurement in on day one, not on the last: after a launch nobody goes back to it. And I try everything with the keyboard before it goes live.
page weight/ keyboard pass/ reading the code back/ measurement before launch
It sounds like fussiness borrowed from a big project. It is precisely what nobody bothers with on small ones, and why so many local business websites are slow, awkward for a good share of their visitors and impossible to understand the day they stop working. The full path is told year by year on the about page.
What this means for you
A beach club or a sports club has no huge catalogue behind it, but the problem is identical: if the page is slow or awkward on a phone, the enquiry never arrives and you never find out why. Treating speed and accessibility as requirements, not as polish, costs little up front and a lot later. How I go about it is written up under websites and e‑commerce.
Speed · Accessibility · Measurement
The code I hand over has to be readable by somebody else, including you in three years' time. It is the same method I used to build Prenoo on my own, from the first line of the database to the last screen: when there is no team around to stop you, the discipline has to come from you.
Readable code · Tests · Handover