I wanted a pitch artifact that said more than “I can code.” So I picked a manual financial workflow, traced a healthcare angle, chose Odoo as the accounting target, and kept moving even without a live Slash API key.
The integration matters. The way I got there matters more.
Demo
This walkthrough shows the research path, the dummy Slash API, the sync flow, and the Odoo-side validation.
Problem
A real workflow, real API constraints, and a prototype target I could validate locally.
The problem is simple: customers do not want card spend trapped in one system while accounting is handled manually somewhere else. A Slash-to-accounting integration can replace CSV exports and manual re-entry with a cleaner path from transaction to expense record in real time.
From conversations with people at Slash, it seemed clear e-commerce was already a strong market, so I started looking at where expansion could happen next. Healthcare stood out through hiring and market signals, which led me to healthcare accounting blogs on Slash and ultimately Odoo, since it was open source, relevant, and something I could validate locally in a real environment. This was less about replicating an integration but more about validating how Slash could extend into more operationally complex verticals.
What I built
Research depth, implementation judgment, and bias for action.
The goal was to automate what could otherwise become a manual CSV handoff: fetch card transactions, filter and map them into accounting-ready expenses, create the records in Odoo, and preserve a sync trail back on the Slash side.
The blocked path was access. I did not have a Slash environment or sandbox API key, so I used the public docs and SDK shape to build a dummy Slash API that let me keep moving.
The project started with docs, SDKs, and market research, then narrowed into a specific workflow worth building.
AI was part of the workflow from research to implementation, but the actual product thinking stayed grounded in the problem.
I did not wait for an API key. I recreated the transaction and note-update surface closely enough to build against it immediately.
Odoo came from the research path, not just convenience: it appeared in Slash's healthcare accounting content and gave me a real system I could validate locally.
The sync is designed to be safe to rerun and conservative in behavior.
The useful part was not just building the happy path. It was identifying what the public API does not expose yet.
How it works
The prototype replaces a manual accounting handoff with a tested sync loop: transaction data in, expense record out, and a trace back to the source transaction.
1. Simulate Slash
Public docs and SDK types were enough to simulate Slash when sandbox access was unavailable.
2. Create the expense
Transactions are filtered, mapped, deduped, and created as Odoo expenses.
3. Close the loop
The Odoo record ID is written back to the Slash note because public sync status is not exposed.
Selected proof points
From sales calls and architecture to shipped systems and measurable fintech scale.
$768M+ in annual Ramp bill pay and card spend through deployed integrations across 15 customers.$768M+
Annual Ramp bill pay + card spend supported through integrations I architected and delivered.
Across 15 customer deployments.
15 Customers
Built and launched integrations across diverse financial workflows, customer environments, and operational constraints.
0 -> 1 Ownership
Took projects from sales call and technical scoping through architecture, implementation, and production delivery.
Business -> Build
Translated customer pain into architecture, developer execution, and shipped client-facing systems.
Contact
This draft keeps the contact surface intentionally light.
If this project resonates, I would love to walk through the research, the prototype decisions, and what I would build next.