The Offline Claim

Every country. Including the ones with bad internet.

You insure people who get dengue in Bali and crash scooters in Thailand. Those are the exact moments when someone is on a borrowed phone, on a network that barely works, filing a claim that actually matters.

I am Cyril. I build products end to end, design and code, from Buea in Cameroon. For six years my constraint has been the one your users hit occasionally and mine hit daily: the connection is not there, and the software still has to work. So rather than describe it, here it is.

What that is actually doing

Client generated identity

Every claim gets its id on the device before the network is involved. That id is the idempotency key, so a retry can never create a second claim.

Persisted locally, receipt included

Claims and their photos are written to IndexedDB on the device. Close the tab, lose the phone signal, reload. Nothing is in memory that would die with the page.

Retry with backoff, on a real signal

Poor mode makes requests slow and half of them fail, which is what a roadside in Thailand feels like. Each failure backs off and retries with the same key. The page also listens to the real online and offline events.

Ordered drain, honest state

Oldest first, one at a time. Queued and received are different words on screen because they are different truths, and a person who filed three claims sees three claims in the order they lived them.

Where this comes from

I designed and built eStudyUniverse, an e-learning platform and mobile app used by more than 10,000 students in real schools here. It had to work fully offline on cheap Android phones, because students here lose connectivity for days at a time, not minutes. That single requirement shaped nearly every architecture decision in the product, and I lived with those decisions for years afterwards rather than handing them over.

I also built ClarioScore, a rent reporting platform, from an empty repository to paying customers. Identity verification, monthly submissions, a landlord portal, bureau reporting and subscriptions. And I run Cyprograms, a small studio that has delivered more than 100 products, which is where I learned that the architecture you choose is the architecture you support at 2am.

On the things you asked for

Architectural decisions with long term follow up. Running a studio means I have never once made a call and walked away from it. I have maintained my own decisions across years and across clients, including the bad ones.

Cross project infrastructure. Shared design systems, component libraries and deployment pipelines across a portfolio of products, because with a small team that is the only way the work scales.

Daily agentic tooling. Claude Code and Cursor are in my loop from spec through review, not as a demo. It is a large part of why a team my size ships what it does. I expect you will ask me to show this rather than claim it, and I would rather show it.

Design. Figma is in your stack and I do the design as well as the code. On a small team that tends to be one hire instead of two.

What I would be learning

I should be straight about the gaps rather than let you find them. Astro and SCSS Modules I have not shipped; my front end is React, Next.js, TypeScript and Tailwind. GraphQL I have consumed but my API work is mostly REST. Cloudflare and Railway are new to me; I deploy on Vercel, Google Cloud and AWS. None of those are conceptual leaps, but they are real, and you should price them in.