Context
I work alone, doing design and front-end for small clients, almost all in the same niche: physiotherapy clinics, courses and events. Many projects are open at once, each with a live site where a wrong push goes straight to production.
Before that I worked at an agency. What frustrated me was not the volume, it was the cold brief: a document arrived saying what to build, without me ever talking to the people who would use it. The process was a waterfall, and in a waterfall one communication failure at any point is enough to lose the whole project. What the client asks for is not always what they need, and I had no way to find out.
Two limits of my own also count here. I don't judge color by eye; I need the number. And with many fronts open, the question that goes unanswered is what gets lost most: not from lack of interest, but because attention has already moved to the next thing.
The problem
The question was never "how to use AI". It was: how does a designer working alone keep production quality across several projects, with no team, without forgetting a client's decision and without publishing what shouldn't go out?
The risks were concrete, because each one had already happened or nearly had:
- an accidental deploy on a shared server where the wrong path overwrites the neighbor's site;
- a color picked because "it looked nice" that fails contrast;
- a decision the client made in a conversation that nobody wrote down;
- a testimonial or a price invented by the tool to fill a blank;
- a question of mine the client never answered, and that I also forgot to ask again.
The approach
There is a kind of professional, the forward deployed engineer, who sits inside the client, learns how they really work, builds the software for that reality and hands back what was learned as a system. I did that with myself as the client.
The process was the same one I use on any project. Talk and understand where the person is. Know who will use it. Prototype fast, by hand. Ask the AI to prototype on top of the sketch. Validate. Test with real people. Apply, learn, refine. The difference is that the person was me, and the "product" was my working day.
The rule that came out of this investigation: a limit becomes a method when it becomes a written rule, not willpower. Everything I did "from memory" and sometimes forgot became a file the tool reads before it starts.
The system
Each piece exists to cover a specific failure. None was planned top-down; all of them came from a mistake or a near miss.
Deploy triggers in plain language. "Done" and "you can commit" mean commit, and the tool asks "Can I publish?" before any push. "You can publish" is the only yes. In repositories where a push publishes nothing, the rule flips: always commit and push, so no work is lost. Covers the accidental deploy.
Color is a number, not an impression. Every color arrives with three things: the hex, its role (background, text, action) and the contrast ratio measured against the real background. "Looks good" is not an accepted answer. Covers color decided by eye.
External, versioned memory. One file per fact, with a date: who the client is, what they decided, what never to do. A one-line-per-file index is read at every session. Client decisions are recorded with the date they were made. Covers the forgotten decision and the invented content: without material from the client, the rule is to mark it as pending, never fill it in.
One question at a time, and a living list. Pending items live in a list the tool shows again at the start and end of each block of work, separating what depends on me from what depends on someone else. Questions come one at a time, starting with the one that unblocks work. Covers the lost question.
One CLAUDE.md per project. The rules that don't change: the deploy path on the shared server, what is forbidden, the code conventions. It is the brief I never got at the agency, written for the tool and for my future self six months from now.
An environment that restores itself. The whole setup, rules, memory and shortcuts, lives in a private repository. On any new Mac, a script brings back the same working environment.
Tools that came out of the process. The quick sketch became a paper prototyping kit that clients use with me. The trouble of matching team photos became a script that crops portraits by face detection. Every time a problem repeated, it became a tool.
In practice
Reeduca Fisio prepares physiotherapists for the specialist board exam in intensive care. The idea was an iPhone quiz app with real questions from past exams, organized by topic, each with its source.
The obvious path was for the specialist to write the questions. But I talked before drawing, and what I saw was someone who works all day at the clinic and teaches at night. Asking her for 120 questions from scratch was asking for a project that would never leave the drawing board, not for lack of will, for lack of hours.
So I flipped the dependency. The 2023, 2024 and 2025 exams existed as PDFs. A script reads each exam, transcribes the questions into the app's database with the options and the answer key, proposes a topic and keywords for each one and marks everything as not reviewed. Annulled questions stay out. Questions with a figure stay hidden until the app can show images. Nothing enters the quiz without passing through a person.
For the specialist, I generated one spreadsheet per exam, in the format she already uses: one row per question, the proposed topic, a "Has image" column and a notes column. Her job stopped being "write 119 questions" and became "check 119 questions", which fits in one evening. A second script applies her review to the database and ships a new build to TestFlight.
In one of the PDFs the exam structure was different from the others. Instead of guessing, the question stayed on the pending list until she answered. It is the whole system in one small example: understand how the person works, build for that reality, keep human validation in the middle and invent nothing.
What changed
Before, a project paused for two weeks came back with questions. Where was the client's copy? Did she approve that color? What was the deploy path? Today I open the session and the first thing on screen is the list of what is pending, and whose turn it is.
Before, "done" could be a deploy. Today "done" is a commit and a question.
Before, the AI filled the blank with a plausible testimonial and I had to hunt for what was invented. Today the blank stays marked as pending, and the client knows what is still missing.
And what I like most: I work more than I did at the agency, because I investigate before I draw. Only now the investigation isn't lost between one project and the next.
What I learned
- AI doesn't replace the conversation with the client. It comes in after the sketch by hand, never before.
- The risk isn't the tool being wrong. It's the question going unanswered.
- A limit that becomes a written rule stops being a limit. It becomes the most reliable part of the process.
- The method I use with clients works on me. Understand deeply, build for the reality found, hand it back as a system.
"Understand how someone really works and hand it back as a tool."
This case is for anyone who needs someone to do exactly that inside a company: understand a domain deeply and hand it back as a usable system. Let's talk.