


I'm a product-minded software engineer who likes turning unclear, fiddly workflows into products people can actually use. I'm also a Computer Science graduate from Queen Mary University of London. Most recently, I designed, built, deployed and supported HymnDeck, an AI automation SaaS used by church worship teams.
The best part of building something is watching someone use it. Code, infrastructure and product decisions are all ways of getting there. That probably connects to the role I play outside work too: when something technical breaks, I'm usually the person friends ask to fix it.
I owned HymnDeck end to end: customer research, product decisions, frontend, backend, AI orchestration, billing, cloud infrastructure, deployment and production support. At its peak, two churches used it every week. One still uses it to prepare Sunday services, reducing a workflow that could take several hours to around ten minutes.
It runs on Next.js, FastAPI and Postgres, with long AI jobs handled through Cloud Tasks. Its job state survives container restarts, duplicate delivery and model failures. It has stayed in production since April 2026 without manual intervention to keep it alive, at near-zero running cost.
My first import flow assumed churches worked from one carefully maintained master presentation. In reality, they rehearsed from folders of old PowerPoints, so I rebuilt it around what they actually had. That experience reinforced something I now try to practise: observe the workflow before becoming attached to the solution.
I also built billing, but none of HymnDeck's users converted from free to paid. I tested product and technical risk before properly testing willingness to pay or distribution. Its engineering depth outran its commercial validation, and I would sequence those risks differently now.
I care about doing things properly, sometimes beyond the point where the extra work matters. Building alone has taught me that quality is not the same as perfecting everything: it also means deciding what deserves care, what needs feedback and what simply needs to ship.
Solo work has taught me ownership and speed, but also where collaboration pays: reviewing decisions early, challenging scope and going deeper instead of constantly switching disciplines. I work best with people who trust one another enough to disagree openly and change their minds.
Much of my life revolves around church and friends—often basketball, dinners, video games, or saying yes to wherever people are going.
Product engineering is my clearest edge, but I'm open to frontend, backend, infrastructure and adjacent roles. I'd like to join a team where I can own meaningful problems, learn from experienced engineers and keep seeing my work reach the people it was made for.
Let's connect if you're hiring, or if you need someone who can take an AI or automation idea through product, build, deployment and the messy part afterwards. If you run an agency and occasionally have more delivery work than hands, here's how I work with agencies.