The problem
QuickBooks Capital could lend to small businesses, but only to businesses that already lived inside QuickBooks. Every partner that wanted to offer those loans to its own customers had no way in. The company decided to build an embedded lending product: the same loan, offered through a partner's platform, starting with Amazon.
I joined as one of the founding engineers on the team that had to make that real.
What I did
Built the application. I architected and developed the embedded lending web application with React and TypeScript on the front end and Java with Spring on the back end, deployed on AWS. This is the flow a business owner sees when they apply for a loan from inside a partner's platform.
Worked the seams, inside and outside the company. The loan onboarding experience already existed for QuickBooks users. Moving it into an embedded context meant working through API contracts with several internal teams that had never had to serve an external surface before. It also meant working directly with the Amazon team to establish the API contract between the two companies, the first time either side had built this integration. I owned the integration work assigned to me and kept the application flow seamless while the contracts changed underneath it.
Removed the daily chore. Testing the application meant filling in a long loan form by hand, five to ten minutes each time, many times a day, for every engineer on the team. I built a Chrome extension from scratch that fills the whole application automatically. A test now takes about five seconds. Between 25 and 30 engineers across the org use it every day.
Made the system observable. A new team had no alerting. I set up the first uptime and error monitoring and wrote the incident runbook, so the team hears about problems before users do.
Kept the team moving. I serve as Scrum Master for the newly formed team, running the sprint ceremonies and the delivery cadence.
Used AI tools on purpose. Claude Code and Cursor are part of my daily loop across the full stack. They help me move faster on the routine work, and I review what they produce as if a person wrote it.
What made it hard
Nothing about the product existed before. The contracts, the environments, the test data, and the alerts all had to be created at the same time as the feature work.
Part of that work crossed company lines. Establishing an API contract and the pipelines between Intuit and Amazon for the first time meant two teams with different systems, release processes, and expectations had to agree on one interface and keep it stable while both sides were still building.
The extension and the runbook were not on any roadmap. They came from noticing which manual steps the team repeated most and paying them down first.
Result
Phase 1 shipped to production with Amazon and serves about 2,000 QuickBooks users. Phase 2 targets about 8,000 users who are not QuickBooks customers, which is the whole point of the product: new customers reached through a partner. The longer projection is about 2 million customers outside QuickBooks as more partners come on.
What I'd do next
Make the integration partner-agnostic. Amazon was built as a first integration, with contracts and pipelines shaped by that one relationship. The next step is to turn that work into a partner platform: a documented integration kit, a sandbox environment, and contract tests on both sides, so a new partner can go live in weeks without a bespoke build. That is what moves the product from one partner to the 2 million customer target.
Smaller and sooner: turn the Chrome extension into a shared internal tool with a release process, and give the runbook a review after every incident.