Build record / first-party work
TechGeek UK public site
A public route from a software-development search to a decision-ready project brief.
Implementation record
What was built
This record covers TechGeek's own public website, not a customer delivery. The implementation turns an urgent AI and software-development offer into a set of crawlable service, resource, policy, product and enquiry routes. It is intended to help a prospective buyer understand what kind of work can be assessed, what information is needed before a delivery date can be discussed, and where the public claims stop.
The central delivery position is deliberately conditional. The site describes a qualifying MVP as potentially deliverable in as little as seven days and a controlled first pilot as potentially targetable within thirty days. It repeatedly attaches those targets to agreed scope, feasibility, access, decision speed, delivery capacity and budget. The implementation avoids presenting either as an automatic entitlement, an emergency-response SLA or proof that any project can be completed in those windows.
- 01
A Next.js 16 public application with an information architecture for urgent software development, AI MVP development, pilots, AI development and transformation, rescue work, responsible AI, secure deployment, product pages, resources, policy pages, company information and first-party work records. The source has an explicit sitemap route list and static pages are generated from structured content rather than a page-builder export.
- 02
A structured rapid-assessment form rather than a generic contact box. It asks for the operating problem, desired outcome, systems and integrations, data sensitivity, residency need, decision-maker availability, budget band, dedicated urgent-team availability and optional NDA request. Those answers are sent as a readable project brief to the configured contact address only after server-side validation; optional attribution fields are deliberately constrained and normalised.
- 03
Search and answer-engine foundations: canonical metadata, page-level titles and descriptions, robots and sitemap routes, Open Graph image generation, `llms.txt`, organisation and page structured data, internal contextual links, and an IndexNow submission script. The local SEO checker enumerates the intended public routes and checks headings, canonical URLs, schema types, social images, link integrity, crawler-discovery files and a bounded list of one-hop legacy redirects.
Architecture and boundaries
The system and its constraints
- 01
The application is a TypeScript/React Next.js project. Content is held in typed local modules, including the claims register, proof record, product detail, resources and enterprise material. This creates a reviewable source of public statements and reduces the risk that a route quietly diverges from the declared claim boundary.
- 02
The enquiry endpoint runs server-side and accepts JSON only. It bounds request size, rejects cross-site origins, applies a small in-memory per-connection rate limit, uses a honeypot and implausible-timing check, validates inputs with Zod, verifies a Cloudflare Turnstile token on the server, and returns `Cache-Control: no-store` for its responses. Email delivery is through Resend only when the required deployment configuration exists; the fallback is an explicit request to email the monitored address rather than a false success state.
- 03
Turnstile verification checks the configured production hostname and named action, not merely whether the browser supplied a token. The code permits Cloudflare's documented always-pass secret only outside Vercel Production, preventing that local test mechanism from becoming a production bypass. The hostnames, secret and action are deployment configuration, so their real-world effectiveness still depends on the configured Cloudflare and Vercel environment.
Release discipline
What the delivery and QA record can show
- 01
The repository defines `npm run verify` as lint, TypeScript checking, acquisition-contract checking and a production Next.js build. Separate scripts cover a local/public SEO crawl, security-header validation, enquiry-form security validation, content-depth checks and IndexNow submission once the relevant key is configured.
- 02
The SEO gate's route list includes the two work-record URLs and checks them as article pages. It also sets minimum visible-word thresholds by route class, checks canonical consistency and looks for expected schema types. This is release automation for discoverability and markup correctness; it does not establish a Google, Bing or AI-answer ranking.
- 03
The public-site README documents the environment variables and release checks required for production: email delivery, Turnstile, Search Console and Bing ownership, and the operating steps in `SEO-OPERATIONS.md`. That provides an auditable handover path for a future operator rather than relying on undocumented dashboard settings.
Evidence boundary
What this record does not establish
- 01
This work record does not prove search rankings, ad performance, organic traffic, lead volume, response time, client outcomes, security certification, universal legal compliance or a specific live configuration. Those require evidence from the relevant deployed environment and, in several cases, time and independent assessment.
- 02
A valid form submission confirms that the configured endpoint accepted and attempted the mail-delivery route. It is not project acceptance, a quoted commitment or proof that the stated delivery target is feasible. A human assessment still needs to check scope, access, dependencies, decision availability, capacity and budget.
- 03
Structured data, `llms.txt`, metadata and content depth make a site easier for search systems to interpret; they cannot compel indexing, citation, ranking or an accurate AI-generated answer. Public content must continue to be reviewed as products, availability and substantiation change.
Build judgement
Decisions and lessons carried forward
- 01
The significant content decision was to replace broad speed language with a qualifying route. The website captures the conditions that determine whether urgent work is possible instead of asking a buyer to infer them after submitting a vague enquiry. This gives the commercial team a more decision-ready brief and prevents the form itself from becoming an accidental promise.
- 02
The technical decision was to combine client-side usability with server-side controls. Browser validation can guide a prospective buyer, but the endpoint independently checks origin, size, rate, honeypot/timing, Turnstile and the full schema before calling the email provider. The lesson is that a public conversion flow is an abuse and data-handling boundary as well as a design surface.
Inspectable material
Evidence sources used for this record
These are the first-party files and artefacts used to write this public summary. They are recorded here to make the basis of each statement legible; they are not a substitute for a buyer's own project-specific review.
- 01
`techgeekuk-site/README.md` and `package.json`: declared runtime, scripts, environment requirements and release gates.
- 02
`src/app/api/rapid-assessment/route.ts`, `src/lib/rapid-assessment.ts` and `src/lib/turnstile.ts`: inspectable enquiry validation, origin checks, rate limit, Resend hand-off and Turnstile verification behaviour.
- 03
`scripts/check-seo.mjs` and `scripts/check-form-security.mjs`: inspectable route, metadata/schema and non-destructive form-security checks.
- 04
`src/content/proof.ts`, `src/content/product-details.ts`, `CLAIMS-REGISTER.md` and `SEO-OPERATIONS.md`: public-proof boundaries, product wording, claim discipline and documented operating tasks.
- 05
`public/paid-assets/techgeek-product-flow.riv`, `src/components/home/HomeExperience.jsx` and `artifacts/design-qa/`: product-system motion asset, implementation and captured local review material.
Direct answers
Questions about this build record
01Does this record prove that TechGeek ranks for urgent software development?
No. It proves that the source contains discoverability and measurement foundations and checks for them in release automation. Ranking requires live indexation, relevant content, competition, independent signals and time; it must be measured.
02Does the form guarantee a seven-day MVP?
No. The form collects the information needed to assess whether an urgent route is credible. The target remains conditional on scope, feasibility, access, decision speed, capacity and budget, and is confirmed only for a specific engagement.
03What happens when Turnstile or email delivery is unavailable?
The endpoint returns a transparent error and presents the configured fallback email rather than silently accepting the request. The actual production behaviour depends on the configured environment values and the availability of the relevant providers.
A practical next step
Start with the work that needs a decision.
Share the operating problem, the outcome you need, the systems involved and the constraints that matter. We will help establish a credible next route.
Start a conversation