From company goals to reliable systems.
Architecture, consulting, and product engineering. Hands-on, directly in your codebase, translating company goals and OKRs into reliable systems.
Fullstack Product Engineering
“Software development is more than routine ticket-taking and writing code. It takes creative thinking to solve the right problem, systems thinking to make it hold up, and business thinking to understand how every decision affects the company”
Most features reach engineering as tickets, already stripped of the reason they exist. I start one step earlier, with the company’s OKRs and the feature product has derived from them.
From there I define the functional and non-functional requirements, design the solution, and write code only once it’s clear what the code has to achieve.
Technical Debt
“Technical debt work is risk mitigation first and execution second. Skip the first, and every fix becomes a bet that can cost time and money, trigger big-bang side effects, or create more debt.”
Technical debt rarely comes from one bad decision. It usually builds up in one of three ways.
Shortcuts and messy code, written when the team chose speed over quality, now slow every change.
Old systems are left alone under an "if it isn't broken, don't fix it" policy while everything around them changes.
Decisions that made sense at the time stop making sense once the product changes direction.
Whichever it is, the fix starts with a strategy, and it is almost always incremental, not overnight. I use proven patterns to change a system while it keeps running: the strangler fig to replace a legacy component piece by piece, adapters to isolate old interfaces from new code, and facades to give messy internals one stable entry point.
Distributed Systems
“Distributed systems are the craft of building reliable systems from components that are unreliable by nature.”
Most products start as one server and one database. As users arrive, you add a cache, queues, workers, and a read replica.
The system becomes many machines, and new problems appear: timeouts, duplicate messages, and data that briefly differs between places.
Reliable distributed systems start with deliberate trade-offs. The famous one is CAP: during a network partition, you choose between consistency and availability. Both come in degrees, and the right choice varies by feature.
Payments need strong consistency, while an activity feed can be seconds stale.
From there the work gets concrete: timeouts and retries that are safe to repeat, sagas with compensating steps where a distributed transaction costs too much, and replication or sharding when one database isn't enough. I design for the failure before it happens.
Workflow Architecture
“Most workflow problems are classification problems. Teams commit to an architecture before they know which kind of workflow they have.”
Workflows range from a few forms in an HR portal to self-service onboarding that mixes people with automated steps. I sort them into four categories.
Simple flows, like a few forms leading to one outcome, are plain application code.
Long-running automated processes with retries and timers are where frameworks like Temporal earn their place, or orchestrated sagas when the steps span microservices.
Large business processes with human approvals and escalation are usually better served by BPMN and workflow engines such as Camunda.
Highly concurrent processes where cases compete for shared resources, like hospital triage with patients, beds, staff, and tests, suit Petri nets, which help model state and detect deadlocks before you build.
Which one you have depends on who is involved, how long it runs, and what must happen when a step fails. Get that right and the architecture stays robust instead of merely busy.
Agentic AI & Retrieval
“Agents are non-deterministic by nature, so you can't tune them by feel. You define what good looks like, measure it, and let evals tell you whether a change helped.”
Not every AI product needs an agent. A fixed workflow is often faster, cheaper, and easier to test than a ReAct loop.
Not every step needs an LLM either. Heuristics and rule-based engines still do some jobs better.
An agent is a handful of parts: short- and long-term memory, prompts, a ReAct loop, a context window, and guardrails. Each exists to serve effectiveness or security.
Tuning them is closer to experimentation than configuration. I define evals with an expected outcome, change one thing, re-run, and repeat until the agent meets it.
Giving an agent your knowledge base starts with the data. Mostly unstructured documents suit RAG.
When the agent has to understand how things relate, like a contract to its supplier to that supplier's risk profile, GraphRAG fits better. The goal decides.
Identity & Access Management
“Identity is the field everyone touches and few fully understand. Authentication and authorization get blurred. OAuth2, OIDC and SAML get used as if they were interchangeable. They are not.”
Authentication proves who you are; authorization decides what you may do. SSO is the goal.
OAuth2 delegates access, OIDC adds login on top of it, and SAML is the older enterprise standard.
I integrate providers like Entra ID and Auth0, set up machine-to-machine access, and map IdP claims to roles: RBAC where roles are stable, ABAC where access depends on context.
Authorization is enforced on the server, tokens are tested against forgery, and every service gets only the access it needs.
Bring the hard problem.
A 30-minute call with the engineer who will actually do the work.