My first client project was not like building a website for myself with a different name and colour palette.
Until then, I had built notes, exercises and tools around my own needs. If something was left unfinished, I was the one dealing with it. With Patricia Pólvora’s website, every page had to help explain someone else’s professional work. That changed the responsibility behind each decision.
Patricia works in social impact consultancy, is an official Social Value International trainer in Spanish and runs The Social Consulting Agency. The website had to bring together services, reports, publications, press, training, talks and contact options without turning her career into a menu that was impossible to navigate.
The result was an Astro site with more than 17 indexable pages. The number matters less than what it forced me to consider. It was no longer enough for every page to look good on its own. The structure had to work for a first-time visitor, someone looking for a specific service and anyone needing to expand the site later on.
Understanding the work meant organising a career
This was not a three-screen product or a landing page with one message. There were different consultancy services, downloadable reports, editorial content, an entrepreneurship story, press coverage and a direct booking contact route.
Before getting into components, I needed to understand the role of every content block. Some deserved their own page because they answered a particular search or decision. Others made more sense as a group. The homepage could not carry the full explanation, but it had to point people towards what mattered.
That work changed how I see information architecture. Organising more than 17 pages did not mean repeating a template over and over. It meant deciding what each visitor needs to find and in which order. Once a website holds that much content, a weak hierarchy affects more than navigation. It also makes writing, maintenance and search visibility harder.
Building a foundation that did not rely on memory
I chose Astro, TypeScript and Sass because I needed a fast, controllable base that could grow. The goal was not to use a particular technology to make the stack look impressive. I wanted to avoid relying on memory whenever a page was added or a section changed, wondering where a style, metadata field or contact detail lived.
I organised styles with Sass 7-1, centralised repeated data and built pages from reusable components. That does not remove the work involved in a larger site, but it stops the project from becoming a collection of exceptions.
The choice also came with a trade-off. A static site gives you a lot of control while building, but it makes you think about how every update will happen. That tension between a clean technical base and the content owner’s autonomy is why I would not choose Astro or WordPress out of habit. The tool has to fit the real maintenance work, not only launch day.
SEO and accessibility stopped being extras
On a personal project, it is easy to leave technical SEO, alt text or careful navigation for when there is “more time”. That approach did not make sense when I was building for Patricia. The site needed to be findable and usable from the start.
Semantic structure, desktop and mobile navigation, accessible dropdowns and the panel-style menu were part of the product. They were not a final layer of review. I also prepared per-page metadata, canonicals, Open Graph tags, structured data, a dynamic sitemap and specific rules for legal pages.
Much of that work came back to one simple idea. Every page needed a clear job. A service page cannot compete for the same search intent as a press page, and a reports section should not carry the same metadata as a contact page. The technical SEO work I later applied to my own portfolio became more tangible here because every URL had real content and professional goals behind it.
Going live was part of the work too
The point that took me furthest beyond familiar ground was not writing a component. It was putting the website into production.
I deployed it on Vercel, set up Patricia’s professional domain and managed the redirects needed for the site to start correctly. It was the first time I had handled that full part of a project for someone else.
That process left me with a clear lesson. A website is not finished when it works locally. It is finished when it loads on its own domain, keeps its routes, presents its content correctly and can be used by someone who knows nothing about the repository behind it.
The difficult parts were not only technical
The challenge in a project like this is not limited to fixing code. I had to make decisions with incomplete information, prioritise very different kinds of content and avoid letting a new page unsettle the rest of the structure.
I also had to recognise the obvious limit of this being my first project of this kind. I had experience building websites and could research what I did not know, but I could not pretend to have already seen every situation that comes with a professional delivery. The domain, deployment and redirects were concrete examples of things I had to learn as the project moved forward.
The way through was not to improvise or add technology just in case. I broke the work into smaller problems, reviewed each one and returned to the website’s purpose. Whenever I was unsure between two options, I tried to ask a more useful question than “which one looks better”. What helps Patricia explain her work, and what can be maintained without rebuilding the site in a few months?
What I would do differently now
I would not trade the learning for an attempt to get everything right the first time. I would start some conversations and documents earlier because I value them more now.
From the start, I would define which content is likely to change often, who will make those changes and how much autonomy the person receiving the website needs. That answer affects architecture as much as design does. I would also write down a launch review covering routes, forms, metadata, responsive behaviour, accessibility and analytics. Not to turn a small project into bureaucracy, but to make sure important details do not depend on a last-minute memory check.
I would also set aside a review after launch. The first day online reveals things a local environment cannot, and it raises real questions about content, navigation and maintenance.
What I took from the project
This project confirmed something I had already started to learn from my apps and notes. Building is a way to learn, but building for someone else makes you learn more carefully. Code still matters, but it has to live alongside message clarity, maintenance limits, organic search, accessibility and the responsibility of publishing.
I did not leave the project thinking I could build any professional website. I left with a much more concrete reference for what delivering one means. I can now look at architecture, SEO or deployment decisions through a real experience, and I know more of the questions worth asking before opening the editor.
The technical details, pages and final result are collected in the Patricia Pólvora case study.