Showcase website & admin interface

Project context

I built an architect’s portfolio website from A to Z, replacing an old WordPress site.

The homepage had been displaying ‘Site under construction’ for several years, and the admin interface was not suited to his actual usage. For an architect who only publishes a few projects per year, coming back occasionally to a dense interface filled with unnecessary sections quickly became discouraging, which gradually led him to stop updating the site.

The goal was therefore to create a site with a real identity, smoother overall, but above all to design an admin interface limited to his actual needs.

Existing analysis

Before starting any design work, I analyzed his existing site and listed all the original data.

This work wasn’t just about listing data. It mainly helped me anticipate upcoming decisions and optimize our discussions. By going through everything that already existed, I was able to identify redundant information, data that could be merged, elements that were no longer useful, but also potential gaps compared to similar websites.

Visual direction & framing

The client didn’t have a clear directive. He could tell what he liked or disliked, but without having a clear vision of what he actually wanted.

I therefore prepared our first meeting in advance by doing visual research, gathering inspirations, proposing color palettes, typography pairings and thinking about the target audience. I also designed 4 homepage variations based on his own projects, each with a very different visual direction, to help him project himself and position his preferences.

The goal wasn’t to get a perfectly formulated request, but to give him concrete material to react to, get feedback, refine his preferences and gradually build a clear direction.

Product vision

The main challenge was to create a tool that is simple, reliable and pleasant to use. The public interface needed to be bright, both clean and elegant, with colors inspired by raw materials and a few original touches.

The admin interface, on the other hand, had to be clear, direct and free of unnecessary noise. It was designed to be easy to use, with a single-page structure organized into collapsible sections.

Architecture & data modeling

Once the direction was validated, I defined the data model and started working on the back-end.

Based on our discussions, I structured entities aligned with real needs and seeded reference data. Relationships use eager and cascade sparingly.

DTO & mockups: a direct link

In my projects, I always connect DTOs and mockups. They can be designed separately, but working alone allowed me to be more demanding about that alignment.

I started by designing the user-facing part, then moved on to the back-end alongside the admin interface. I first imagined the behavior, structured the data accordingly, then designed the UI to match it.

Without that, structures can quickly become too heavy or not suited to the interface. I don’t see a DTO as a simple projection of the database, but as something directly tied to how the user interacts with the system.

Back-end construction

Once the structure was defined, I developed the services required for the site to function.

The API covers all content, including projects, their images, as well as global data such as contact information, the “atelier” page description, the architect’s background, and collaborations (MOE) with their associated links. It also allows selecting featured projects on the homepage and controlling their display order.

Some data is intentionally exposed differently depending on front-end needs in order to avoid unnecessarily heavy requests.

Security & access management

With the API functional, I added access management. Sensitive routes are protected via JWT, with guards limiting certain actions based on roles.

Before going live, I also added several protection mechanisms such as header management, rate limiting, and permissions configuration.

Front-end & personal growth

The front-end was built starting from simple elements and gradually moving toward complete pages.

I created a reusable base with constants, types, hooks and components reused from previous projects and adapted when needed.

For styling, I used Tailwind only for responsive handling. Everything else was done with styled-components to keep full control over the rendering.

Even though I’m naturally more back-end oriented, this project helped me evolve my approach to front-end work. I used to try to control every detail across every screen size, but I realized it’s more about finding a balance that works across as many formats as possible rather than locking everything down.

Image handling

High-quality images are essential in architecture.

I handled image processing on the back-end to control file size without visible quality loss, and to generate multiple formats for different use cases. Images are ultimately stored on Cloudflare R2.

This complements the optimization already handled by Next.js on the front-end.

Deployment & real constraints

Deployment was a particularly impactful phase of the project.

At first, I planned to use a simple setup with Vercel and Render. However, the client’s existing hosting changed that decision.

What I initially thought was an expensive yearly cost turned out to be a 3-year payment. It wasn’t an option to make him abandon that investment, nor to propose a solution that wouldn’t allow him to make use of it.

His hosting offered some flexibility but imposed a very outdated version of PostgreSQL, incompatible with the project. I had to move toward a VPS, which wasn’t planned initially.

I approached this step very carefully. Even though I already had an idea of what needed to be done, I prepared everything in advance by listing all configurations and their execution order to avoid mistakes.

Managing a VPS involved aspects I hadn’t fully worked with before, especially around security and infrastructure. This phase helped me strengthen those areas and get back into working with Linux through the command line.

Production & monitoring

Once the site was live, an issue occurred the very next day due to a browser update affecting scroll behavior.

Since all pages were impacted, I quickly identified that the issue came from a global point, which allowed me to fix it without having to break down the analysis.

After that, I set up a ping system with Better Stack to be immediately alerted in case of downtime.

Result & perspective

The site is now functional, deployed and stable.

This project allowed me to cover the full lifecycle of an application and was an interesting experience beyond purely technical aspects.

What stands out the most to me is the human side of the work: listening, analyzing, understanding, reformulating, guiding and proposing, but also making decisions, adapting and responding.

These are all aspects I was able to practice and genuinely enjoy, especially because of the responsibility it implies toward the person you’re working with.