Research-led / Slash API / Odoo prototype

Slash to Odoo, built from public signals and a mocked API.

A pitch artifact meant to show how I think: research the market signal, pick a real accounting target, and build around blocked API access instead of waiting for perfect conditions.

Demo

A weekend prototype, end to end.

This walkthrough shows the research path, the dummy Slash API, the sync flow, and the Odoo-side validation.

Prototype problem statement

A realistic path from Slash transactions to accounting truth

The integration replaces a manual accounting handoff with an automated path from card spend to expense records.

The workflow is simple: turn Slash-style card spend into accounting-ready records without CSV exports, manual re-entry, or a broken audit trail.

The target came from research, not convenience: conversations pointed to vertical expansion, healthcare stood out, and Slash’s own healthcare accounting content led me to Odoo after ruling out QuickBooks as already covered by a native integration.

What I built

The prototype shows how I close gaps.

Research depth, implementation judgment, and bias for action.

I built a Slash-to-Odoo sync that replaces a manual CSV handoff with an automated path: fetch transactions, map expenses, create Odoo records, and write a trace back to Slash.

The constraint was access. With no sandbox key, I used public docs and SDK shape to recreate enough of the Slash API to keep building.

Research narrowed the target

Docs, SDKs, hiring signals, and market research narrowed the prototype into one workflow worth building.

  • 01 Understood the public Slash API surface.
  • 02 Used healthcare research to pick the accounting use case.
  • 03 Validated against a local Odoo instance.

AI accelerated the workflow

AI helped me move faster, while the product judgment stayed grounded in the workflow.

  • 01 Synthesized docs and compared implementation paths.
  • 02 Pressure-tested idempotency, API gaps, and accounting handoff.

No sandbox key? Built anyway.

I recreated enough of the transaction and note-update surface to keep implementation unblocked.

  • 01 Modeled transaction fields and pagination.
  • 02 Added note patching for the full sync loop.
  • 03 Used the slash-sdk as a shape reference.

Why Odoo for this prototype

Odoo came from the healthcare accounting research path, then gave me a real system to test locally.

  • 01 Healthcare research pointed beyond QuickBooks.
  • 02 QuickBooks already had native Slash support.
  • 03 Odoo was open, relevant, and locally testable.

Safe create-only sync

The sync is conservative by design: safe to rerun and hard to duplicate.

  • 01 SQLite state plus Odoo-side markers.
  • 02 Re-runs avoid duplicate accounting records.

API gaps surfaced

The prototype also clarified what the public API does not expose yet.

  • 01 No public chart-of-accounts data.
  • 02 No accounting fields or analytic plans.
  • 03 No public sync-status surface.

How it works

From mocked Slash transactions to Odoo expenses.

Transaction data in, Odoo expense out, source trace written back.

1. Simulate Slash

Public docs and SDK types filled the sandbox gap.

2. Create the expense

Transactions are filtered, mapped, deduped, and created in Odoo.

3. Close the loop

The Odoo record ID is written back as the available sync trail.

Architecture flow showing Slash docs leading into a dummy API, filtering, idempotency, Odoo, note writeback, and known public API gaps.

Why Me

$768M+

Enabled $768M+ in annual customer spend across Ramp bill pay + card products by architecting and launching production integrations across 15 deployments.

Built Under Tight Deadlines

Scoped, architected, and shipped integrations while the sales deal was still open. The integration helped close the deal instead of simply following it.

0 -> 1

Direct customer-facing owner from discovery and technical scoping through architecture, implementation, deployment, and production launch.

Built Once, Scaled Forward

Designed integrations from raw APIs based on customer needs, then turned them into reusable systems: self-serve onboarding, repeatable workflows, and infrastructure that could extend beyond one-time implementations.

Contact

If this sparked the right kind of conversation, let's talk.

Based in VA, open to San Francisco or New York.

AK

Principles

Put oneself in as many uncomfortable situations as possible.