Notes on building software that ships
What we've learned building products with founders and teams — scoping, shipping, scaling, and the decisions that matter most.
The features you cut matter more than the ones you ship
Every MVP conversation starts with a feature list that is too long. Here's how we decide what actually makes version one.
Read the post →AI made building fast. It did not make building safe.
Generated code that demos beautifully and fails in production is now the most common way software projects go wrong. The fix is not less AI — it is direction.
Read the post →Rebuild or refactor? Four questions that settle it
Teams inherit a codebase they did not write and immediately want to start over. Sometimes that is right. Usually it is not.
Read the post →Why we will not quote a build without a discovery sprint
A fixed quote from a vague brief is a guess wearing a suit. One week of structured work makes it a real number.
Read the post →How to run a build you don’t have the skills to audit
You do not need to read code to tell whether a software project is going well. You need the right four signals.
Read the post →What “built to scale” should actually mean at ten users
Scalability is not about handling traffic you do not have. It is about not having to start over when you do.
Read the post →