There is a particular kind of clarity that comes from being your own client.
Over the past two weeks I have been building the new Lean Otter website. We help established, non-tech businesses with AI-enhanced product development. So when it came to building our own site, I made a deliberate choice: use the same process I recommend to clients. Strategy before structure. Copy before code. Decisions grounded in understanding, not opinions.
What I did not expect was how much the experience would reveal about what working with AI tools actually requires of you.
I have built websites every way possible
WordPress. Wix. Framer. Figma Sites. Flat-file CMS platforms. Flash… Good old HTML, CSS, SASS and a bit of JavaScript.
Each of them came with their own flavour of friction. A proprietary system to learn. A plugin that breaks when you update something else. A visual editor that looks great until you need it to do something slightly outside its comfort zone. At which point you spend three hours fighting it to achieve something that should take ten minutes. The technical constraint had a habit of making decisions for you. You would come up with an idea, immediately sense it might be beyond your current skills or the platform’s limits, and quietly abandon it before you had even tried.
That constraint has gone.
The new stack is genuinely different
The Lean Otter site is built on Astro with Tailwind CSS, deployed on Vercel. During development I used VS Code with OpenAI’s Codex agent, Claude for strategy and copy, and Gemini for imagery. Lucide for icons. A bit of Figma where I needed it.
You might hear this described as vibe coding. It is not quite that. Vibe coding, in the sense of prompting your way to a product with no real understanding of what is being built, produces something that looks functional until it needs to do anything real. What I am describing is closer to vibe coding plus: you still need product thinking, design sensibility, and enough technical literacy to write a precise specification. But the implementation is no longer the hard part.
This is miles away from Lovable or Replit. I own the codebase. I own the repository. I can open the files, read them, extend them, hand them to an engineer without embarrassment. The AI is doing the heavy lifting on implementation, not running the show.
The practical difference is significant. My brain no longer stops short of an idea because the technical execution might be beyond me. I try things. Some work, some do not, but the cost of finding out is low. That shift changes how you think creatively, in ways that are hard to fully articulate until you have experienced it.
Building was the easy part
Here is the thing nobody tells you when they talk about AI-assisted development: the hard part is not the code. It never was.
The hard part is defining your ICP with enough precision that it changes how you write. It is nailing a value proposition in a market that is shifting under your feet. The AI world does not sit still long enough for you to finesse a positioning document. It is deciding what the site needs to say, to whom, and in what order, before a single line of code gets written.
The first version of the Lean Otter site was built too fast. The copy was generic. The positioning was soft. It said things like “we help businesses navigate digital transformation”, the kind of sentence that sounds reasonable and means nothing. The site looked fine. It said nothing.
So we started again. With the strategy. Then the copy. Then the structure. Then the build.
That order matters more than the tools you use. When you are working with AI assistance, the temptation is to collapse all four stages into one. To go from “I need a website” to “build me a website” in a single prompt. The output arrives immediately, it looks plausible, and before you know it you are iterating on something that was never properly thought through. I have watched clients do this. I did it myself.
The solution is to reimpose a sequential discipline, artificially and deliberately. Lock the strategy. Write the copy. Define the structure from the copy, not from a template. Then give the agent a precise written specification and let it build.
The quality of what comes out is directly proportional to the quality of what you put in. That sounds obvious. It is also consistently underestimated.
On process and Figma and the itch I have not quite scratched
I will be honest: there is still a part of me that wants to dust off the crayons and go back into Figma. There is something satisfying about designing in a tool built for design, about having that visual fidelity and control before anything gets built.
I will get there. But right now I am pushing the boundaries of what the current tooling actually makes possible, and those boundaries are further out than I expected. The constraints I assumed would frustrate me mostly have not materialised.
The process is not fully dialled in yet. I do not think anyone’s is. The tools are evolving faster than any process can fully account for. What I have found is that with the right foundational principles, product thinking, design sensibility, an understanding of how good software gets built, you are really only missing two things: the problem worth solving, and the creativity to solve it in an interesting way.
The rest, increasingly, is just execution.
One warning worth taking seriously
Do not let AI do it all.
I have seen what happens, and produced some of it myself, early on. The copy sounds vaguely professional. The layout looks clean. The whole thing is so completely forgettable that it serves no purpose whatsoever.
AI tools produce the average of everything they have been trained on. If you hand them your website without bringing your own thinking, your own voice, your own very specific perspective on the problem you are solving, what comes back is a perfectly adequate version of every other website in your space.
The site has a point of view because I have a point of view, and I refused to let that get smoothed away in the name of efficiency.
What I took away from it
The Lean Otter website is, in a small way, a working demonstration of the methodology. The same discipline I apply to a client’s AI product, understand the problem before you build anything, make decisions explicit, move fast but not recklessly, I applied to my own front door.
It took longer than it would have if I had just let an AI generate it in an afternoon. It is also (I hope) significantly better, and more honest about what we actually do.
That trade-off is one I would make again. And it is exactly the trade-off I would recommend to any business thinking seriously about their first AI product.