Henry Dennis

Building partner-facing platform systems and testing how agent-assisted engineering changes software delivery.

I work on APIs, integrations, and reliability at Tillo, and I test workflows where automation helps without loosening quality. Architecture, verification, and maintainability still decide the outcome.

See selected work Read the field notes

Selected work

Work that held up in real systems

Examples where architecture, product shape, and delivery constraints had to be resolved together.

View the work

Tillo

Senior Software Engineer

Making partner-facing platform systems faster, clearer, and easier to extend

Constraint

Performance, partner onboarding, and integration architecture all needed to improve together. Isolated fixes would have moved the symptoms around without improving the system.

Decision

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.

Result

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.

This is the kind of work I am drawn to: technical decisions that make both the internals and the external experience better.

Independent

Agent-assisted engineering workflows

Turning agent-assisted delivery into a repeatable workflow

Constraint

AI tools can generate plenty of code, but without clearer briefs, verification, and ownership they mostly move ambiguity around faster.

Decision

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.

Result

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.

I am interested in AI when it changes how good software gets made in practice, not when it only produces a better demo.

Tutorful

Software Developer

Designing for messy real-world constraints without making the platform brittle

Constraint

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.

Decision

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.

Result

The system supported real-world input variability, unlocked more product capability, and avoided leaving a larger clean-up bill behind for the team.

I care about the hard middle ground where product ambition meets operational complexity and architecture has to stay realistic.

Sonin

Lead Software Developer, iOS

Bridging app architecture, backend reality, and delivery infrastructure

Constraint

Mobile work often absorbs the cost of unclear backend contracts, shifting requirements, and infrastructure decisions made elsewhere in the stack.

Decision

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.

Result

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.

My bias is always toward coherence: making the whole system easier to reason about, not just polishing one layer of it.

Field notes

Ideas grounded in operating work

Notes and essays pulled from the systems, workflows, and delivery questions I am actively testing.

Browse the full archive

Current themes

What keeps showing up

The ideas, tensions, and system questions that keep returning across the work.

01

Agent-assisted engineering

I am interested in what changes when code generation gets cheaper, tools become more autonomous, and more of engineering work shifts toward context, verification, and system design.

02

Platform systems

I care about boundaries, trade-offs, failure modes, and the architectural decisions that decide whether a platform compounds or becomes harder to change every quarter.

03

Engineering judgement

Good engineering is not only execution. It is deciding what deserves complexity, what should stay simple, and what makes software actually feel coherent to its users.

04

Maintainability

As generation gets cheaper, quality matters more. I pay attention to clarity, observability, trust, and the habits that make a system hold up after the demo.