Software architecture, with the people left in.
I'm Bartosz Frąckowiak. For twelve-plus years I've been building distributed systems in production, and studying the humans and org charts that shape them. I write about both here, most Mondays, because thinking in public is how I find out whether an idea holds.
This page is the short version of how I got here. The long version is the essays.
12+ years in distributed systems PhD research, University of Warsaw Top 3% on Toptal Architect at a global SaaS platform
From proving architectures to shipping them, and now teaching machines to help.
I started by trying to formalize architecture in a PhD, learned in production why people bend every formal model, and now lead an AI transformation across hundreds of engineers. The essays linked below are the receipts from each stage.
-
2008–2013 Toruń
Computer science, then the production shock
University taught elegant models. Production taught their price. A CS degree in Toruń, the first .NET jobs, the first incident, and the lasting discovery that no theory survives deployment unchanged.
.NETfirst production systems -
2013–2017 University of Warsaw 4 yrsdoctoral research
Doctoral research: can architecture be proven?
Built a formal language for validating software architecture. The honest result: boxes and arrows can be formalized, and the forces that bend them are organizational. That tension powers every essay on this site.
formal methodsarchitecture validation -
2015–2017 Cybercom
Consulting years
Every engagement was two systems: the codebase, and the organization around it. Senior consultant and team leader across client projects and offshore teams. The second system was never in the repository, and usually mattered more.
consultingteam leadershipoffshore delivery -
2017–2022 Global SaaS platform 15-yrmonolith moved
Technical Leader: a fifteen-year monolith, moved
Led a 15-year legacy monolith toward microservices. CI/CD where there was none, domain-driven design as the shared language, repositories that merged themselves, and the hard conversations no diagram captures. Also the era that taught me "technical leader" is two jobs wearing one badge.
legacy migrationdomain-driven designCI/CDmicroservicesField notes from this era Technical Leader: Identity Disorder The Automerger Stop Calling It Legacy Code -
2022–today Global SaaS platform 20+bounded contexts
Solution Architect / Senior Staff Engineer
Architecture across 20+ bounded contexts on an event-driven Azure platform. Decision records, governance, integration design, and the discovery that most architecture work is deciding who decides. The sharpest tool at this altitude is a well-aimed question, not a diagram.
event-drivenAzureADRs & governanceField notes from this era Decisions Have an Architecture Too Nobody Owns the Sum Questions Are an Architect's Sharpest Tool -
2025–today Global SaaS platform 15squads, AI-native
Leading an AI transformation at scale
AI-native engineering across fifteen squads and several hundred developers. An agentic tech radar that turns signals into decisions, probabilistic metrics for work no database records, and a prompt-driven architecture practice. This blog exists because that work keeps producing field notes worth publishing.
Claude Codeagentic tech radarprobabilistic metricsField notes from this era From Signals to Blips Probabilistic Metrics Prompt-Driven Architecture Multi-Agent Is an Org Chart -
nights & weekends own products ×3shipped solo
Building my own products
Three products, one person, all in production. An invoicing SaaS wrestling the government e-invoicing spec and its parliament-written edge cases, an architecture-modeling tool where the diagram cannot lie because it is the code, and a self-hosted scheduler in Go. Proof of shipping, and an endless source of material.
SaaSGoproduct designField notes from this era A Company of One, Staffed by Agents The Diagram That Cannot Lie Edge Cases Written by Parliament Anti-Personas
"To be the architect who connects classic distributed-systems discipline with an AI-native way of working, and to show, in public, one essay a week, how systems and the people who build them actually behave."
Say hello, or argue with an essay.
I answer everything within two business days, and disagreements are the most interesting mail I get.
- LinkedIn /in/bartoszfrackowiak ↗
- M Medium @bfrackowiak ↗
- GitHub /batas2 ↗
- Newsletter one essay, most Mondays
What I do in daylight. Architecture consulting, and training on domain-driven design, event-driven systems, and the AI workflows I write about here. It is the same material, in a room, with your systems on the whiteboard instead of mine. The detail is here if you need it.