01RWA · Multi chain2023 to 2025

Three RWA Platforms, Three Chains

Tokenizing real world assets on Ethereum, BNB Chain and Algorand. Same goal each time, three very different sets of constraints, and every one of them shipped to mainnet.

SolidityEthereumBNB ChainAlgorandNext.js
Drop a Decrypted Labs screenshot
3
platforms live across three networks
Fractional
ownership of real assets on chain
End to end
contracts, frontend and admin
Mainnet
deployed, not left on testnet
The problem

Real assets like property are high value and illiquid, so ordinary investors are locked out. Tokenizing them sounds simple until you hit compliance, issuance control, and the fact that a bug in a contract is permanent.

What I built

For each chain I built the token contracts, the issuance and distribution logic, investor onboarding with KYC gates, campaign pages, investor dashboards and an admin panel for the issuer. Ethereum used ERC-20 fractional ownership with IPFS metadata, BNB Chain was chosen where the economics only worked on low fees, and Algorand used ASA with instant finality and built in asset controls for the compliance heavy case.

The outcome

Three working platforms where investors buy fractional ownership of real assets, issuers control supply and compliance, and the whole flow from signup to token holding runs without manual intervention.

The hard part

Every chain has a different toolchain, a different fee model and different assumptions about compliance. The real work was not writing three sets of contracts, it was deciding which chain fitted each business case and then designing the money flow so that a mistake could not become permanent. Testing, staging and audit discipline mattered more than the code itself.

02Healthcare SaaS2025

One CRM Backend, Two Healthcare Businesses

Built a practice management CRM for a chiropractic clinic, then reused the same backend for a second client — a medical equipment billing office. Both were drowning in the same problem: paperwork that had to be retyped by hand.

NestJSPrismaPostgreSQLAWS TextractAWS S3Next.js
Drop a Chiro360 screenshot
2
healthcare businesses on one backend
Textract
auto-reads scanned intake & billing docs
Live
in production, not a demo
1 pipeline
reused end to end for the second client
The problem

Intake forms, insurance documents and billing paperwork arrived as scans and PDFs. Someone had to open each one and retype it into the system before any work could actually start. That's slow, and it's the kind of job people make mistakes on by the fiftieth form of the day.

What I built

A NestJS and Prisma backend where uploaded documents go through AWS Textract, which reads the scan and pulls out the structured fields automatically — no manual retyping. On top of that: role-based login, PDF generation for billing, CSV export for reporting, and scheduled jobs for the recurring stuff nobody wants to remember to do manually. Once the chiropractic clinic (Chiro360) was live in production, I reused the same backend architecture for a second, unrelated healthcare client doing medical equipment billing — same document pipeline, different business.

The outcome

Two healthcare businesses run on this now, not one prototype. Staff upload a document instead of typing it out, billing PDFs and reports come out in one click, and the second client shipped faster because the hard part — the document pipeline and the auth — was already built and proven.

The hard part

OCR is never perfect, and healthcare staff won't trust a system that quietly gets a number wrong on a billing document. The real work was making Textract's output easy to spot-check — clear enough that a human glances and confirms in seconds, instead of re-typing the whole form just to be safe.

03AI Developer Tool2025

Automated LinkedIn Content from GitHub Commits

Developers do interesting work every day and never talk about it. Built a tool that reads your GitHub commits, uses OpenAI to write developer-voice LinkedIn posts, and publishes them on a schedule.

Next.js 16NextAuth v5OpenAI APIBullMQUpstash RedisLinkedIn APIMongoDBVercelTypeScript
Drop a Personal SaaS screenshot
1 click
from commits to a finished post
2 OAuth
GitHub and LinkedIn connected
Scheduled
background publishing on a queue
Queued
BullMQ jobs on Upstash Redis
The problem

Most developers are too deep in the work to think about personal branding. Writing LinkedIn posts about what you built is time-consuming, and most people just don't do it. The knowledge stays locked in commit messages that nobody outside the repo ever sees.

What I built

Users connect GitHub and LinkedIn via OAuth (NextAuth v5). The app pulls recent commits, sends them to OpenAI with a prompt tuned for developer voice — not corporate speak — and generates post drafts. Users can review and edit before scheduling. BullMQ with Upstash Redis handles the background job queue. Posts go out at the time the user sets, adjusted for their timezone. Deployed to Vercel with a background worker running separately.

The outcome

An automated personal branding pipeline that runs on its own once connected. Users get consistent LinkedIn presence reflecting their actual work, without writing a single post manually.

The hard part

Commit messages are terrible source material. Getting from raw diffs to something worth reading meant shaping the prompt around what was actually interesting in the work, and giving the user an edit step before anything reached their public profile.

04B2B SaaS Platform2025

Digitizing a Defence Procurement Workflow

