How the stack fits together

From request to response, end to end

Imagine a user opening Tasklane in a browser. Watch what happens, and notice every layer:

1. The browser hits a URL. DNS resolves tasklane.com to an IP. The request goes over HTTPS to a CDN edge or Vercel's edge — the closest geographic server.
2. If the request is for a static asset (the homepage, a CSS file), the edge serves it directly from cache. Done in milliseconds.
3. If the request needs computation — say the user clicks "log in" — the edge forwards it to an application server. That server is running Next.js on Node, written in TypeScript.
4. The server checks authentication. Auth.js reads the session cookie, validates the JWT, and looks up the user. The OAuth dance with Google or GitHub happened earlier; what's in the cookie now is the result.
5. The server queries the database. Prisma generates SQL against Postgres. The query plan uses the indexes you set up. The connection comes from a pool. Redis caches the most expensive query results with a 60-second TTL.
6. The server returns HTML or JSON. REST if it's a traditional API; GraphQL if the client asked for a specific shape. The browser receives the response, hydrates the React components, and renders the UI.
7. If anything goes wrong at any of those steps, Sentry captures the exception and your team gets a notification. Datadog or Prometheus records the latency and error rate. Logs go to ELK. If the error is severe, PagerDuty wakes someone up.

From a developer's commit to that running production server

1. An engineer (or AI agent) writes code in Cursor or with Claude Code. Tests pass locally.
2. They push to a feature branch. GitHub Actions (or Jenkins, or GitLab CI) runs lint, typecheck, tests on every push.
3. They open a pull request. The CI also builds a preview deployment at a unique URL — anyone can click and try the change in a real environment.
4. Code review happens. A teammate (or the engineer themselves, with the diff) checks the change. Comments resolve. Approvals collected.
5. Merge to main triggers production deploy. The pipeline builds a Docker image once and promotes it through stages. Or it deploys static output to Cloudflare Pages or Vercel directly.
6. For more sophisticated environments, the deploy goes to Kubernetes via Terraform-managed infrastructure. Secrets come from a secret manager. Deploy strategy might be canary or blue/green.
7. Configuration management with Ansible handles the long tail of VMs and bare metal that don't fit cleanly into containers.
8. The cloud underneath everything is usually AWS (or GCP, or Azure) — even if you never log into the console, your hosted platform is renting from one of them.

Apprentice path · 0 → 100

The apprentice path covers the first six levels and uses a focused subset of this stack: a frontend framework (React or Next.js), TypeScript, Node.js, Postgres via Prisma, Auth.js, deployed to Cloudflare Pages or Vercel, with errors going to Sentry. That's a working modern web app. Most teams ship and grow without ever needing more.

Yardmaster path · 100 → 140

The yardmaster path adds the operations layer: Docker, Kubernetes, Terraform, Ansible, deeper CI/CD with Jenkins, observability with Prometheus and the ELK Stack, and on-call discipline with PagerDuty. This path is necessary when you outgrow managed platforms — for compliance, scale, custom infrastructure, or simply for the engineers who will one day be on-call.

The mental model

Pick a tab. Each tech page leads with its own focused mindmap — what it depends on, what it competes with, what builds on it, and where in Shipyard it shows up. The pages are designed to be read in any order.

The Overall mindmap above (the one on this page) is the bird's-eye view: every technology, grouped by category. Click any node to jump straight into that tech's page.