How this site was built

Every product manager resume I compete with now says AI somewhere. Mine does too. A line on a resume costs nothing to write, so it proves nothing. I wanted a hiring manager to be able to check the claim instead of taking my word for it.

So the site had to be the evidence, not a description of it. It shows two live products I built with AI tools, ReturnKoto? and this site, and this page is the build record: what I gave the tools, what I decided, what the tools enforced, and how it reached production. A two-page PDF cannot show any of that.

What the site had to prove

1. That I ship with AI, not only talk about it. The proof has to be a live URL, a working product, and a build record a stranger can read.

2. That I hold AI output to rules. Fast output with wrong numbers is worse than no output. Every claim here traces to my resume, my LinkedIn profile, or a live page.

3. That I make the product calls. The tools offered options. Choosing between them, and saying no, stayed with me.

What I gave Claude Code

Files

My resume and my LinkedIn profile, both as PDFs. For version two, the full ReturnKoto? project folder.

Skills

Impeccable, a Claude design skill, and my own anti-slop writing standard, a Claude skill I first wrote for ReturnKoto?.

Links

My Google Calendar booking page and my LinkedIn profile, the only two ways to reach me from the site.

Eight questions before any code

Claude asked in two rounds before it wrote a line. The answers that shaped the site, written as the diff they produced:

Three directions, then Dieter Rams

Impeccable first wrote a product brief from my answers: who visits, what they need to decide, and which facts are off limits. Then, instead of reaching for its favourite look, it offered three visual directions. I picked The Release Log, a career written as a software changelog, over a fund factsheet, which sat too close to a finance candidate, and a standard PM portfolio, which looks like everyone else's.

Midway through the build I asked for Dieter Rams as an influence. His work for Braun is the reference for "less, but better", and a changelog is already a functional document, so the two fit. Each Braun idea became one rule on this page:

How the skills held the work

During the build Impeccable held every screen to a written craft floor: text contrast, keyboard focus, no card grids, no gradient text, no decorative labels above headings. Its detector scanned the source and returned zero findings. Then a separate review agent compared the finished site against the direction it had agreed to. It sent back eight fixes, among them colour on figures that should have been plain ink, a stats strip that read like a template, and arrow keys missing from the filter bar. After those were in, a second pass returned "ship", and a third agent wrote DESIGN.md, the design system file any later edit has to follow.

The copy went through my writing standard. It treats a page like a score that collapses if any single part fails, and every sentence here passed its five tests:

1. Substance. Strike every sentence with no fact, number, or decision. If more than a third dies, rewrite.

2. Inflation. Every strong word must be proved by its sentence. "Verified" survives only when someone verified it.

3. Competitor. If another candidate could paste the sentence unchanged, it is generic. Replace it with something only I can say.

4. Effort. The writer does the work, not the reader. The point goes in the first line.

5. Worst element. One wrong number or one banned phrase fails the whole page.

It caught real problems. An early draft described ReturnKoto?'s price history as weekly, when its return math runs on monthly prices, and the sentence was rewritten. Every figure on the site was then checked against its source, and a search for banned words and dashes came back empty.

From my laptop to mojtoba.com, with Cursor

I wanted the deploy done by an agent too, so Claude Code wrote a prompt for Cursor in eight phases, with rules on top. Tokens stay in one local file that is never printed or committed. The agent must stop and ask me before it changes nameservers, deletes a DNS record, or makes the repository public. Then the Cursor agent ran it:

Cursor then wrote down what it had actually done in the repository's deploy notes, so the next person, or the next agent, starts from fact.

Version two: my own review

Once it was live I read the site the way a hiring manager would, and sent back what did not work:

Claude Code made the changes, and a second Cursor prompt pushed them. The workflow from version one rebuilt and deployed the site on that push with no further setup.

Stack

Framework

Astro, built to static HTML. No client framework; small scripts for the filter keys and the motion.

Hosting

Cloudflare Pages, deployed by GitHub Actions on every push to main.

Domain

Registered at name.com, DNS on Cloudflare.

Data

The ReturnKoto? figures on this site are read from returnkoto.com's public data files by a daily GitHub Actions job, which keeps the last good set when a check fails.

Motion

CSS transitions, one small script, and cross-page view transitions. Off for anyone whose device asks for reduced motion.

Type

Mona Sans and Monaspace Neon, self-hosted.

Tracking

None. No analytics, no cookies, no third-party scripts.

What this says about how I work

The AI did the typing, the reviewing, and the deploying. I set the constraints, answered the questions, chose between options the tools could not choose for me, and sent the work back when it was not good enough. That is the job of a product manager on a team that builds with AI, and this site is a small, checkable example of it.