The journal
Notes from between the idea and implementation
Writing on cloud architecture, honest cost estimates and the work of turning a rough project description into a plan a team can actually deliver.
What makes a cloud estimate defensible
A useful estimate names its architecture, workload assumptions, region and pricing source. The number matters, but the assumptions make it reviewable.
Reading an architecture diagram like a cost model
Every component implies usage, resilience, data movement or operational work. Cost review starts by reading those implications clearly.
The Statement of Work is the real deliverable
A useful SOW translates architecture into milestones, assumptions, roles and acceptance criteria a delivery team can stand behind.
Multi-cloud without the theatre
Comparing AWS, Azure and GCP is useful exactly twice: at the start, and when something changes. A short method for doing it without turning it into procurement theatre.
How to describe a system before the architecture exists
You do not need perfect requirements to start. You need boundaries, critical flows, constraints and the decisions that are still open.
Staffing a build you have not designed yet
Role mix follows the shape of the work. Databases, integrations, security, deployment and migration each ask for different skills.
Notes on grounding: keeping the model honest
Cross-checking across models, pinning every figure to live provider rates, and refusing to invent a service that does not exist.
The hidden cost of the queue you forgot
Queues are not just plumbing. They define what can wait, what must not be lost and which failures need an operational response.
Nothing filed under that yet. Try another topic.
One useful piece a week
Architecture, cost and delivery writing in your inbox. No product noise, no launch countdowns.