Specs clarify the work. TDK makes it run.
Field notes for teams building service-heavy products without turning every developer into a platform engineer.
Start with the argument
Three essays on the distance between written intent and a system developers can trust.
Choose a way in
The library is broad. These reading paths group the questions teams usually meet together.
Read for the problem in front of you.
One hundred practical notes on specs, local development, platform work, testing, security, and the systems between them.
The Spec Is the Map, Not the Terrain
How teams can use specs to reduce ambiguity without confusing written intent for production behavior.
When Specs Lie Quietly
A practical look at stale assumptions, missing edge cases, and the false comfort of tidy requirements.
What SDD Gets Right
The useful parts of spec-driven development: shared language, reviewable intent, and better AI handoffs.
What SDD Cannot Do
Why specs cannot replace product judgment, architecture tradeoffs, operational feedback, or integration testing.
From Product Intent to Runnable Services
How TDK turns service definitions into local systems developers can actually inspect and run.
Why Local Feedback Still Wins
The case for fast local loops even when cloud development environments look convenient on paper.
No Kubernetes Before Lunch
Why TDK keeps developers productive without asking every product engineer to become a cluster operator.
The Cost of Setup Rituals
How repeated onboarding chores quietly consume product time and make teams afraid to change services.
Day-One Onboarding for Microservices
What it should feel like when a new developer joins a service-heavy product team.
Why Generated Docs Beat Forgotten Docs
How generated C4 diagrams and assistant briefings keep documentation closer to the live system.
The Best Docs Are Rebuilt
Why documentation that regenerates from service definitions is easier to trust than a wiki page.
AI Assistants Need Topology
Why coding assistants behave better when they understand services, boundaries, generated files, and ownership.
Stop Asking AI to Guess Your Architecture
How TDK gives assistants concrete context before they suggest changes in the wrong layer.
The AGENTS.md Advantage
A practical guide to generated assistant briefings and why they matter in larger repos.
Service Definitions as Team Contracts
How one service.json can make runtime expectations visible across product and platform work.
The Local Stack as a Product Surface
Why internal developer experience deserves the same care as user-facing workflows.
Microservices Without Local Theater
How to tell the difference between a useful local stack and a fragile demo.
The Laptop Should Tell the Truth
Why local environments should reveal integration problems early instead of hiding them until CI.
Plain Docker Is Still a Feature
Why standard generated Docker files are easier to inspect, debug, and keep than opaque platform magic.
Tilt Without the Cluster Tax
How TDK uses Tilt and Starlark for local orchestration without forcing Kubernetes concepts into every task.
Starlark for Repeatable Local Rules
Why small deterministic orchestration rules can beat a pile of custom shell scripts.
Golden Layers for Boring Builds
How shared Docker layers can make generated services faster and easier to reason about.
Hot Reload Is a Trust Feature
Why developers keep using local tools only when feedback feels immediate and reliable.
Selective Startup for Big Repos
How teams can work on one slice of a system without booting every service every time.
The Hidden Price of Cloud Workspaces
Why rented developer environments can solve setup while introducing spend, latency, and governance questions.
When Cloud Development Makes Sense
A fair look at where cloud workspaces help and where local tooling remains simpler.
Why TDK Is Not a Cloud IDE
The difference between renting a remote machine and generating a better local development surface.
Standard Files Beat Platform Lock-In
Why teams should keep generated output they can read, edit, commit, and carry forward.
MIT License as Product Philosophy
Why open licensing matters when a tool sits in the middle of daily engineering work.
Secrets Are Not Onboarding Steps
How managed identities reduce the habit of copying credentials through unsafe channels.
Local Credentials Without Spreadsheets
Why developer secrets need managed paths, not tribal knowledge and old setup docs.
The Service Registry as Shared Memory
How a service registry helps teams understand what exists, where it runs, and how it connects.
C4 Diagrams That Do Not Rot
Why architecture diagrams should be generated from the system instead of redrawn after the fact.
The Brownfield Rescue Path
How existing repos can be discovered and gradually shaped into explicit service definitions.
Do Not Rewrite Before You Understand
Why brownfield modernization starts with discovery, not a heroic platform replacement.
A Better First Week for Founding Engineers
How early teams can avoid building local infrastructure from scratch before the product is proven.
MVP Speed Without Throwaway Tooling
Why fast early product work still deserves a local stack that can survive growth.
The Founder Case for TDK
How TDK reduces setup drag so tiny teams spend more time on customer-facing decisions.
The Platform Engineer Case for TDK
Why platform teams should automate local development instead of becoming laptop support.
The Product Engineer Case for TDK
How product developers can ship across services without memorizing infrastructure internals.
The DevOps Case for TDK
How generated local environments keep platform attention closer to production reliability.
The AI Code Review Context Problem
Why reviewers and assistants both need a map of generated files and service boundaries.
Generated Clients Without Guesswork
How generated SDK and client surfaces reduce drift between frontend and backend work.
Why One Manifest Matters
The benefits of giving each service one explicit source for local development intent.
The Discipline of Boring Defaults
Why teams move faster when generated defaults are predictable, readable, and unexciting.
The Difference Between Simple and Simplistic
How TDK tries to reduce local complexity without pretending distributed systems are easy.
Microservice Sprawl Needs a Workbench
Why service count becomes manageable only when developers have a coherent local surface.
The Real Meaning of Reproducible
What reproducibility should mean for service discovery, ports, credentials, generated files, and startup.
Ports Should Not Be Folklore
Why local port assignment belongs in generated configuration instead of memory and Slack.
Queues Belong in the Local Story
Why background work and messaging need first-class local support, not production-only mystery.
Databases Are Part of the App
How local database setup, migrations, and service ownership shape daily developer confidence.
Prisma in a Generated Stack
Where ORM setup fits when service definitions generate development infrastructure.
Playwright Belongs Near the Stack
Why end-to-end testing is more useful when the local system is easy to boot and reset.
Testing the System You Actually Run
How local orchestration can make tests reflect real service relationships instead of isolated assumptions.
The Fast Path to a Useful Demo
Why a runnable multi-service demo beats screenshots when teams need product feedback.
Documentation for Humans and Assistants
Why modern engineering docs need to serve both people reading and agents acting.
The Problem With Perfect Templates
Why templates help only when they keep matching the system after the first generation.
Code Generation That Stays Inspectable
How generated files can help teams without becoming an opaque maintenance burden.
How to Review Generated Infrastructure
A guide to inspecting generated Docker, Tilt, TypeScript, and config outputs with confidence.
Why TDK Does Not Hide the Stack
TDK exposes standard tools because hiding every detail makes teams weaker when debugging starts.
The Local System Is a Contract
Why every service should declare how it runs, connects, and participates in the development loop.
From Empty Repo to Working Landscape
How a service landscape forms when definitions, generated artifacts, and local orchestration line up.
The End of Setup Archaeology
Why developers should not have to reconstruct old setup decisions from scripts and memories.
A Smaller Surface for Mistakes
How generated conventions reduce the number of places local setup can quietly drift.
Local First Does Not Mean Local Only
Why strong local development complements CI, staging, and production instead of replacing them.
What Belongs in CI After TDK
How local reproducibility changes what teams expect from continuous integration.
When the Stack Should Say No
Why good local tooling should fail early, explain clearly, and avoid partial mystery states.
tdk doctor as Team Memory
How health checks can replace long troubleshooting threads with actionable local diagnostics.
The CLI as a Calm Interface
Why a development CLI should guide without burying engineers under flags and hidden states.
Terminal UI for Real Work
How a focused terminal interface can make a complex service landscape easier to scan.
Why Local Dev Needs Product Design
Internal tools still have users, workflows, friction, and moments where clarity matters.
The Practical Beauty of One Command
Why one reliable command can be more valuable than a thick setup guide.
The Problem With Works on My Machine
How reproducible generated environments remove a phrase teams should not need anymore.
New Hire Confidence Is a Feature
Why the first successful local boot shapes how quickly people feel useful.
The Quiet ROI of Fewer Interruptions
How reducing setup questions and environment drift returns attention to product work.
Counting the Cost of Waiting
Why blocked developers are expensive even before a team buys any extra infrastructure.
Local Tooling and Team Morale
Why reliable development environments make engineers more willing to touch unfamiliar services.
Why Big Repos Need Small Rituals
How simple repeated commands can hold a large service graph together.
The Difference Between Demo and Daily Driver
What separates a local stack that impresses once from one developers trust every day.
Observability Starts on the Laptop
Why logs, status, health, and service relationships should be visible before staging.
Generated Does Not Mean Disposable
How generated artifacts can become stable, reviewable parts of the engineering system.
Owning the Output
Why teams should be able to keep every generated file if they outgrow the generator.
The Escape Hatch Is the Product
How no-lock-in design makes a developer tool safer to adopt.
From Ticket to Topology
How assistants can work better when user stories connect to actual services and generated context.
Why AI Needs Guardrails, Not Theater
The practical role of generated boundaries, ownership notes, and service maps in AI-assisted coding.
Making Brownfield Code Legible
How discovery can reveal hidden services, missing manifests, and patterns worth preserving.
Gradual Adoption Without Drama
How teams can bring TDK into an existing repo without stopping product work.
The First Manifest to Write
Where to start when turning an existing service into an explicit TDK service definition.
A Local Registry for Real Teams
Why internal packages and generated clients benefit from a local registry during development.
The Case for Verdaccio
How a local package registry supports service-heavy TypeScript development.
Frontend and Backend in One Loop
Why product work moves faster when UI, API, and generated clients update together.
Vite Everywhere It Helps
How consistent Vite usage can make frontend, backend, SDK, and library workflows easier to reason about.
Bun, Node, and Practical Defaults
How runtime choices should serve developer feedback instead of becoming identity debates.
The Local Gateway Pattern
Why gateways, nginx, and routing deserve generated support in local service landscapes.
Traefik Without Mystery
How generated routing config can make local service URLs predictable.
NATS in the Development Loop
Why event-driven services need local messaging support that developers can see and restart.
Postgres as a First-Class Neighbor
How local database services become less painful when they are part of generated orchestration.
Configuration That Explains Itself
Why generated configs should carry enough structure for humans and assistants to understand them.
A Better Default for Service Teams
Why TDK is built for teams that want standard tools, faster feedback, and less local ceremony.
Why TDK Matters After the Spec
A closing argument for pairing spec-driven thinking with a development workbench that can actually run the system.
No articles match that search. Try a broader term or another category.
From the field guide
Make the spec runnable.
See how TDK turns service definitions into local infrastructure your team can inspect and keep.