Full project deep dives

Project 01 — Open Source

Mongeese

npm install mongeese · TypeScript · MongoDB · Open Source

MongoDB has never had a proper migration tool. You add a field to your schema, you write a one-off script, you run it manually in staging and hope you remember to run it in prod. There is no Prisma Migrate for MongoDB. No declarative schema definition, no automated diff, no migration history. This was the gap I built Mongeese to fill.

Mongeese works by letting you define your MongoDB schema declaratively and then computing a three-way diff: additions (new fields and indexes), removals (deprecated fields), and modifications (enum changes, type changes). Removals are flagged as dangerous and require explicit confirmation. The diff is then applied as a structured migration, recorded in a _mongeese_migrations collection. Each migration carries a content hash, making reruns safe and idempotent.

I shipped it with no marketing spend. Within 31 days it had 1,000+ npm downloads and 22,900+ LinkedIn impressions from a single post. The SVP of Products at MongoDB reached out to discuss the problem space. The pull was organic — the problem is real and every MongoDB developer has felt it.

Project 02 — Fintech / Payments

Kortex

NestJS · MongoDB · Paystack · Monnify · HMAC-SHA512

Kortex is an African creator economy platform for online courses. I built the payment infrastructure that handles every transaction on the platform — from the moment a student clicks "Pay" to the moment the revenue is split between the tutor, the platform, and any affiliate channel.

The first engineering requirement was exploit-resistance. Payment webhooks are unauthenticated HTTP requests — anyone who knows your endpoint URL can fire them. Before Kortex touches a database record, it verifies the HMAC-SHA512 signature on every incoming webhook using the shared secret from Paystack or Monnify. An invalid signature gets a 401 and nothing else.

The second requirement was idempotency. Payment providers deliver webhooks at-least-once — the same event may arrive twice, three times, or more. Before processing any event, Kortex checks the payment reference against a processed references collection. A duplicate reference is acknowledged but not processed, making the pipeline safe against double-crediting creator wallets.

The third requirement was atomicity. The revenue split — tutor share, platform fee, channel commission — must either complete entirely or not at all. This is implemented as a MongoDB multi-document transaction. There is no world where the platform fee is recorded but the tutor share is not.

Project 03 — YC W22

Topship

NestJS · MongoDB · Event-driven · Carrier APIs · Payments

Topship is Africa's largest cross-border shipping aggregator, backed by Y Combinator (W22). The platform aggregates DHL, FedEx, UPS, and regional carriers under a single API, letting businesses and individuals ship internationally at consolidated rates.

My work was on the payment and carrier integration layer. Payments had to be confirmed before shipment bookings were released to carriers — a sequencing requirement that sounds obvious but requires careful state machine design when payment webhooks are asynchronous and carriers have their own async status update streams.

Carrier APIs are not reliable. DHL will intermittently return 503s. Status update webhooks arrive out of order. I built retry logic with exponential backoff, dead-letter tracking for events that exhausted retries, and reconciliation jobs that periodically re-query carrier APIs for shipments whose status went stale. The goal was eventual consistency, not synchronous correctness — and the 99.9% API uptime on the integration layer reflects that.