Clinical Psychology Practice Site — Designed and Coded Solo

A solo clinical psychologist needed a one-page site that could turn a visitor into a booked session. There was no CMS to build, no login and no backend: the entire booking mechanism was going to be WhatsApp. So the job was to make a single page carry the positioning, the reassurance and the opening line of a conversation — and then to build it.

Freelance work under Locuz, taken on after the Spaceapps era. Sole designer and sole developer: the reference pass, the moodboard, the style guide, the page design and the production build were all mine. There was no existing brand to work from, and the only photograph I was given was a single 150×150 profile picture.

The brief

One page, in Portuguese, for a clinical psychologist working alone. It had to do the work a practice website does when there is no reception desk behind it: say who she is and who she treats, name the feelings people actually arrive with, explain her approach, list the health plans she accepts, answer the questions that stop someone from writing the first message, and give directions. Twelve sections in the end, and every one of them earning its place on a page nobody scrolls twice.

No brand, one 150×150 photograph, two weeks

The project started from almost nothing: no logo, no palette, no type pairing, and one 150×150 profile picture. So the first half of the work was building the thing the design would then be made of — a visual-reference pass, a moodboard, logo explorations, and a style guide covering the palette, the Cormorant Garamond and Montserrat pairing, and the desktop and mobile grids. Underneath it, a twelve-step warm-sand ramp with semantic aliases that resolve in both light and dark.

📄12

sections on the page

🧱13

bespoke section components

⚙️9

shadcn primitives underneath

🎨30

design tokens authored

When the design was settled I marked the file released for development and then built it myself, as a static Next.js export: thirteen bespoke section components sitting on nine shadcn primitives, three legal pages and a custom 404. It was deployed a week in, and the second week was fixes and adjustments she asked for. Designing and building the same page has one specific advantage, and it is not speed. It is that nothing gets designed that cannot be built, and nothing gets built that quietly drops what was designed.

The booking mechanism is code, not decoration

WhatsApp was the entire conversion path, which meant the interesting design problem was not the button — it was what the message already says when the button opens the app. A visitor who has to compose their own first message to a psychologist is a visitor who closes the tab. So every entry point on the site opens WhatsApp with its own pre-written Portuguese message, phrased for the place the person was standing when they tapped: seven distinct deep links, fourteen rendered instances across the deployed page.

The one I am fondest of is on the 404, where the pre-filled message is not about booking at all:

A broken link on a practice site is a person who wanted something and did not get it. Handing them a sentence that describes their actual situation costs one line of code and turns the worst page on the site into a working entry point.

Responsiveness was built in the browser, not in Figma

The mobile artboard in the design file is empty, and that is not an omission I want to hide — it is how this one was made. The desktop page was designed at full fidelity and the responsive behaviour was then written directly in code, where the breakpoints actually live; the deployed HTML carries 177 responsive utility hits. It is a reasonable method when the same person designs and builds, and a bad one to hand to anybody else. On a project with a separate developer, the artboard gets drawn.

What this is not

• Not a backend. The Express file in the repository is dead template scaffolding and was never deployed; the site is a static export served by Apache.
• Not a themed site. The design file resolves a complete light and dark token set, but the deployed page ships no dark-mode utilities and the theming library goes unused. That was a scope decision under a tight clock, not a feature.
• Not competitive analysis. The large benchmark board in the file is ten full-scroll screenshots placed side by side — visual reference, nothing annotated and nothing synthesised.
• Not a 1,189-token design system. Thirty tokens were authored for this project; the rest of that number is inherited ramps that came with the base file.
• Not analytics. Only Google Tag Manager appears in the deployed page.
• Not my starter file. The base came from a course template, which I made production-grade through auto-layout and tokenisation — after which it became the default file everywhere I worked.

The collateral nobody asked for

A practice does not stop needing things once the site is up. Alongside the build I produced Instagram highlight covers, a business card, and a four-page walkthrough for setting up her email in Thunderbird, with annotated phone mockups. None of it was in scope. All of it was the difference between handing over a website and handing over something someone can actually run.

Evidence

The build was finished, deployed, and is still inspectable on my own host. It never went live under the client's own domain. The imagery is AI-generated, she did not want it representing her practice, and the root domain was parked to redirect to her Google Business Profile instead. The project went unpaid. I had asked for photographs and been given one 150×150 profile picture, so I generated the imagery rather than let the ship date slip; she turned it down, and that was the end of it. The artifact is real and the source is public. The lesson is worth more than the project was: photography is now a precondition I settle before the work starts, not a dependency I design around.