The most dangerous phase of a software project: before your MVP ships
The highest risk point in a software project is the time before real users ever interact with the product.
Read articleDiclode blog
Field notes on building software that ships.
Read some thoughts about delivery, planning, system integrations, and what actually works in real projects.
Featured
Priority reads
APIs should be boring
After integrating with dozens of APIs, the most reliable ones all share the same trait: they are predictable.
Read articleWhy integrations fail in production
Integrations often work perfectly during development. The real problems appear once they begin running in production environments.
Read articleGood systems assume failure
Reliable systems are not built by assuming everything will work. They are built by assuming it won't.
Read articleThe integration tax
Every integration adds permanent complexity to your system. The cost rarely appears when the integration is first built.
Read articleBackground jobs are where distributed systems begin
Background jobs seem simple until retries, ordering, and duplicate processing start to matter.
Read articleIdempotency is one of the most important ideas in distributed systems
Many systems assume operations will run exactly once. Reliable systems assume they might run more than once.
Read articleWhat experienced engineers look for in a system
Experienced engineers tend to evaluate systems differently. They look for signals of reliability, clarity, and operational maturity.
Read articleBoring technology wins in production
The technologies that perform best in production are usually the ones nobody talks about.
Read articleObservability is not just logging
Logs alone rarely explain what is happening in a production system. Observability requires multiple signals.
Read articleAll insights
Further articles
Reliable software is built around recovery
Failures are unavoidable in complex systems. The most reliable systems are designed to recover from them quickly.
Read articleThe systems that last are designed for change
Long-lived software systems succeed not because they avoid change, but because they are designed to accommodate it.
Read articleWhy platform architecture matters earlier than you think
Many products delay thinking about platform architecture until growth appears. By then, changing direction can be expensive.
Read articleEvery integration becomes a dependency
Integrations feel like features when you build them. In reality, they become permanent dependencies.
Read articleThe first question I ask when starting a new project
Before discussing architecture or technology, the most important question in a new project is about the problem being solved.
Read articleThe cost of building before learning
Many teams spend months building features before real users interact with them. That delay often leads to expensive corrections later.
Read articleFeature creep is a product risk
Feature creep is usually treated as a product management problem. In reality it introduces serious engineering and operational risk.
Read articleThe most dangerous database migrations
Database migrations seem routine until they affect production traffic. Some migrations carry far more risk than others.
Read articleSystems drift over time
Long-running systems slowly diverge from their original design. Detecting and correcting that drift is part of maintaining healthy software.
Read articleYour API is a product
Developers experience your platform through its API. That experience deserves the same care as any customer-facing product.
Read articleRetries are a feature, not a fallback
Retries are not an edge case in distributed systems. They are a core part of how reliable systems function.
Read articleThe difference between software that works and software that survives
Software that works in testing is easy to build. Software that survives production is much harder.
Read articleSoftware projects fail slowly
Most software projects don't fail all at once. The warning signs appear months earlier.
Read article