Frame the problem
I start with the decision the system has to support and the failure that would hurt most, and I write both down before choosing tools.
Senior Full-Stack Engineer
Backend systems · Verifiable AI · IoT · Product interfaces
I take a problem from an unclear requirement to a system that runs, recovers and can be checked. Most of my depth is in the backend — Python and C#/.NET services, PostgreSQL, identity and payments — with TypeScript and React interfaces on top. My current focus is AI that has to be verified: retrieval over versioned sources, citations checked in code, evaluation that runs in CI, and a person who stays accountable for the decision.
I start with the decision the system has to support and the failure that would hurt most, and I write both down before choosing tools.
Each significant choice gets a short decision record: the option taken, the one rejected, and what would make me revisit it.
Data model, API, workers and the interface people use, so the rules the server enforces are the rules the screen shows.
Tests for the failure paths as well as the happy one: duplicates, timeouts, stale versions, unsupported claims. For AI features, a versioned evaluation set that runs in CI.
Runbooks, recovery steps and honest limits in the README, so someone else can run it, change it, or show me where it's wrong.
APIs, workers, ledgers and data stores that keep one authoritative record when a broker, cache or third party is down, late or duplicated.
Retrieval over versioned sources, structured output, code that checks every citation, evaluation in CI, and human review where the stakes need it.
TypeScript and React surfaces that let a person inspect, decide, retry or cancel under the same rules the server enforces.
Four systems I'd walk you through first. Each card names the problem, the decision, what I traded away, and where to check the code. Each runs locally from its README.
Domain data is synthetic unless a project says otherwise. These are reference systems, not production services or legal advice.
ai-compliance-agent
ProblemA fluent paragraph isn't a compliance finding unless every quote, date and deadline traces to the policy version it came from.
DecisionRetrieval searches 588 EPA rules from the Federal Register (34,174 sections) in PostgreSQL, ranked by hybrid full-text and vector search and limited to rules in force on the case date. Code checks the model's typed output: - Each cited source was retrieved. - Each quote appears verbatim in its policy. - Each date or duration in the rationale appears in a cited quote. - A failed check gets one retry with the errors fed back, then goes to a reviewer. - Only an authorised reviewer can approve or reject, and the review is bound to a hash of the analysis. Questions about the rules get an answer only when every quote matches its numbered source.
Trade-offThe checks catch unsupported quotes and dates but not wrong interpretations, so human review stays mandatory. A correct answer can be withheld when a quote is off by a word.
EvidenceThirteen versioned cases in evals/cases/v1.json run in CI with a deterministic provider. Hybrid search was chosen after measuring five retrieval methods (ADR 008). A PyTorch classifier was compared and not promoted (ADR 009). Tests cover worker leases, lease renewal and fencing tokens.
RepositoryRun locallyEvaluation setDecision recordsMeasurements
operations-command-center
ProblemA workflow engine without a safe human console trains people to bypass the controls at 2 a.m.
DecisionNext.js with OIDC sessions, tenant-scoped audit, and retry/cancel that require an idempotency key plus an expected version.
Trade-offEvery retry or cancel costs the operator an extra step, an idempotency key and the expected version, so a double-click or a stale screen gets a clear conflict instead of a second recovery.
EvidenceAuthenticated console, optimistic-concurrency tests, and tenant audit history in PostgreSQL.
daraja-mpesa-for-woocommerce
ProblemClosing a tab, or trusting a callback body, isn't settlement.
DecisionCorrelate callbacks and STK status queries, verify the exact amount, treat duplicates as idempotent, and keep an audited manual reconciliation path.
Trade-offConfirmation can take longer when callbacks are late or missing. The order stays unpaid until a correlated callback matches the exact amount and receipt. A status query on its own does not mark the order paid.
EvidenceWordPress/WooCommerce plugin, callback correlation tests, and documented timeout plus manual verification flow.
enterprise-automation-platform
ProblemA workflow that can't be restarted mid-flight will eventually lose work, and nobody will know which step it lost.
DecisionPostgreSQL is the system of record. Redis only dispatches. A transactional outbox, leased workers, and signed webhooks carry work; operators replay dead letters.
Trade-offAt-least-once delivery rather than exactly-once. Duplicate messages are expected and made harmless by an atomic claim; connectors still need their own idempotency keys.
EvidenceCompose stack, worker lease tests, and an operator recovery path for exhausted deliveries.
Smaller labs, each built around one failure mode. The linked note explains the decision behind each.
Signed webhook ingestion with a persisted envelope, at-least-once delivery, fenced leases and replayable dead letters.
An OIDC gateway with PKCE, client credentials and revocation, where the protected service validates tokens itself.
Typed adapters for third-party APIs with timeout budgets, circuit breakers, contract checks and redacted errors.
Outages you can replay: injected faults, cache circuit breakers and measured recovery.
Effective-dated prices, immutable usage receipts, and invoices that don't change when prices do.
A .NET double-entry repayment ledger kept separate from broker delivery, with recovery drills.
Motor claims as durable Temporal cases behind one BFF, with RPA adapters kept replaceable.
Versioned consent, deny-on-missing-policy, and audited break-glass access that never comes from a cache.
A Next.js storefront where WooCommerce stays the record for price, stock and orders.
Late, duplicate and out-of-order telemetry kept as receipts; live location is a rebuildable projection.
Publish-time rights checks, reproducible transforms, and revocation after an unknown delivery outcome.
Explainable scoring and mandatory review for high-risk automation proposals.
A TypeScript control plane for n8n, Zapier, Make, and Power Platform with one authenticated operations app, versioned manifests, signed execution telemetry, release approval that cannot be self-granted, and incident evidence that does not store provider payloads.
Notes
Thirteen versioned fixtures run through the real retrieval and validation code in CI, with a fixed model output, so a weaker check fails the build.
n8n, Zapier, Make, and Power Platform keep their native artifacts. One control plane owns inventory, releases, and signed telemetry. A gated release cannot be approved by the person who proposed it.
Spring Boot owns the case and authorization. Temporal owns timers, human-task signals, and recovery. Python and RPA adapters stay replaceable; they do not become the claim.