"Do you write code, or only advise?"

"I build the first thin end-to-end release myself, then the whole team builds from there, and we all direct coding agents — hand-written code is the exception. The skill worth paying for is knowing what to give the agents and how to assess what they produce — thirty-five years of shipping software across Go, C#, TypeScript and Python is what makes those judgements good."

"What does a typical engagement look like?"

"Most start with a short architecture review: I read the system, talk to the people who run it, and come back with a written assessment of what the system has outgrown, and what to change first. That often turns into implementation work, either alongside an existing team or as the whole of it."

"Who do you work with?"

"Engineering leaders and architects, mostly in companies whose systems have outgrown their original design — often legacy platforms that now need to support modern data and AI workloads without a rewrite."

"Are you tied to any vendor or platform?"

"I resell nothing and take no referral fees. Recent work has been on Microsoft Azure, and the design goal is to keep a change of vendor affordable."

"Is it safe to let AI write production code?"

"It depends entirely on who is directing and reviewing it. Agents are fast and confident, and confidently wrong in ways that pass a casual read. The discipline that makes them safe is the discipline software has always needed: knowing what the system must do, deciding what the agents work from, and reviewing their output against that."

When the system has outgrown its design.

Robert Reppel · principal engineer and architect · Vancouver

Contextualized Systems is an independent architecture practice in Vancouver. I design systems — event-driven architecture, open data platforms, governed agentic AI — and I direct the coding agents that implement them. The judgement is what I bring, alongside your team: what the agents work from, and whether the result is right. You work directly with me.

Thirty-five years of shipping software·Architect at PayByPhone·CTO & partner at Adaptech Solutions·Co-founder & CTO of TwoTonic Labs

What I get brought in for

Making agent-driven delivery work

Not buying tools — getting real systems built with them. I introduced coding agents to a client's engineering team and drove the adoption: agents implementing real systems, with specification, context and review agreed with the team, and management behind it. It worked because the team was brought into the change rather than handed it.
Architecture that has outgrown its design

A system that has grown past its original design: tangled boundaries, one database doing everything, changes that break unrelated things. I map what is actually there, so the first change is the right one — and so the parts that work get left alone.
From legacy platforms to open ones

Proprietary and monolithic stacks to open, vendor-neutral data platforms, including the unglamorous part nobody puts on a slide: total cost of ownership, so the change pays for itself.
Event-driven systems that hold up in production

Event sourcing, CQRS and domain-driven design as working systems rather than as slides. I have been building this way since before it was a conference topic, including tooling that takes a team from an event storming workshop to a running API.

Selected work

In production now client anonymised under NDA

External principal architect, working inside the client's engineering team · Contextualized Systems · 2022 – present

Five production systems for an automotive collision-repair platform.

I began with spikes to retire implementation risk and built the walking skeleton: a thin end-to-end slice across services and products, in production early. The whole team built out from there, so it became our system.
One event-driven design under every system, in production for four years: domain events stored as immutable blobs in Azure Blob Storage, small single-purpose services reacting to them, and a catalogue of event types covering every state change.
An open, vendor-neutral data lakehouse on Azure Blob Storage with per-tenant isolation and time-bound, securely issued credentials.
The design has carried change underneath it: the first services run as Azure Function Apps, the newest as Azure Container Apps on consumption plans; first-generation .NET services work alongside newer Python ones, and existing services are reused in new products. Hosting, language and storage are chosen per service from its SLAs, its cost, and how hard the choice would be to reverse.
The agentic layer: Python FastMCP servers, OAuth 2.0 / PKCE-secured agent gateways through Azure API Management, and Docker-sandboxed agent orchestration.
Analytics stores subscribe to the same events, so they can change without touching the products; an Azure Fabric data warehouse is in production alongside the five systems.
Three of the five systems were delivered with coding agents doing the implementation. The other two predate agentic coding, though all their recent maintenance and enhancements go through agents. I brought coding agents into the client's engineering team and drove the adoption, and the whole team now directs agents: hand-written code is the exception, with major productivity gains and a great deal learned along the way. We agree the specification and context together, and review what the agents produce against the event catalogue.

Built as products, sold to paying customers TwoTonic Labs, 2018 – 2021

Co-founder & CTO · a two-person partnership — I owned everything technical

StoryStream — a real-time collaborative event-storming editor. A purpose-built text DSL that renders live as a colour-coded domain model, Firepad-over-Firebase co-editing through shareable links, PNG export, role-based access, and Stripe subscription billing. About 1,300 commits over three years, front end to cloud functions.
Pomodus — a focus timer wired into Slack: cloud functions set and clear a user's status and do-not-disturb at each cycle boundary, turning a private timer into a team-visible signal. Free and paid tiers, Stripe checkout and webhooks, and a usage-analytics pipeline syncing Firestore into Elasticsearch.
An internal modelling toolchain — an event-storming DSL that generates a working CQRS/event-sourced API, a drag-and-drop tool for deciding where one microservice ends and the next begins, and a Go service that turns an event storming into a normalised model and generates component and sequence diagrams on demand.
The platform underneath — an event-logging service on Kubernetes with PostgreSQL, and Kubernetes and AWS infrastructure provisioned as code with Terraform.

