Files
mintel.me/apps/web/plans/freelance-relaunch.md
T
mmintelandClaude Opus 5.5 75993100fa feat: German as the main language, English under /en, with a language switch
The site now exists in German (at the root, with /impressum and /datenschutz)
and English (/en). A request without a language follows the visitor's choice
from the language switch, then the browser language, then German; the old
English legal addresses move to /en for good.

All visible texts are data in src/content/de.ts and en.ts, so components hold
none of their own. The header carries a DE/EN switch whose bit curtain covers
the page while it is swapped and reopens at the same reading position. Title,
description, canonical, hreflang, Open Graph, the share image, the sitemap and
the structured data are per language. The privacy notice now describes the
cookie that remembers the chosen language.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 13:07:22 +02:00

9.5 KiB

mintel.me relaunch concept: freelance engineer site

Scope: this website only. Goal: a visitor understands what I sell within 10 seconds and books a 20-minute intro call within 2 minutes. Low sales overhead, more bookable hours.

1. Positioning

The senior developer who builds web apps and websites that keep working.

"Senior developer for web apps, interfaces and websites. You talk to me directly, you see progress every week, and what I build holds up when it grows."

Copy rules for everything a client can read (owner decision)

  • Never mention AI as my own tool. How I work is none of the client's business: no "AI-built", "AI-accelerated", "AI-code rescue", no FAQ about AI tools. The one exception is the automation service, where AI steps are part of what the client gets (sorting, summarising, reading documents).
  • Modest and factual. No promises I have not made (response times, weekly updates, start dates, search ranking). Only state what the owner confirmed. No superlatives.
  • No internal method vocabulary on client-facing pages: no specs, TDD, mutation testing, coverage, pull requests. Translate into what the client gets: changes do not break things, a written update every week, predictable cost. Technical detail belongs on /process and /notes, for engineers.
  • Do not say: "everything", "fullstack for anyone", "vibe coding". No location or tax talk; say "remote, available during European business hours".
  • Pick the visitor up: introduce me first, then let them choose their need (developer for a product, make an app reliable, just a website), then explain for that need what they get, how it runs, what it costs.
  • Language (owner decision, 2026-10-04): German is the main language at the root, English lives under /en. The language is detected from the browser and can be switched in the header.

Audiences (priority order)

  1. Startups and founders (DACH/EU) who built with AI and now need it stable and extended.
  2. Agencies with overflow capacity (recurring blocks; my team-lead and agency background is the argument).
  3. Web3 teams (frontends, dashboards, wallet flows, WebSockets).

What I offer / do not offer

  • Offer: websites and web apps (Next.js/TypeScript, strong design), light backend (APIs, auth, integrations), CLI tools and automation, AI agents/MCP servers, architecture and code review, the spec/test/mutation process for teams, Web3 frontends. macOS apps on request only.
  • Do not offer (state it plainly): Windows apps, mobile apps, running client infrastructure, database-heavy work, email/DNS administration.

2. Differentiator: verified AI speed

Anyone can generate code. The scarce thing is code that survives production. Spec first -> red -> green -> refactor -> mutation check on changed code -> coverage as gap finder -> a delivery report with exact commands and results on every PR.

Site treatment:

  • "How I ship" on the homepage plus /process with one real example report ("N cases, N mutants caught, changed lines X%").
  • A downloadable sample delivery report.
  • Evidence uses measured numbers only. Never claim: "100% coverage" (flash-loans measures 87.5%), "property-tested" (none found), or mutation scores that have not been run in full.

3. Site structure (owner decision: one page)

Everything is on the homepage. The header has the logo and one button ("Get in touch") that jumps to the contact section. Contact is the address hello@mintel.me: the owner rejected a calendar integration as unnecessary. No /about, /process, /notes or /book.

  1. Hero: headline "WEB APPS / & WEBSITES." (says what I do; "Ship fast. Break nothing." was rejected as unclear), availability, one button.
  2. Hello: portrait fading out of a dark surface with the introduction set over it, then the career line.
  3. Services, four typical cases: developer for a product, make an app reliable, automate a process, just a website. Each case explains what you get, how it runs (four steps with an animated drawing each), what it costs.
  4. Technology: which projects I am right for (good fit / also possible / not my field), what I work with, and an illustrated explanation of why I test my work (no code).
  5. Working with me: one contact (diagram) and four plain principles.
  6. My work: live previews of klz-cables.com and e-tib.com (both cleared by the owner).
  7. Questions, then the closing call to action.

