Selected work

The work, and the decisions behind it.

Six engagements across insurance, fintech, gaming, healthtech and field service. For each: the situation, the call that was expensive to reverse, how I approached it, and what it shipped. The numbers are real.

Insurance · enterprise platform

Pie Insurance

Owning the authentication track of a unified frontend re-architecture across a 100+ microservice platform.

100+

services on the notification system

~80%

less support load via self-serve docs

OAuth

Amplify/SRP → Cognito Managed Login

Situation

Pie's Partner Portal runs on 100+ backend microservices, and the frontend was being consolidated into one unified application. Authentication sat on a legacy Amplify/SRP flow that had become load-bearing without anyone choosing it on purpose. Fine, until the day you need to change it.

The decision that mattered

The auth architecture was the expensive-to-reverse call. Framework, where tokens live, which OAuth flows, how to handle multiple Cognito user pools. Get any of it wrong and 100+ services inherit the mistake. I owned that track, wrote the decisions down as ADRs before writing the code, and pressure-tested them with Product, UI/UX, Finance and senior leadership.

Approach

I authored the ADRs, then implemented the result: a modern OAuth flow on Cognito Managed Login, replacing the legacy Amplify/SRP flow. Alongside it I designed a generic notification system that works with 100+ services, shipped a self-serve document-generation feature that cut manual support load by ~80%, and contributed to a platform-wide shift from BFF-heavy to direct-to-backend. Agentic tools (Claude Code, Cursor) carried the scaffolding and refactors; the architecture and review calls stayed with me.

fig. tokens moved from JS-readable cookies to httpOnly; auth from browser SRP to OAuth 2.0 on Managed Login.

Before diving into the code, he takes the time to thoroughly understand the business requirements — that meticulous upfront analysis lets him anticipate complex edge cases and architectural roadblocks long before they reach production. He has the rare maturity to provide constructive pushback when necessary.

Shilpi ReddyEngineering Leader · Pie Insurance

Web3 · gaming

Bullseye Web3 Studio

Architecting and leading the backend for two greenfield Web3 games.

150k+

registered users

< $500/mo

GCP across 10+ services

products shipped from zero

Situation

Two products from zero: AI Nexus, a Unity-powered social-metaverse mobile game, and A1X Clone Machine, a web app for creating AI agents. Neither had product-market fit yet, and nobody could say how fast either would grow. The backend had to handle growth without burning money waiting for it.

The decision that mattered

The hard call was scope, not scale. I committed to an event-driven microservices architecture on GCP, then kept cutting: no orchestrator, Firebase Cloud Messaging instead of custom websockets, nothing built for a growth curve we hadn't seen yet.

Approach

I architected and led the backend end to end, from first principles through CI/CD and the blockchain integrations, translating ambitious game-design and product requirements into services that stayed cheap and stable as the products grew.

fig. one blueprint per module, a database per module, events in between; the rest deliberately left out.

Healthtech · 0→1

Parentool

Fractional CTO from idea to a top-3 App Store health app, all on organic growth.

10,000+

users, organic

App Store Health & Fitness

7%+

paid conversion

2,000+

paid consultations · 16+ fields

Situation

A bootstrapped healthtech idea with non-technical founders: no product, no team, no technical direction, and no outside funding to paper over mistakes.

The decision that mattered

As the technical owner, the recurring decision was allocation: what to build, what to defer, and where limited resources buy the most progress toward product-market fit. The rest was building a team and a process that could carry it without burning the runway.

Approach

I took it from Figma designs to live apps on both stores, then owned architecture, delivery and the technical side of growth and hiring, eventually formalized as CTO and shareholder. Every decision got explained in plain terms to non-technical founders.

fig. Firebase direct for the everyday; Cloud Functions as the gate for paid ops and the OpenAI chatbot.

He delivered a highly functional, almost bugless solution in the exact timeline we agreed — and could explain to us, non-technical people, everything happening in the backend.

Petruța CosteaFounder · Parentool

Consumer · production rescue

Glede

Stabilizing a live microgifting app, then pushing it toward B2B.

30,000+

users

Hot paths

performance recovered

B2B + Wallet

new direction shipped

Situation

A microgifting app with a built-in viral loop (send a small gift; the recipient installs the app to redeem it, then gets nudged to send their own) had grown past 30,000 users, and a struggling production codebase was causing real problems for paying customers.

The decision that mattered

The call was triage versus rebuild on a live, revenue-affecting product: what to fix first without making things worse, and how to open a B2B direction on top of a codebase that was already wobbling.

Approach

I came in as the mobile expert, fixed the critical problems, improved performance in the hot paths, and shipped new functionality, notably the move toward B2B and an Apple Wallet integration for gift redemption.

fig. migrate module by module, shift users gradually, ship the new stuff in the new codebase only.

An amazing programmer. He had no problems turning business requirements into code, and worked really well with our designers — even when the design wasn't ready yet.

Erik KjernlieCo-Founder & CTO · Glede

Fintech

Reach Finance

The foundations for a fintech app that acts as a personal financial advisor.

0 → shipped

mobile app from scratch

AWS

backend + process foundations

Situation

A fintech product where users set goals (buy a house, retire early) and get projections, a concrete strategy and progress tracking toward them. Greenfield, and I was brought in at the very start.

The decision that mattered

Early-stage fintech lives or dies on its foundations. The call was to set the architecture, code structure and development process for the AWS backend up front, in a tight loop with business and design, so the structure and the product could grow together.

Approach

Full-stack lead from day one: I built the React Native app from design and business requirements while establishing the AWS backend architecture and the team's development process.

fig. reactive calculations on-device, proprietary ones on AWS next to the data; one UI, matching numbers.

Truly a stellar developer. As we were building a very complex fintech application, his experience, problem-solving and speed were extremely valuable. He creates the right solutions, is 100% reliable, and delivers what you need — in time and quality.

Daniel HeckerProject Manager / Deputy Division Head · Frankfurter Bankgesellschaft

Field service · offline-first

Equinet — by Mustad

Collaborative organization management inside an offline-first architecture.

Offline-first

multi-user orgs shipped

Sync + conflicts

the hard part, owned

Situation

An offline-first React Native app helping farriers run their businesses: scheduling, inventory, multi-user organizations. I joined a team two years into the product to lift performance, ship features and raise codebase quality.

The decision that mattered

The hard part was never the UI. It was organization management and collaborative actions in an offline-first model, where sync and conflict handling are the whole problem. That's where I focused.

Approach

I designed and implemented org management and collaborative actions with the sync and conflict handling an offline-first architecture demands, alongside performance and quality improvements across the codebase.

fig. two devices, one org: offline edits queue locally, conflicts resolve centrally, every device converges.

One of those valuable developers you'd want to build your team around — a pragmatic problem solver, keen to improve code and product quality while keeping the user in mind.

Sebastiaan OrdelmanProduct Director & CTO

Start a conversation

Recognize your situation in one of these?

A decision that's expensive to reverse (auth, data, system boundaries), or a build where design and delivery belong to the same person. That's where I'm useful. Tell me what you're weighing and I'll tell you straight whether I can help.

Book a conversation hello@dbln.me