EVA Builder
The chain that takes an address and returns an audit, a redesign prototype and the thinking behind it. The machine gathers, measures, builds and checks; whatever reaches someone has been looked at.
EVA Builder is the machine behind the audit page: an address goes in, an audit and a redesign prototype come out, at the same URL. It is not a site generator. It is a tooled workshop where the repetitive share of the work (gathering, measuring, applying the system, building, checking) falls to the chain, so that human time goes where it counts. The robot circling its six workstations on the audit page comes from there: it is the same sequence, staged.
One folder per job, and nothing else
Everything about a job fits in one folder: the content and the measurements in a text file, the colours and fonts in a JSON, the prototype as an Astro project. No database, no hidden state, the repository is the state. A build rebuilds the whole thing, and a small guard at the door checks that the requested address really exists: an unknown reference returns a 404, never the neighbour’s page. What protects a link is its randomly drawn identifier, not a password nobody remembers.
The theme is derived
The colours are not picked by eye: they are extracted from the existing site’s images, then expressed as roles (a brand colour, an accent, two backgrounds) rather than as values scattered around. The inks are computed: every text colour is derived from its background so the contrast holds everywhere. The prototype loads the fluid scale of EVA CSS, then the job’s theme, then what little bespoke work remains.
Guards rather than a proofread
A prototype does not ship because it “looks fine”. A deterministic check comes first: system tokens respected, contrasts measured, image paths valid, alt text present, hero measurements within bounds. The core functions have their tests, with zero dependencies. And the daemon draining the queue publishes nothing: it pushes to a “needs review” folder. Automated work that ends in a waiting room is finished work.
Auditing the tool, then rebuilding it
A tool that audits sites eventually deserves the same treatment. The internal audit listed what was holding up badly, and the rework happened in stages, with not a single commit before the test suite went green again.
- The safety net first. Tests on the pure functions, input reading that tells “missing file” from “corrupted file”, and the end of that library file that rewrote itself on every build without a single line having changed.
- Then the flow. A progress bar showing where each job stands, the queue made visible with an honest signal (is the loop still running?), and live updates instead of a manual refresh.
- Sturdiness last. A guard against requests pointing inward, a size cap on downloads, and a template that renders empty when data is missing, instead of leaking another job’s content.
The rest is written down in the same file: what is deferred, what remains a known limit, what is not fully closed. An honest backlog beats a tool reputed to be finished.
What it does not decide
Three things escape it, and they are the three that matter. Saying whether the project makes sense: a site rebuilt last year does not need rebuilding, and we say so even at the cost of the job. Choosing the art direction: a machine can apply a system, it cannot tell which tone suits an architect rather than a caterer. And sending. Nothing goes out on its own.
Node and Astro for the making, Vue and Fastify for local steering, Netlify for delivery. No framework on the visitor’s side.