The old site (/blog, /case-studies, /contact, /websites, /technologies, /tags) is deleted, together with its content, tooling and the code only it used. Its URLs redirect to /. Legal pages: /imprint and /privacy (owner details taken from the old terms document; the privacy text is a draft from what the code actually processes and has not been checked by a lawyer).

4. Design

  • Light, the original look of the site: white, oversized type, binary texture, one accent (the yellow marker).
  • The hero headline is built from running binary digits ("SHIP FAST. / BREAK NOTHING."). The owner approved it: do not change the hero design.
  • One left axis for logo, navigation and content. No sidebars. Few sections, each with one job.
  • Availability line fed by one constant, shown in the hero, the sticky booking bar and the closing section.

5. Offers and pricing

Pricing per case (owner decision: hour packages like 15 vs 20 h are meaningless to buyers)

Case Model Shown on the site
Developer for a product By effort, on agreed days per week 100 EUR/hour, 800 EUR/day, net; two weeks notice to month end
Make an app reliable Fixed week 3,500 EUR for 35 hours (derived from the rate, not yet confirmed)
Automate a process Estimate, then a budget 100 EUR/hour; no price before the process has been seen
Website Estimate, then a budget (contingent) from 3,800 EUR; extras at 100 EUR/hour; monthly fee for hosting agreed up front (no amount yet)

The hourly rate is public now. Rate: 100 EUR/h. DACH freelancer average is about 103 EUR/h (freelancermap Freelancer-Kompass 2026).

Entry offer: make an app reliable (1 week, 35 h; internal name "rescue")

Audit of an AI-built codebase, test foundation, mutation baseline, prioritized report. Easy to buy, converts into a block.

Website sprint plus subscription (for clients who want zero involvement)

  • Sprint: time-boxed package (example 40 h, 3,800 EUR) with a clear scope list. Extra work is a follow-up block, not open scope. 50% at start, 50% at launch.
  • Site: static Next.js, no CMS, no server, no database.
  • Hosting: managed platform (Cloudflare Pages or Vercel) in my account, flat monthly subscription (example 49-99 EUR) including hosting, SSL, domain renewal at cost, 1 h of changes per month. Deployment: git push builds automatically, client approves via a preview URL by email.
  • Changes: by email or message, no CMS training.
  • Domain: client is the registrant; transfer-out and source handover on request.
  • Email and DNS are out of scope. Never switch nameservers. Only the two records A/CNAME for apex and www are changed, after exporting the existing records, and mail delivery is checked afterwards. Mailboxes stay with the client's provider.
  • No SLA, no on-call; changes within 2 business days. Cap the number of subscription clients (for example 10) to protect bookable hours.
  • Open decision: offer the subscription, or only handover plus 14 days of bug fixes.

6. Getting clients (low effort first)

  1. Own network: former colleagues from i22, Trusted Shops, sdox.io, Sevenval. Ten personal messages.
  2. LinkedIn and X: one post a week from real work (process, numbers, diagrams), one pinned "next free block" post.
  3. Platforms (freelancermap, freelance.de, Web3 job boards) as a secondary channel.
  4. Direct outreach: 10 targeted messages a week with one template.
  5. Testimonials: one line each from existing clients.

7. Proof usable on the site (measured facts only)

  • Liquidation system: 7 chains, Rust plus Solidity, 1,339 commits since 2026-09-16, 6,365 test markers, mutation gate with zero-survivor policy, coverage ratchet (badge 87.5%). Revenue to date is 0 EUR; show engineering and architecture only, no profit claims, no strategy details.
  • Trading engine: spec-first structure, functional-style gates with self-test.
  • Live references: klz-cables.com, e-tib.com.
  • Still to measure before quoting: full mutation run and real coverage on the main system.

8. Risks for the site itself

  • This repo currently has no tests and tracked tmp/log files in the root. The rigor pitch needs a tested site: spec tests for availability logic, booking flow and redirects, plus a CI gate.
  • Impressum needs a serviceable address (DDG section 5); settle it with a tax advisor. Do not publish tax, visa or payment-provider details.
  • Scheinselbststaendigkeit: prefer 15-20 h blocks over one client at 35-40 h.

9. Implementation order

  1. Cal.com event and /book.
  2. Spec tests for availability and redirects, then new hero, nav and offers; remove old SMB sections.
  3. /process with the sample report.
  4. First two notes with diagrams.
  5. English copy pass, then /de; SEO/OG basics; redirect /websites to /.