Solution Architect · Warsaw, Poland

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

Bartosz Frąckowiak
B. Frąckowiaksolution architect
The journey

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.

  1. 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
  2. 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
  3. 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
  4. 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/CDmicroservices
  5. 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 & governance
  6. 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 metrics
  7. 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 design
The goal

"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."

— where all of this is heading
Contact

Say hello, or argue with an essay.

I answer everything within two business days, and disagreements are the most interesting mail I get.

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.

Send me a message