Engineer, Integrations + Design Partners
- Terms
- Paid trial project, then contract-to-hire. Equity when you convert to full-time.
- Location
- On-site in Duncanville, Texas
You’ll own the QuickBooks Online sync, get bookkeeping firms live on it, and watch them close real months on what you ship.
What you’ll own
- Our accounting-system sync layer: QuickBooks Online today.
- Getting outside bookkeeping firms live. You’ll set them up, watch them close real months, and turn what breaks into fixes.
- A weekly written log of what partners hit and what you did about it.
What you won’t own
Our lead developer owns the core product: the close workflow, the categorization engine, the data model, and infrastructure. Our sales lead finds and signs firms. You own the connectors and the partner’s first months on the product. When your work needs a core change, you propose it and the lead developer decides. Clear lines, few meetings.
This is an engineering role.
No sales quota, no support queue. You will talk to bookkeepers, because that’s where the bugs are.
How you’ll use AI here
- AI coding agents write a lot of the first draft. You write the tests that prove it and read every diff before it ships.
- You’ll use AI to read a new ledger API’s docs fast, map its fields, and draft sandbox tests.
- You’ll turn partner call notes into bug reports with AI, then check them against the logs yourself.
You might be a fit if you
- Have shipped a production integration with an accounting, payments, banking, or ERP API and kept it alive.
- Use AI coding tools every day and check what they give you.
- Write clearly and work well async (our lead developer is in Vancouver, BC).
- Like owning a problem end to end.
Bonus
- QuickBooks Online, Xero, or NetSuite API experience.
- You’ve worked in or with a bookkeeping or accounting firm.
How we hire for this role
A short written application, a 30-minute call, a paid trial project on a real integration problem, then a longer interview about your past work and a reference check. We read everything you send, so write your note the way you’d write a pull request description: what, why, and what you tested.