When Talvenor became an AI workflow systems company, we didn’t patch the old website. We rebuilt it from scratch, with the same rules we use for client systems: build only what’s needed, test the failure cases, and keep a person in control.
This is how it was built, what it’s made of, and what went wrong along the way.
The brief we gave ourselves
Before any design, we wrote down what the site must never do:
- No invented proof. No fake clients, testimonials, numbers or logos. If we haven’t done it, it isn’t on the page.
- No third-party tracking. No advertising pixels, no cookies, no third-party analytics. We count visits ourselves, anonymously, without storing anything that could identify a person. A visitor should be able to read everything without being followed.
- Nothing leaves the browser unless the visitor sends it. The readiness check and the interactive demo run on your device; a readiness result is shared only if you choose to, with your consent.
- The contact form must be safe to leave running. It shouldn’t be usable to send spam, and it shouldn’t keep personal data forever.
Then the Home page was designed as a mockup and approved before a single line of production code was written.
What it’s made of
- Astro, generating plain static pages. Most pages ship almost no JavaScript, which is a big part of why they load fast.
- Cloudflare Pages to host it, plus four small server functions: the contact form, the optional readiness-result sharing, the optional “reach me” card and our own visit counting.
- Supabase (Postgres) for the data: enquiries, articles, project details and site settings.
- Self-hosted fonts and media. The demo video plays from our own server, so watching it doesn’t load YouTube.
The interactive workflow on the Home page, where a fictional enquiry stops at a human approval gate until you click Approve, is about 100 lines of plain JavaScript. It pauses when it’s off screen and jumps straight to the gate if your device asks for reduced motion.
The contact form: small, but built like a system
The form is the one place where a stranger’s data reaches us, so it got the most care:
- Spam filters that don’t track you: a hidden honeypot field, a check that the form wasn’t submitted inhumanly fast, and a check that the request came from this site.
- Rate limits inside the database: the same email address can send at most 3 enquiries in 10 minutes, and the whole form accepts at most 60 an hour.
- Visitors can write, never read. The public key can create an enquiry through one database function. It can’t read, change or delete any enquiry, including your own.
- Automatic deletion: every enquiry is deleted 6 months after it arrives, unless the person becomes a client. A scheduled job runs the clean-up every night.
- A confirmation email that can’t be abused: when it’s switched on, it contains none of the text you typed, so nobody can use our form to send their message to someone else.
How we tested it
We didn’t want to say “secure” and “fast” without checking. Every change runs through:
- 59 database checks on a throwaway copy of the database: can the public key read enquiries? Can it change an article? Do the rate limits trigger? Does the clean-up keep clients?
- 35 automated tests on the server functions, including bots, oversized messages, attempts to inject extra email headers, fake profile links, and a database that’s down.
- Browser tests on every page at desktop and phone width: accessibility (WCAG 2.1 AA), no sideways scrolling, no errors, and proof that the pages load nothing from third parties and set no cookies.
- A secret scan that fails the build if anything that looks like a key or password is in the code.
In our first mobile Lighthouse test, the Home page scored 95 for performance and 100 for accessibility, best practices and SEO. That was measured on a local test server, so the real site should do slightly better.
What went wrong
Plenty, which is why the tests exist.
- Words glued together. An automatic HTML-shrinking setting removed the spaces between some words: “name,company” instead of “name, company”. We switched it off.
- Text that was too faint. The accessibility checks failed a few grey labels for low contrast. We made them brighter.
- A demo that didn’t fit. On a 900-pixel-tall laptop screen, the Home page demo pushed the approval gate below the fold. We tightened it until the whole story fits.
- A table that didn’t work on phones. The Systems table was cramped at phone width, so on small screens it now becomes a stack of cards.
- Audio that was too loud. The original demo video’s audio was clipping. We re-encoded it to a normal loudness and cut the file from 30 MB to 8.8 MB, with no difference you can see.
Built with AI, checked by a person
We built this site with Claude as an engineering collaborator: writing code, running the tests and catching problems. Every design decision, every piece of copy and every change to a live system was approved by Shivam first.
That’s the same approach we sell. AI makes the work faster. It doesn’t make anyone less responsible for the result.
Want a system built the same way for your business? Tell us about one workflow, or see what else we’re building.
