I reuse the system, not the website

Three personal projects became the proving ground

A template can save time in the wrong way. Change the logo, replace a colour, move two blocks and the previous website is handed to another business. The code has been reused, but so have the decisions. That is how websites become formally different and fundamentally identical.

I wanted to test the opposite. I compared my professional website, gianlucapartengo.it ↗, and Animals in Black ↗. The first needs to present services, work, tools and content in two languages. The second is a single-language author website, with books, a biography and a nocturnal editorial direction. The third is a bilingual photographic archive with a catalogue, search, basket and payments.

They share some technical responsibilities and some code. They do not share page hierarchy, tone, navigation, visual language or data model. Even the actions they invite are different, because their audiences and purposes are different.

These three personal projects allowed me to test the new foundation against very different requirements. Once verified, the same method entered the websites I build and maintain for clients: each business receives its own structure, content, identity and features, while technical responsibilities already solved remain under control.

If changing the logo and photographs is enough to recognise the previous project, I have not built a reusable system. I have built a mould.

The shared part is what must always work

Every website needs sound HTML structure, clean URLs, security headers, canonicals, sitemaps, theme management, keyboard navigation and forms that do not lose data at the first error. A multilingual project needs consistent paths, metadata and links for every language. A single-language one should not drag around a disabled multilingual system.

These responsibilities do not make a brand recognisable. They make the website governable. They are also where a small inconsistency can spread everywhere: a faulty helper can generate the wrong canonicals, one routing rule can create duplicate URLs and a mouse-only component can compromise every page that uses it.

That is why I turned those responsibilities into a maintained, verifiable source foundation. General fixes are studied in the shared base and brought into existing websites by comparing behaviour, never by blindly replacing customised files. Tests check the structure expected for the chosen profile, essential markup and shared functions.

The advantage is not having fewer things to do. It is knowing which decisions have already been addressed, where they live and how to verify them before a change reaches the public website.

Four layers stop the foundation becoming a cage

I separated what belongs to every project from what must remain specific. This is not a theoretical distinction: it determines which files are generated, which components exist and where custom work can intervene without breaking the rest.

The shared foundation may establish that a control needs an accessible name and must work from the keyboard. It does not decide how that control should look on a photography website or an author’s website. It defines how canonicals and language alternatives are built, but not which pages should exist or what they should say.

This separation lets me work at the right layer. A security fix should not rewrite the visual identity. A new design choice should not alter routing. A feature built for e-commerce should not appear on a website that sells nothing.

Single-language and multilingual are not the same website with a switch

The distinction between single-language and multilingual profiles is one of the clearest examples of the method. It would be easy to prepare one package full of features and hide the unused ones through configuration. The website would still contain dispatchers, dictionaries, selectors and rules it does not need.

I chose two physically distinct profiles instead. Before generating a project, I declare its languages, primary language and locales. The single-language profile receives one dictionary and no multilingual infrastructure. The multilingual profile builds localised URLs, canonicals, hreflang, selector and sitemaps from the same map, while checking for collisions between slugs.

This is not a feature added to impress a client. It reduces ambiguity and inactive code. Above all, it forces an architectural decision before pages begin to fill with content.

A website should contain what it genuinely needs. Modularity has value when it also knows what to leave out.

Three personal projects, three recognisable identities

On my professional website, the structure has to connect services, work, tools and two editorial formats. The design is precise, technical and built for consultation. Internal search crosses very different content, and routing must resolve it correctly in English and Italian.

At gianlucapartengo.it, the centre is books, writing and biography. There is no language selector because the website is genuinely single-language. Typography, space, images and movement create an editorial experience, not a different colourway of the website where I sell services.

Animals in Black uses another grammar again. Black is part of the photographic project, animals sit at the centre of the interface and one architecture must connect species, photographs, prints, commercial variants and payments. Here, data does more than compose a page: it must remain consistent across archive, shop, feed and external systems.

These three projects show that infrastructure can be shared without imposing the same result, provided it was designed to separate responsibilities and identity. I apply the same principle to client websites: the method remains, the result belongs to the business.

Not every website receives everything

Reusing a system does not mean installing every capability it offers. Internal search makes sense when there is a body of content to explore. A catalogue belongs where products or works have structured data. Multilingual publishing should exist only when it will be maintained as a complete journey. Unused features are dependencies to update, check and protect without creating value.

Optional components are therefore added when the project requires them. They do not sit hidden in anticipation of a possible future. The shared foundation defines how to integrate them correctly; the work on the website decides whether they should exist.

Custom work also remains within the project that produced it. The Animals in Black catalogue does not become a universal feature. The author website’s editorial components do not become blocks to distribute everywhere. They may suggest a solution, but first they must be separated from their context and prove they carry a genuinely shared responsibility.

This discipline prevents the shared foundation from growing into a storehouse of everything I have built. It should contain what I know how to maintain and verify across projects, not the indiscriminate sum of previous projects.

What the client actually receives

A client does not fund a new experiment on every basic element, and does not receive a copy of the previous website. They receive an architecture that starts from verified rules and is then adapted to the real responsibilities of their business.

This means clearly distinguishing what belongs to the system from what was built to measure: identity, content, features, data and journeys. It also means limiting dependencies to the parts that are genuinely needed and knowing where to work when the website needs to evolve.

To me, a professional template is not a collection of ready-made pages. It is where I preserve the decisions that must remain reliable, so every new project can focus on the decisions no other website can make on its behalf.

I reuse the system precisely because every website deserves to be designed as a unique case.