About
Hands-on Architects is the practice of two software architects - Maciej Laskowski and Tomasz Michalak. Fifteen-plus years each, still writing code and reviewing it alongside the engineering teams we work with - and advising the executives and leaders who decide how those teams build and run software.
Why both of us
Most of our work is one engagement with both of us on it. Maciej comes at it from the architecture - what the system should be, which options are real, and what each one costs. Tomek comes at it from production - whether that design survives load, failure, and the team that has to run it once we are gone. Same decision, looked at from two ends.
It is a lean, not a division of labour. We are both architects, we have worked together for years, and either of us can run a review, a workshop, or the call on his own. Whoever is closer to the problem leads; the other one pressure-tests.
Leads with the architecture: the shape of the system, the options worth having, and what each one costs before anyone commits to it. Works at both ends of AI — AI in the product, where he took an enterprise AI-agent platform to production and handed it to the client's own team, and AI in the delivery, designing the harness that lets a team build with AI rather than around it. Fifteen years of continuous delivery and cloud-native architecture underneath. Conference speaker.
Leads with production: whether a design holds under real load, real failure, and a team that has to operate it after we leave. Formerly Principal SRE in the engine room of Jira Cloud at Atlassian. Now builds AI agent infrastructure and co-founded an engineering-org AI Guild that sets AI adoption strategy. Designs and reviews systems with TDD and DDD, and turns engineering complexity into trade-offs and goals. Conference speaker.
The pair is the point. An architecture decision nobody has argued with the person who will have to operate it is not finished yet. We would rather have that argument between the two of us, out loud and in front of you, than leave it for your team to discover in an incident.
How we work
Small, task-based engagements
Architecture decisions and reviews, SDLC and delivery-process design, team and role structure, and helping teams adopt AI in a way they own rather than rent. No full-time roles, no slow-moving, low-autonomy work.
In the open
The blog is the practice, not the pitch: the Harness Model as we build it, and the architecture craft behind it. We would rather show you a real artifact than a slide about one.
One engagement at a time
If either of us is heads-down for a stretch, the other keeps things moving; you're never blocked on a single calendar. We each cap consulting at a fraction of the week around a full-time job, and take on one engagement at a time, plus room for something lighter running alongside it - not a number picked to sound available.
Two invoices, one team
You sign one engagement agreement covering both of us. Each of us invoices through our own registered company, so you'll get two invoices for one team.
No conflict with our day jobs
Client work here doesn't touch what our day jobs cover. We structure every engagement that way on purpose, and keep both of us involved throughout.
Let's talk
Tell us what you're deciding - an architecture call, a review, a delivery-process or AI-adoption question - and we'll tell you plainly whether we're the right fit. You'll be talking directly with the two of us, not a sales team, and we reply within 2 business days.