I had three structurally similar sites: my personal blog, LiveDXB and the nevskii.me portfolio. Putting them in one technical house felt natural. Why solve images, routes, languages and builds three times?
That led to shared Astro code with settings for each site. It allowed mechanisms to be reused while keeping different content and presentation. But a shared platform quickly reveals a familiar household trait: renovations in one room can be heard in every other room.
The “nevskii.me — first screen” view preserves the project’s real materials and design.
nevskii.me — first screen
Archived interface · demo data
A shared template increases the reach of an error
When an article component changes, opening one convenient page is not enough. You need to know which sites use it, which block variants exist and where the text will be longer. Arabic adds writing direction, a gallery adds media order, an old URL adds redirect rules.
The “nevskii.me — internal section” view preserves the project’s real materials and design.
nevskii.me — internal section
Archived interface · demo data
Site configuration must therefore explicitly select content, routes and design. Someone else’s material must not accidentally enter a neighbouring release just because a suitable file sits nearby. The more you work with agents, the more useful it is to make these boundaries visible in the system itself.
nevskii.me — contact section
Archived interface · demo data
Architecture is allowed to change
Over time, the needs diverged. nevsky.ae gained its own application and editorial source in Git. LiveDXB retained its process based on published EmDash revisions. The Astro version of nevskii.me remained a separate preview.
I therefore do not describe this story today as “three live sites on one unchanged engine”. The shared platform was a stage that helped identify reusable parts. Some boundaries later needed to be drawn more firmly.
That is a perfectly useful outcome. You can reuse routing or block-processing solutions without requiring editorial teams to follow one schedule forever. Otherwise, savings from avoiding three code copies gradually turn into the cost of coordinating every move.
When working with studios and brand groups, I now start by asking: what is actually shared? If it is only the owner’s logo, a unified platform can be an expensive way to emphasize that. If it is the content model, team and release process, shared mechanisms are worth using.
The common foundation allowed content, language and page handling to be reused. The projects later separated. This post preserves that architectural decision’s history: similar interfaces do not mean every site needs one source and one release.
Related stories: The history of Nevsky.ae · LiveDXB migration · Portfolio from Framer to Astro.
@nevsky_alexander
On Instagram: Dubai beyond the postcard — family, the city, discoveries and life between projects. On Threads: thinking out loud about design and AI. On YouTube: videos that need more room than a story. Follow me wherever you feel at home, and let’s keep in touch