Fovero Technologies
Four free tools, and a recommender that tells you what it rejected.
NextJS
ReactJS
TypeScript
Supabase
- Cheerio
- Resend
- 116
- Detection rules
- 38
- Tech options scored
- 10
- Scoring dimensions
- 0
- Tests
The problem
An agency site is a brochure, and nobody trusts a brochure. The useful version gives a prospect something before asking for anything, and the thing they most want is an answer to "what should I build this with, and what is wrong with my current site?"
What I built
Four tools. A technology recommender that asks eleven branching questions and returns a stack. A website auditor that fetches a page and scores SEO, accessibility, security and performance against what it actually finds. A stack fingerprinter that identifies 116 technologies from markup, scripts, headers and meta tags. And a digital readiness quiz.
Around them: result caching keyed on a canonicalised URL, a lead scoring model, transactional email, and a follow-up sequence on a schedule.
Decisions I'd defend
The recommender is three layers, and the order matters. Filter first, on hard rules: a mobile project cannot use a web-only frontend, a non-technical team cannot use a framework that requires code. Then score, across ten independent dimensions. Then validate across categories, because a coherent stack is not just the top-scoring item in each column: picking a hosted store builder means there is no backend to recommend, and a Flutter app cannot sit on a serverless function that sleeps.
The scoring tables are keyed by technology name inside its own category rather than by tags. The previous engine summed tag weights globally, which let an answer about mobile boost anything tagged mobile regardless of which column it was in. Names cost more to maintain and stop the categories bleeding into each other.
The explanations are a by-product of the filter, not a second list. Every exclusion returns a human-readable reason, and the "why not React, why not AWS" section reuses those strings verbatim. Adding a rule automatically produces the right explanation, so the two cannot drift apart. Telling someone why you rejected the thing they were expecting is most of what makes a recommendation credible.
Every external dependency degrades rather than fails. No performance API key means the auditor falls back to eleven heuristics over the HTML instead of returning nothing. A cache read or write failure is swallowed and the tool still runs. An email send happens off the response path. The scheduled follow-up advances a subscriber stage only after a successful send, so a failure retries tomorrow instead of skipping someone.
What I would do differently
The download button says PDF and returns HTML with a print button. It produces a fine document, but the label writes a cheque the code does not cash, and that is the first thing I would fix.
Two of the eleven questions are collected and then never read by the engine, left behind when the scoring model was replaced. Worse, the feature checkboxes for e-commerce and mobile projects do not overlap with the feature scoring table at all, so on those branches that question contributes exactly nothing. The retired engine is also still imported, so it ships in the bundle unreachable.
There are no tests, on an engine whose whole selling point is that the same answers always produce the same recommendation. That is the single highest-value test suite I am not writing, and a handful of snapshot cases would lock it down.
Where it is now
Live, with all four tools linked from the homepage and feeding a real lead pipeline.