Built
How this site was built
The profile says Aaron Wells directs software by writing a specification first, then verifying what comes back. This page is that method applied to the page you are reading. The specification is real; the site was built against it in October 2026 by an AI coding tool, Claude Code, with Wells reviewing and verifying each change on a live server before accepting it. Nothing here was written by hand except the words.
What it must do
- Read as a magazine profile of a person, not a services page and not a résumé. Third-person narrator; the subject quoted in first person. A reader should want to hire him or have a beer with him, ideally both.
- Be one page that stands on its own at every width from a phone to a wide monitor, in light and dark, with as little JavaScript as possible. It ended up with about 40 lines: the theme switch, and a poster that loads the video player only when pressed.
- State only facts that trace to his own documents or his business site. Every number exact: 46 pages, 22 releases, 177 sources, 1,864 briefings. Nothing rounded up.
- Pass accessibility checks at WCAG 2.2 AA with zero violations and keep every Lighthouse category above 95.
- Let a reader write to him without ever publishing his email address.
What it must never do
- Look like a template or like another AI-built site: no centered hero with two buttons, no three feature cards, no logo strip, no gradients, no glass panels, no icon fonts, no emoji, no Inter.
- Tease the subject. The dry turns are aimed at ceiling fans, beige roofs and dial-up modems, never at his policies, prices, credentials or clients. A pull quote never opens with what he does not do.
- Use an em dash, an exclamation point, or any of a list of about thirty words that mark marketing copy: elevate, seamless, passionate, journey, storytelling, cutting edge.
- Load anything from a third party: no fonts from a CDN, no analytics, no tracking pixels, no cookies. The one embedded player is his own platform, mlsvideos.com, which is the only outside origin the content security policy admits, only inside a frame, and only after the reader presses play. Inline scripts and styles are forbidden and the page is built to satisfy that.
- Reach the server except through Cloudflare. The origin accepts web traffic only from Cloudflare’s published addresses and nothing else.
- Invent a story. Where a true anecdote was missing, the writer was told to leave a marked gap rather than make one up.
How we knew it was right
- Screenshots at 375, 768, 1,280 and 1,920 pixels in both color schemes, looked at by a person, with a check for horizontal overflow at each width.
- An automated review of every paragraph: no negative openings, no asides at the subject’s expense, no banned words, no sentence over forty words without a reason, no two consecutive paragraphs opening the same way.
- Four readers on the copy, in this order: a publicist, an agent, a brand lead, an editor trained on the AP Stylebook. Each had a veto.
- axe-core on every page, an HTML validator on every file, a link checker on every reference, Lighthouse on the live domain. Every blocked spam attempt on the contact form is quarantined, not discarded, so a real message caught by mistake can be recovered.
- A fresh read by Wells, who rejected the first headline, the first set of pull quotes and the opening image, and was right each time.
What was rejected
- “Aaron Wells Does Not Write Code.” The first headline. His own line, but it led with a negative, and the whole page was reworked so that nothing does.
- The bathrooms. The first draft opened with him waiting for the light in other people’s bathrooms. Accurate, memorable, and replaced by the press, which is where the headline comes from.
- The signature. An ink signature closed the profile for a day. It read as signing a note he had not written.
- A timeline. A dated record of jobs was built and removed. A profile is allowed to skip things; a chronology is not.
- Two other designs. A charcoal contact-sheet layout that let photographs dominate, and a page whose background moved through the Arizona sunset as you scrolled. The first made the site about the photographs, which live elsewhere; the second was a gradient site with a rationale.
- A staging site. Built, used, and removed at his request. Previews happen locally now.
What it runs on
- Markup
- Hand-structured HTML and one stylesheet, about 600 lines, organized in cascade layers. A small Python build step content-hashes assets and precompresses text.
- Type
- Newsreader for text and display, with its optical-size axis, and IBM Plex Mono for labels. Both self-hosted, subset to the characters the site uses. The spacing scale is in picas, since a rem at 16 pixels is one pica, which is what a paste-up room measured in. The favicon is the letters A and W as outlines pulled from the Newsreader font file.
- Images
- His own photographs, served in AVIF, WebP and JPEG at three widths each, metadata stripped. The portrait is a stipple engraving he owns. The Arizona map is drawn from public county boundaries into an inline SVG.
- Server
- A Debian virtual machine. Caddy serves the files and renews the certificate. SSH on a non-standard port, keys only. Automatic security updates, a nightly local backup, fail2ban.
- Edge
- Cloudflare in front: TLS 1.2 minimum, HSTS, a rule that blocks the usual scanner paths, a rate limit on the contact form, and none of Cloudflare’s injected scripts, which were turned off one by one.
- Contact form
- A 200-line Python service with no dependencies, running as its own locked-down user. Honeypot, a signed timing token, hourly limits, link and keyword heuristics, duplicate detection. Mail goes out through his own mail provider.
- Scripts
- One, about 40 lines, which switches the theme, remembers the choice in the reader’s own browser, and swaps the video poster for the player on request. The other script tag on the profile is structured data that browsers never execute.
- Scores
- Lighthouse on the live domain, mobile: performance 96, accessibility 100, best practices 100, search 100.
The method, in one paragraph
The specification was written before any markup. Work went out in scoped increments: the voice guide, then the brand decisions, then the page, then each change. Everything that came back was read, run and checked against the specification before it was accepted, on the live server, with a dated backup and a documented way to roll back. When something was wrong, the fix was to the specification first and the page second, so the next change could not make the same mistake. This page is part of the specification now.
The specification, voice guide and build scripts are kept in the site’s repository. Ask through the contact form if you would like to see them.