A UK-based defence contractor was running procurement through email chains and spreadsheets. Built them a full-stack platform that handles the entire lifecycle — from RFQ creation to vendor selection.

Next.js 16NestJSPostgreSQLPrismaGSAPLenisRechartsShadcn/UITailwindCSSDigitalOcean
Drop a LightNX Defence screenshot
100%
of RFQs moved off email
Real time
vendor negotiation and bidding
1
source of truth for compliance
3 roles
buyer, vendor and admin flows
The problem

Procurement was a mess. RFQs went out as PDFs via email. Vendors replied with attachments. Compliance docs got lost. Negotiations happened over phone calls with no record. There was no single source of truth, and audits were painful.

What I built

Built a full-stack platform on Next.js and NestJS. Admins create RFQs with line items, deadlines, and compliance requirements. Vendors log in, review RFQs, and submit structured proposals. A built-in chat component handles negotiations with full message history. Compliance documents are uploaded and tracked per vendor. The admin panel gives full visibility into every active procurement.

The outcome

The entire procurement cycle — from RFQ to vendor selection — now runs through the platform. Zero emails exchanged for routine procurement. Every interaction is logged. Admins can track compliance status in real time and export audit trails on demand.

The hard part

In defence procurement the audit trail is the product. Every state change needed to be recorded, attributable and impossible to quietly edit later, which shaped the data model far more than the interface did.

05FinTech / Web3 Platform2025

Fiat Payments & Subscription Billing for an MLM Platform

Migrated a crypto-only MLM platform to accept fiat payments via Authorize.net, fixed broken subscription billing, got rank tracking working correctly, and stood up a full staging environment.

Next.jsNode.jsExpressMongoDBAuthorize.net SDKSolidityPM2NginxDigitalOcean
Drop a IAMDivinity screenshot
2 rails
fiat and on chain, unified
Auto
recurring CIM subscriptions
On chain
rank reward distribution
CI/CD
dedicated staging pipeline
The problem

The platform only accepted crypto. A large portion of users wanted to pay with cards. Authorize.net was partially integrated but kept throwing testRequest errors — turned out the team had mixed demo and sandbox credentials. On top of that, personalVolume wasn't tracking correctly for MLM rank calculation, and there was no safe place to test changes without risking production.

What I built

Diagnosed the Authorize.net credential mismatch — demo accounts don't work in the sandbox environment, full stop. Rebuilt the payment flow using createCustomerProfileFromTransaction so the first real charge also creates a Customer Information Manager (CIM) profile for recurring billing. Set short subscription expiry cycles in test mode to verify the billing loop. Fixed the personalVolume tracking logic in the rank calculation service. Provisioned a separate DigitalOcean droplet for staging with its own subdomain, MongoDB seed data, PM2 config, and Nginx reverse proxy.

The outcome

Fiat payment processing is live. Subscription renewals fire correctly on schedule. Rank advancement works as expected based on real volume data. The staging environment is isolated from production and used for all new feature testing before deployment.

The hard part

Two payment worlds with completely different failure modes. A card charge can be refunded, an on chain distribution cannot, so the system had to treat the chain as the final step and never the first one.

06Dispatch / Logistics SaaS2025 to present

Putting a Towing Company's Dispatch on a Map

A towing company in Jacksonville, FL was dispatching trucks over the radio with no shared view of who was where. Building them an admin platform that puts every truck, job and invoice on one screen.

Next.js 16NestJSPrismaPostgreSQLLeafletTanStack Query
Drop a TOWINTEL screenshot
1
real towing company dispatching on it
Live
map of every truck and active job
3
core flows: dispatch, jobs, billing
Real data
every screen, no mock data left in
The problem

Dispatch ran on radio calls and phone memory. Nobody had a live view of which truck was free, which job was in progress, or what a job should be billed once it closed. Everything lived in someone's head or a notebook.

What I built

A Next.js dispatch dashboard with a live map (built on Leaflet) showing every truck and active job, a job board drivers pull work from, a driver queue, and a charges panel that builds the invoice as a job closes out. It's backed by a NestJS and Prisma API on Postgres. Every screen reads and writes real data — there's no mock data left anywhere in the flow, because the company is actually using it to run their day.

The outcome

A dispatcher can see the whole fleet on a map instead of asking over the radio, and a job goes from created to billed inside one system. It's still actively being built out — new flows go in as the business needs them, tested against how the company actually dispatches, not a spec written up front.

The hard part

Dispatch software has to be right in real time. If the map shows a truck on the wrong job, or the queue is stale by even a minute, someone's actual day breaks. The hard part wasn't any single screen — it was keeping the map, the queue and the billing state honest with each other while the underlying data keeps changing.

Available now for AI and blockchain projects

Your build could be the next one on this page.