Backbone Technologies
ActivePayments and fintech infrastructure for SMEs: Stripe, Plaid and Modern Treasury rails behind an event-driven TypeScript backend holding p95 API latency under 100 ms.
- TypeScript
- Node.js
- Express
- BullMQ
- MongoDB
- Redis
- AWS ECS
- AWS Fargate
- Plaid
- Modern Treasury
- Stripe
- React
- PostHog
One of two engineers, owning backend, AWS architecture and the payments stack, working directly with the CEO. p95 API latency under 100 ms. Monthly cloud spend cut 30%.
What was broken.
SMEs were stitching together accounting, banking, and reconciliation manually. Backbone needed an API surface fast enough to feel like a single product, not three integrations duct-taped together.
How it is wired.
Event-driven TypeScript/Node backend on AWS: Express services with BullMQ queues over MongoDB and Redis. Plaid for bank linking and transaction ingestion, Modern Treasury for payment rails, Stripe for cards after Chase discontinued WePay. Ledger events are materialised into analytics-ready facts for the ML surface.
What I shipped.
- Selected Stripe and ran the migration when Chase discontinued WePay
- Plaid integration for bank linking and transaction ingestion
- Inter-bank transfer flow on Modern Treasury payment rails
- Event-driven queue layer on BullMQ holding p95 API latency under 100 ms
- User-facing ML classifier categorising Plaid transactions for accounting
- Staff and customer dashboards instrumented with PostHog
What changed.
- <100ms
- p95 API latency
- -30%
- Monthly cloud spend
Why these choices.
Idempotency keys on every webhook from day one, which is what held during a Stripe replay incident. Queued the slow paths rather than calling rails synchronously, so a degraded provider never shows up as a degraded API.