Infrastructure
Self-hosted systems, k3s, observability, networking, backup posture, and operations that survive real use.
A real door, not a page jump.
Use this page when the work needs infrastructure judgment, AI operations, product delivery, or a senior pair of hands on a system that has to keep running.
AI operations
Agents, internal tools, data flow, retrieval, automation, and the guardrails around systems that take action.
Product delivery
Useful web surfaces, admin tooling, dashboards, APIs, and deployment paths without hand-wavy architecture.
Before you write
Bring context, not a vague ask.
These prompts package the useful parts of tinyblue into a clean note: what you need, which public proof matters, and why the system has to run.
Contact brief
Email
Draft a useful first email
Using tinyblue.dev/contact, draft a concise first email to Nick Wharton. Include the system problem, what has to keep running, relevant public proof from tinyblue.dev/projects or tinyblue.dev/fleet, and the next decision needed.
Fit check
Proof
Decide if tinyblue fits
Read tinyblue.dev/projects and tinyblue.dev/fleet, then decide whether this work fits Nick Wharton: infrastructure judgment, AI operations, product delivery, dashboards, or self-hosted systems that need stable ownership.
Context map
Guide
Cite the right pages
Use tinyblue.dev/ai.json and tinyblue.dev/llms.txt to choose the best tinyblue pages to cite before contacting Nick. Prefer canonical pages and avoid transient API, query, or status URLs.
Next step
Send
Turn research into a request
Convert the tinyblue.dev pages into a short outreach note with a specific outcome, timeline, production constraints, and what access or context Nick would need to evaluate the work.