Sep 12, 2024
Why I prefer building in phases (even for small projects)
Phase 1, 2, 3 beats "big bang". Better for budget, clarity, and the sanity of everyone involved.
Even small projects get messy when everything is “must have”. I default to three phases:
- Phase 1 – Must have: the smallest version that delivers the core outcome. It ships fast and is stable enough to use.
- Phase 2 – Nice to have: quality-of-life improvements once Phase 1 is in production and we have feedback.
- Phase 3 – Experiments: ideas we only build if earlier phases show traction.
This reduces stress, keeps budgets in check, and protects scope. It also gives us real usage data before we double down. Most importantly, it sets a rhythm: ship → learn → extend, instead of guess → build → regret.
Related work and writing
Replaced scattered timesheets and manual payroll processes with a single source of truth. Consultants log hours in one system, managers approve in real-time, and exports are audit-ready by default.
Replaced cash handling at the company canteen with NFC tap-to-buy. Employees tap badges, purchases sync to payroll, and the canteen eliminated cash entirely.
How a three-person dev team at a Copenhagen consultancy decided what to build, what to buy, and what to hybridise, and why those decisions weren't really about preferences.
The steps I use to go from a sentence-long idea to a scoped, buildable MVP with realistic trade-offs.