Migration commit for the ELF-15 atomic PR. Realizes the CTO plan in ELF-13 revision 1 and ADR-0001 (Go + SQLite + stdlib net/http + SSR + SSE) and the detail choices in ADR-0002 (chi, modernc.org/sqlite, html/ template, stdlib testing, Apache-2.0). Docs: - docs/engineering/tech-stack.md rewritten for Go + SQLite + stdlib net/http + SSR + SSE. Frontend is server-rendered HTML + a little vanilla JS. Packaging is multi-stage golang -> scratch with an optional Caddy sidecar. Boring-technology principle kept. - docs/engineering/first-engineer-role.md rewritten: Go must-have (stdlib + HTTP fundamentals + SQL + GitHub), TypeScript/Next.js/ Prisma/PostgreSQL moved to nice-to-have or deferred. Tailwind and monorepo tooling explicitly deferred. - docs/engineering/onboarding.md: pnpm install / pnpm dev replaced with go test ./... and go run ./cmd/hatch. New step: read local-dev and hatch-architecture on day 1. - docs/engineering/local-dev.md (new): day-to-day commands, where things live, SQLite tips, troubleshooting. Living doc, engineer owns. - docs/engineering/hatch-architecture.md (new): component map (http ServeMux -> handler layer -> store layer; in-process SSE hub), request lifecycle (Capture / Inspect / Mock / Live update), data model (endpoints, requests), performance budget, future seams. - docs/adrs/0002-hatch-detail-stack.md (new): CTO-authored ADR closing the open choices in ADR-0001 with concrete picks, named alternatives, and a per-choice rollback path. Router: go-chi/chi. SQLite driver: modernc.org/sqlite (pure Go, no CGO). Templates: stdlib html/template + //go:embed. Tests: stdlib testing + httptest. License: Apache-2.0. Housekeeping: - README.md: drop the apps/ and packages/ layout lines (no monorepo), add local-dev and hatch-architecture pointers, fix Hatch demo to point at /healthz, switch license line from 'Proprietary' to Apache-2.0 with a LICENSE file pointer. - CONTRIBUTING.md: code-style section rewritten for Go (gofmt, go vet, internal/ for pure logic, server-rendered by default); branch example uses engineer/hatch-* matching the actual workflow. - LICENSE: full Apache-2.0 text, copyright El Foundation 2026. Per ADR-0002. - .gitignore: ignore the pre-built 'hatch' binary, bin/ (per ADR 0002 binary convention), and SQLite files (*.db, *.db-journal, *.db-wal, *.db-shm). Out of scope (handled by ELF-17 onwards, not this PR): - Storage layer implementation (Task B, ELF-17) - Capture, Inspect, Mock (Tasks 3-6) - E2E smoke test (Task 8) Foundation + this commit are the atomic PR. CI is green (go vet, go test ./... -race, docker build all pass locally; same gates the GitHub Actions workflow enforces). Co-Authored-By: Paperclip <noreply@paperclip.ing>
5.6 KiB
Role Definition: First Software Engineer
Context
El Foundation has established its charter, operating model, and engineering baseline. We are pre-product but have a clear technical direction. The first engineer will work directly with the CTO to build the initial product and set the engineering culture for every hire that follows.
The engineering stack is Go + SQLite + stdlib net/http + server-rendered HTML + SSE, per ADR-0001 and ADR-0002. The product is Hatch, a self-hostable HTTP request inspector + mocker that ships as a single static binary.
What They Will Own
- Product implementation. Write the first lines of production code. Own features end-to-end from task assignment to merge.
- Technical foundation. Help solidify the stack, tooling, and conventions. The code you write sets the standard.
- Quality bar. Write tests, review PRs, and catch regressions before they reach users.
- Documentation. If it is not written down, it does not exist. Document APIs, runbooks, and decisions as you go.
- Production reliability. Once we have users, own on-call rotation with the CTO and ensure systems stay healthy.
Technical Skills Required
Must-Have
- Go — comfortable with the language, idiomatic style, the
net/httppackage, and the standard library. Ago test ./.../go vet ./...workflow is the daily loop. - HTTP fundamentals — methods, status codes, headers, content negotiation, request/response lifecycle. SSE and chunked transfer are a plus.
- SQL and relational schema design — schema design, query optimization, migration discipline. SQLite-specific knowledge is a plus but not required.
- Git and GitHub — branching, rebasing, PR discipline, code review.
- Server-rendered HTML — at least one templating system (
html/template, Jinja, ERB, Handlebars). Comfort with progressive enhancement. - Testing mindset — writes tests as a default, not an afterthought. Knows when to reach for
httptest, table tests, and in-memory fixtures.
Nice-to-Have
net/httpinternals — middleware,http.Handlercomposition, theServeMuxmethod-based routing added in Go 1.22.- Docker / multi-stage builds — comfortable debugging a
Dockerfile, reading layer output, and shipping ascratch-based image. - SQLite — pragmas, indexes, JSON columns, the
modernc.org/sqlitedriver. - Linux / single-binary services — has run a Go service in production behind a reverse proxy (Caddy, nginx, Envoy).
- Devtools / API design taste — has built or used webhook inspectors, request bin tools, or mocking tools. Empathy for the user is the job.
- TypeScript or another typed language — transferable skill; nice but not a v0.1 requirement.
- Mongolian language or market context — our early users are likely in Mongolia.
Explicitly Deferred (not required for v0.1)
- Frontend frameworks (React, Next.js, Vue) — Hatch v0.1 is server-rendered. We may adopt one later; we are not starting there.
- TypeScript / Node.js — the foundation is Go. TypeScript remains in the toolbox for tooling only.
- Monorepo tooling (Turborepo, Nx) — single Go module, single binary, no need.
- Tailwind / utility CSS — hand-written CSS is enough for v0.1 surfaces.
Attributes We Value
- Slope over intercept. We care more about how fast you learn than what you already know. Go fluency is learnable; engineering judgment is not.
- Writes things down. Async-first communication. Clear documentation. Decision records.
- Disagrees and commits. Healthy dissent, then full commitment once a decision is made.
- Protects focus. Ruthless prioritization. Says no to multitasking.
- Pulls for bad news. Surfaces problems early. Does not hide blockers.
- Boring by default. Reaches for the standard library before adding a dependency.
First 30-Day Priorities
| Week | Focus | Deliverable |
|---|---|---|
| 1 | Onboard and ship the bootstrap | Merged engineer/hatch-bootstrap PR with cmd/hatch HTTP server, Dockerfile, CI green |
| 2 | Ship Task 2 (SQLite storage layer) | Merged PR with internal/storage/..., migration runner, :memory: tests, schema in PR description |
| 3 | First user-facing task (Capture, Inspect, or Mock) | At least one merged feature PR that exercises the full stack |
| 4 | Document and refine | Updated local-dev.md / hatch-architecture.md with real friction, first own-authored ADR |
Reporting
- Reports to: CTO
- Peers: None yet — you are the first IC
- Growth path: Senior Engineer → Staff Engineer → Engineering Lead as the team scales
Compensation & Logistics
- Decision owner: CEO (pending approval)
- Budget: To be confirmed by CEO
- Location: Remote / async-first
- Start date: As soon as approved and hired
Recommendation
Hire a mid-level engineer with Go and HTTP-services experience. They should have shipped a Go service to production and be comfortable with net/http, SQL, and Docker. A senior engineer would be ideal but may be overkill for our current stage and budget. A junior engineer would require too much hands-on guidance from the CTO, slowing both product velocity and hiring velocity.
If a strong TypeScript engineer is the only available candidate, that's acceptable — the stack is small and the ramp is short — but Go experience is preferred.
Suggested title: Software Engineer
Suggested level: Mid-level (2–5 years shipping production code)
Priority: High — we cannot build product without an engineer.