mintel.me/apps/web/plans/freelance-relaunch.md

mintel.me relaunch concept: freelance engineer site

Scope: this website, plus the videos made from it (apps/video, see section 6). Goal: a visitor understands what I sell within 10 seconds and writes an email within 2 minutes. Low sales overhead, more bookable hours.

Status note: sections 3 to 6 describe the site as built. Sections 2 and 9 are kept as history and are marked as such.

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, predictable cost.
• 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. The videos and their post texts exist in both languages too (apps/video/src/content/videos.ts).

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 (internal, not shown on the site)

This is how the work is done. Under the copy rules above none of it appears in client-facing copy, and the pages named below (/process, the sample report) were not built: the site is one page (section 3).

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 ("WEB APPS / & WEBSITES."). The owner approved the design: do not change it.
• One left axis for logo, navigation and content. No sidebars. Few sections, each with one job.
• No availability line and no booking bar: both were dropped with the calendar. The hero shows two facts instead (15 years in web; remote, EU core hours).
• Dark surfaces carry light: BitAura (light along an edge, digits drifting off it), BitSeam (lit top edge of a dark section) and BitGlow (light following the pointer on data-glow surfaces, including the dark button).

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.
• Care after the launch (owner decision 2026-10-05, replaces the managed-platform idea): one offer, "Betreuung", 89 EUR per month net, cancel monthly. Hosting on the owner's own servers in Germany (EU hosting matters to German clients; no Vercel or Cloudflare), domain, security and updates, and small changes by email (a text, a picture, opening hours; internally about 30 minutes a month). No CMS and no login for the client. The first three months are included in the project price. Anything bigger (a new page, a new feature) gets a price first. Reply within two working days, no on-call. The client can leave and take everything along.
• Larger clients: the same care with all non-editorial changes included, about 250 EUR per month (one existing client pays 3,000 EUR a year). Offered in the quote, not listed on the website.
• CMS only as an exception and at extra cost (file-based first; Payload only when the site lives on maintained data such as a product catalogue).
• Operations: serve client sites as static files from one shared web server, not one container per client.
• Not on the website yet: "green hosting". The owner wants it as an argument; state it only once the provider's proof (renewable energy) is at hand.
• 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 first; plan, rhythm and measures in plans/content-strategy.md. A set of short looping videos, one per service, with post texts in English and German, is produced in apps/video (node scripts/export.ts writes out/library).
3. Google Ads for German clients: search campaigns for "website" and "automation". Concept, ad texts and open prerequisites in plans/google-ads.md.
4. Platforms (freelancermap, freelance.de, Web3 job boards) as a secondary channel.
5. Direct outreach: 10 targeted messages a week with one template.
6. 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 (history: superseded by the one-page site in section 3)

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 /.