Selected work as evidence of judgement, not just delivery.
I am less interested in presenting a portfolio gallery than in showing how I approach meaningful technical and product problems. These notes focus on what made the work difficult, what decisions mattered, and what the outcome says about how I operate.
Tillo
Senior Software Engineer
Making partner-facing platform systems faster, clearer, and easier to extend
Real problem
Performance, partner onboarding, and integration architecture all needed to improve together. Isolated fixes would have moved the symptoms around without improving the system.
Decisions that mattered
Used Datadog APM to identify production bottlenecks, refactored webhook logic around strategy patterns for a broader offering, and stayed close to client integrations so platform decisions reflected real onboarding friction.
Outcome
Response times improved by 20%, the webhook service became easier to expand without duplication, and the product surface became more trustworthy for partners relying on it.
What it says about how I work
This is the kind of work I am drawn to: technical decisions that make both the internals and the external experience better.
What changed
Production tracing turned a vague performance problem into a concrete refactor plan, which made the API surface faster for partners and clearer for the team maintaining it.
Independent
Agent-assisted engineering workflows
Turning agent-assisted delivery into a repeatable workflow
Real problem
AI tools can generate plenty of code, but without clearer briefs, verification, and ownership they mostly move ambiguity around faster.
Decisions that mattered
Tested multi-agent repo workflows, specification-first briefs, and review checklists against real coding tasks while keeping a running log of where orchestration helped and where manual judgement still had to step in.
Outcome
The gains showed up in faster repo orientation, stronger first drafts, and clearer handoffs. The misses were equally useful: review load, integration work, and architectural trade-offs still needed a human with context.
What it says about how I work
I am interested in AI when it changes how good software gets made in practice, not when it only produces a better demo.
Workflow note
The durable pattern was not more autonomy. It was tighter briefs, one clear owner, and explicit checks that kept review debt from erasing the speed gain.
Tutorful
Software Developer
Designing for messy real-world constraints without making the platform brittle
Real problem
A document validation flow had to handle multiple DBS certificate formats and localisations while the wider product was also evolving quickly across web and mobile.
Decisions that mattered
Built the validation API with AWS Textract, planned availability infrastructure that could scale operationally, and helped sunset a legacy Laravel API to reduce long-term maintenance drag.
Outcome
The system supported real-world input variability, unlocked more product capability, and avoided leaving a larger clean-up bill behind for the team.
What it says about how I work
I care about the hard middle ground where product ambition meets operational complexity and architecture has to stay realistic.
System note
The work only held together because the API design, operational rollout, and product edge cases were treated as one system instead of separate clean-up jobs.
Sonin
Lead Software Developer, iOS
Bridging app architecture, backend reality, and delivery infrastructure
Real problem
Mobile work often absorbs the cost of unclear backend contracts, shifting requirements, and infrastructure decisions made elsewhere in the stack.
Decisions that mattered
Re-architected iOS work around SwiftUI and MVVM, built serverless video infrastructure for inspection workflows, and regularly stepped into the joins between app teams, APIs, and delivery concerns.
Outcome
Products became easier to evolve, teams had clearer technical boundaries, and delivery stopped depending on one part of the system pretending the rest did not exist.
What it says about how I work
My bias is always toward coherence: making the whole system easier to reason about, not just polishing one layer of it.
Architecture note
The best interventions were the ones that tightened contracts between app code, backend behaviour, and delivery infrastructure so teams could change one part without guessing about the rest.
How I tend to operate
I like ambiguous work where architecture, product, and delivery all need to inform one another.
I care about the decisions that reduce future drag, not only the ones that close the current ticket.
I treat performance, clarity, and maintainability as connected concerns rather than separate clean-up phases.