Startup Architecture – How much “it depends”?
summary
Experience moving from a large retailer to a one‑person healthcare startup drives practical rules: model by domains early, deploy each domain behind a unified API (GraphQL federation or similar), treat one service ≈ one domain where possible, and accept messy internals as long as interfaces are stable. Measure user flows and feature adoption, track technical debt via visible TODOs or code metrics, ship continuously, and when a prototype becomes core refactor to standard, make technical debt visible, prioritize core domains.
AI-written summary · about
chapters (23)
- 0:00Intro
- 0:50Background
- 1:44Agenda
- 2:28Corporations
- 4:54Enterprise Architecture
- 6:21Architecture for Startups
- 7:22Build with Components
- 7:51Flexibility
- 8:52Domain Driven Design
- 12:48Messy Domains
- 14:08Onboarding Example
- 15:17Therapy Plan Example
- 16:06Reminders Example
- 17:20Technical Debt
- 19:22Deployment
- 20:44Dont Repeat Yourself
- 22:26Take a Step Back
- 23:08Domain Splitting
- 24:04Prototyping
- 25:25Architecture
- 27:39Questions
- 34:09Prototypes
- 36:41API Layer
related talks
39mMinimal Viable Architecture
46mDigital scale-up architectural patterns
24mFrom Startup to Scale Up Designing for Growth from Day One
27mArchitecting for Change Debate
43mThe Clean Architecture: How to Grow From Startup to Enterprise
25mThinking Architecturally
46mEvolutionary Architecture: The What. The Why. The How.
54mSoftware and architecture quality in a startup