Consequential initiatives across product, platform, data, and delivery.
A record of the work I am responsible for, most recent first.
Selected evidence
- 2026
Product and domain migration
The new experience and domain shipped as one transition while established entry points continued to lead users into coherent journeys.
- 2025–2026
Natural-language analytics
A dashboard that answers questions in plain language, sitting on a unified surface across two product lines.
- 2023–2025
Delivery and reliability
60% growth in dashboard adoption post-launch. Production bugs down 85%. Uptime sustained at 99.9%. Code review to deploy compressed from days to minutes.
The full record
-
Product architecture · Migration · Release engineering
Resident Ambassador: product rebuild and domain migration
Staff Software Engineer, Opiniion (via Rentgrata acquisition)
Joined a resident-facing rebuild already in progress and took technical ownership of its highest-risk seams, carrying the product and domain migration through a staged, backward-compatible release.
The new experience and domain shipped as one transition while established entry points continued to lead users into coherent journeys.
The reasoning
ContextA product-led rebrand had expanded into a rebuild of the resident experience and a move to a new domain. Engineering work was already underway without a single technical owner across the workstreams.
ProblemExisting links and communication flows still had to reach valid destinations while the product journeys behind them changed.
JudgmentAfter joining, I treated the work as a compatibility programme: define what had to remain true for users, connect the work already in motion, and give Product, QA, DevOps, and Engineering one shared release model.
BuildWithin a three-engineer team, my work covered much of the critical path: routing and legacy compatibility, chat and rewards flows, payments integration, the domain and authentication transition, email delivery, integration hardening, and the staged release through launch.
-
AI · Analytics · Platform
Natural-language analytics, and a unified product after acquisition
Staff Software Engineer, Opiniion (via Rentgrata acquisition)
Two parallel threads at Opiniion: an LLM workflow that turns plain questions into a query DSL and chart spec, and the architecture that lets two acquired products read as one dashboard.
A dashboard that answers questions in plain language, sitting on a unified surface across two product lines.
The reasoning
ContextTwo acquired product lines had to read as one dashboard, and operators were arriving with questions in their heads and leaving with a chart configuration in their hands.
ProblemThe layer between a question and an answer was a configuration exercise, and the two systems behind the dashboard had different operating histories showing through at the seam.
JudgmentI made an opinionated query DSL the trust boundary instead of letting the model emit free-form SQL: anything expressible in the DSL is safe to run, anything else is rejected before it reaches the database. The chart spec is a separate typed output, so the model decides the question’s shape and React renders deterministically. It costs expressiveness, deliberately, because the floor matters more than the ceiling for analytics operators trust on a Monday morning.
BuildThe DSL and chart-spec pipeline, an interactive dashboard that treats the LLM as a translator rather than a renderer, and a Gateway / Composer / Reconciler pattern that absorbs the two products’ differences at the seam. Architectural oversight embedded with the Resident Applications team.
-
Product · Reliability · Delivery
Ari, and trunk-based delivery on a customer-facing surface
Technical Team Lead, Rentgrata
Two intertwined initiatives as Technical Team Lead: the architecture and launch of Ari, our natural-language analytics platform, and the move to trunk-based development with containerized CI on a widget that ships to property managers every day.
60% growth in dashboard adoption post-launch. Production bugs down 85%. Uptime sustained at 99.9%. Code review to deploy compressed from days to minutes.
The reasoning
ContextTechnical Team Lead for a customer-embedded widget shipping to property managers every day, alongside the architecture and launch of Ari, the company’s natural-language analytics platform.
ProblemOperator workflows were spread across screens that existed only to bridge other screens, and the release loop was slow enough that shipping felt like an event rather than a habit.
JudgmentTwo questions held together: what the dashboard looks like if it is designed around the decisions an operator is actually making, and what the release loop looks like if every change is small and ships against an environment matching production. Long-lived branches were treated as a smell, not a strategy.
BuildLed Ari end to end: a RAG, vector-driven, LLM-powered analytics system rendered through a schema-driven generative UI. Redesigned operator workflows into single-page UIs, moved the team to trunk-based development, and stood up containerized CI. Reviewed the first ten small changes carefully so the eleventh felt safe.
-
Frontend · Platform · Embed
Migrating the widget platform to TypeScript and React
Senior Software Engineer III, Rentgrata
A multi-year migration of a customer-embedded widget from a legacy stack to TypeScript + React, taken seriously because it ships into pages we do not control.
60% smaller bundle. Twelve months without a release rollback. Design-system, cross-domain messaging, and an A/B testing surface the product team could actually use.
The reasoning
ContextThe widget ships inside other people’s marketing pages, where every byte sits on someone else’s critical path and every CSS leak becomes a support ticket.
ProblemA legacy stack was carrying the company’s primary distribution surface, and its cost to the host page had never been weighed against what the product actually needed to do.
JudgmentThe migration was not about TypeScript or React; those were the tools. The question was what the widget costs the host page and how to shrink it without losing capability. Old and new code paths ran side by side through the bulk of the work, so any regression was attributable rather than mysterious. Calendar time spent to buy confidence.
BuildMigrated the widget platform end to end to TypeScript and React, built design-system components shared with the dashboard without dragging styling into the host page, designed cross-domain messaging primitives, and stood up an A/B testing surface the product team could iterate inside without reshipping.
-
Data · Integrations · Reliability
Aggregating unstructured feedback into a product signal
Full-stack Software Developer, Unbird
Full-stack work on a platform that pulled customer feedback out of email, social, and app stores and turned it into something product teams could read.
Schemas remodeled, integrations stabilised, and a CI pipeline that recovered from incidents in minutes.
The reasoning
ContextA small team against a noisy data problem: customers were leaving signal across email, Twitter, Zapier flows, and app-store reviews.
ProblemProduct teams could not read any of it without first pretending it was structured.
JudgmentAggregation systems live or die on schema discipline. The most useful work was the least visible: the slow remodel of the data shape so everything downstream could stop apologising for it.
BuildBuilt and maintained the web application end to end, shipped and operated Twitter, email-bot, and Zapier integrations, remodelled 35+ database schemas and the APIs around them, and automated integration testing across CircleCI and AWS CodeDeploy.
-
Web · SDK · Embed
The flagship widget SDK, version one
Software Developer, Rentgrata
Built the first version of the widget SDK that became Rentgrata's primary distribution surface, and the one I would migrate to TypeScript and React four years later.
163% conversion lift in the first two months. Setup and observability rebuilt around what install partners actually needed.
The reasoning
ContextThe SDK was the first thing a prospective renter touched. Dashboards, messaging, and the operator surface all depended on it rendering correctly on a property’s marketing page within a second of arrival.
ProblemThe company needed a distribution surface property managers would embed, and install partners needed to integrate it without engineering hand-holding.
JudgmentMake the install easy and the failure modes legible. What the boundary actually promises, and what a host page can and cannot tolerate, became the brief for the TypeScript and React rewrite four years later.
BuildBuilt the flagship widget SDK end to end, reworked setup so install partners could integrate unaided, and added observability that let operators tell whether a property’s widget was healthy.
-
Frontend · Microservices · Migration
Migrating an AngularJS client to React, and twelve services to Mali.js
Software Developer, Andela
Frontend and platform migration work as part of an internal engineering org, and an early lesson in moving fast without losing the floor.
50% lift in developer productivity and 70% lift in stability after the React migration. 12+ services consolidated onto a single Node framework.
The reasoning
ContextAn internal engineering organisation with a real client application that teams shipped against daily, and a service mesh assembled from whatever language each team had reached for first.
ProblemNot a greenfield. The client app and twelve-plus services had to keep working for the teams depending on them while they moved.
JudgmentMigrations are mostly about the order you do things in. Get the seams right and the change is boring; get them wrong and every commit is a negotiation. Most of what I know about staged rollouts started here.
BuildMigrated an AngularJS client to React, and contributed to consolidating 12+ microservices onto Mali.js from a mix of Go and Ruby stacks.
These engagements are the evidence the convictions rest on.
The principles underneathIf you are weighing a decision shaped like one of these, that is a conversation worth having.
Contact