StoryStream and Pomodus shipped as real products with billing. The modelling toolchain stayed internal research and is described here as tooling, not as delivered client work.

Open source and published work

les — go directly from an event storming to a working API, via Event Markdown validation and code generation. Go.
letseventsource / LESTER — the specification-to-API stack that grew out of the same practice.
kubel — a domain-driven-design modelling tool for finding where one microservice should end and the next begin.
eventsourcing-hotelreservations — a hotel-reservations API with CQRS and event sourcing. C#.
hist — a small event store for event sourcing, in Go.
docker-eventstore-cluster — three replicating EventStore nodes, and the Kubernetes equivalent.

Talks: Legacy Code: Using Domain-Driven Design to Carve Out Areas of Sanity (InfoQ, 2013) and Log Aggregation In 10 Minutes Flat (NDC Oslo, 2013).

Other things I build not the business

language-tape — a language-learning app. In development.
historywalker — a location-based storytelling app that surfaces the history around you. In development.
DailyLimerick — a daily limerick, published.

Approach

One person, no layers: Contextualized Systems is me — Robert Reppel — there is no account manager and nobody between you and the person doing the work. On an engagement I work inside your team — the architecture decisions get made with your engineers in the room, rather than handing over documents and leaving.
Nothing should depend on me permanently: One person is a fair thing to ask about. The answer is in how the work is structured: I start with spikes and a small end-to-end release in production, then the whole team builds from there, so the people who will live with the system have built it with me from early on. At any point you should have something your own engineers already run — not a half-finished thing that only makes sense to me.
We all direct the agents, and I am accountable for the result: Coding agents do most of the typing now, and the whole team works this way — I drove that change at my client, and adoption was swift and management-backed. What I bring is the judgement: agreeing with the team what the agents work from, and assessing whether what comes back is right. Thirty-five years of shipping software is what makes both of those judgements good.
I start it, then we build it together: I do the spikes and build a thin end-to-end first release into production myself, which retires the risky unknowns and sharpens the estimates. Then the whole team builds from there, together: your team's to own and build on, and the aim is that everyone can say “we built this” — fit for its purpose, simple, maintainable, and something to be proud of. That is how I worked long before AI, and it is how the agents get used now.
The team has to be in on it: Adoption fails when the people who have to live with a change feel threatened by it. I introduce change with the team rather than to them — support from management without acceptance inside the team produces compliance, and compliance does not deliver.
Vendor-neutral, because I sell nothing else: I do not resell platforms and take no referral fees. When I recommend the smaller, cheaper option, nothing is pushing me the other way.
Often the answer is not to build it: The most useful thing an architect can say is often "you do not need this". More often than not, the recommendation is smaller than the request. What I recommend depends on your situation, so I look before I recommend.

Questions

Do you write code, or only advise?: I build the first thin end-to-end release myself, then the whole team builds from there, and we all direct coding agents — hand-written code is the exception. The skill worth paying for is knowing what to give the agents and how to assess what they produce — thirty-five years of shipping software across Go, C#, TypeScript and Python is what makes those judgements good.
What does a typical engagement look like?: Most start with a short architecture review: I read the system, talk to the people who run it, and come back with a written assessment of what the system has outgrown, and what to change first. That often turns into implementation work, either alongside an existing team or as the whole of it.
Who do you work with?: Engineering leaders and architects, mostly in companies whose systems have outgrown their original design — often legacy platforms that now need to support modern data and AI workloads without a rewrite.
Are you tied to any vendor or platform?: I resell nothing and take no referral fees. Recent work has been on Microsoft Azure, and the design goal is to keep a change of vendor affordable.
Is it safe to let AI write production code?: It depends entirely on who is directing and reviewing it. Agents are fast and confident, and confidently wrong in ways that pass a casual read. The discipline that makes them safe is the discipline software has always needed: knowing what the system must do, deciding what the agents work from, and reviewing their output against that.

Background

2021 – present Principal engineer and architect, Contextualized Systems Inc. — Robert Reppel, Vancouver
2018 – 2021 Co-founder & CTO, TwoTonic Labs — an independent product lab
2016 – 2018 CTO & partner, Adaptech Solutions — event-sourced microservices practice; built LES / LESTER
2012 – 2016 Senior solutions architect, PayByPhone — architectural ownership of the parking platform and its move to event-driven, cloud-hosted services
1990 – 2012 Architecture and engineering roles at Move Inc., Forbridge, Visiphor, Pearson Education, Top Producer Systems, Burntsand Solutions and others

Contact

If the system has outgrown its design — or you want more of it delivered by agents — tell me what you are working on. I have built these systems.

Robert Reppel
robert@contextualized.systems
LinkedIn · GitHub