Fourth engineering hire, reporting directly to the CTO. A founding engineer builds whatever the company needs that week (product, infrastructure, tooling) because there is nobody else to hand it to, and works directly with whoever else is around; at that size, that was the founders themselves.
On one of my first days, I asked for four monitors as a joke. The next day, four monitors were set up on a dock at my desk, and we got to work.
The team started out as a few of us in a windowless room where IT used to store its overflow equipment. Later, once the company had more money, we got a weekly masseuse. Those were the days.
- Built the core platform matching homeowners who wanted solar with lenders willing to finance it.
- Built the loan application flow homeowners used, and the portal solar sales companies used to track their deals.
- Worked directly with the founders and execs, and with underwriting, business development, and marketing, to shape the product; there was no layer between engineering and the rest of the company yet.
- Helped decide what to build first: some of what we scoped in that room went on to generate well over $100M in revenue, which made prioritization the highest-stakes part of the job.
- Set up the foundations: created the GitHub repo itself, configured the first CI/CD pipelines, and documented the code quality guidelines the team still used years later.
Exciting and demanding in roughly equal parts.
Scaling partner onboarding
GoodLeap worked through partners: solar installation and sales companies at first, later every kind of home improvement contractor. Each partner got a website to hand their sales reps, a loan application that collected a homeowner’s Social Security number and other loan details, ran it through an automated credit pull, and came back with either a clean approval or a stipulation. A stipulation showed up immediately for the sales rep, who could tell the customer on the spot what document to upload through a link sent to their email. All of it happened in about two minutes on average.
Before this product existed, a homeowner who wanted solar had to take out a personal loan, notoriously high interest rates. We built our own loan product instead: low rates, and the packages were good enough that banks couldn’t buy enough of them.
Each partner’s application was its own HTML page: a folder in an S3 bucket with its own HTML, CSS, and JS, and that partner’s specific config (which loan rates they offered, among other things) hand-baked directly into the files. A separate layer of DynamoDB entries backed other partner config, things like bank account details. Partners typically ran two to five different application types, so onboarding one meant hand-building two to five of these pages. We were about a year into the business at that point, still solar only, and business development wanted partners onboarded faster than engineering could produce the pages. The onboarding backlog kept growing.
By the time Maxton Delaney and I decided to fix it, we already had over 300 of these pages live: 300 folders in S3, each one hand-edited enough times over the years that the config buried inside the HTML and JS wasn’t even formatted consistently from page to page, let alone the same from partner to partner. We spent a full weekend at my apartment on it.
- Wrote scripts to crawl every one of the 300+ buckets and parse the partner config out of the raw HTML and JS, working around years of inconsistent hand-edited formatting to do it.
- Modeled a new config schema in DynamoDB, so a partner’s loan application became a row of data instead of a hand-built page.
- Built a new web app that read a partner’s config out of that table and rendered the application around it.
- Solved the migration risk without touching a single live URL:
thousands of sales reps had these pages bookmarked on iPads they carried
into the field, so changing the URLs would have stopped their jobs cold.
Instead, we mapped each partner’s new config ID to the filename of their
original page, and had CloudFront strip the
.htmloff the incoming request and pass it to the new web app as a URL parameter. The same bookmarked link kept working; only what answered it changed.
Monday morning, we presented what we’d built at standup. That feeling, of walking in with something that impressive, is something we were both instantly addicted to. Between us we saved the company hundreds of thousands of dollars in salary and eliminated hours of manual work per partner onboarded. Application support no longer needed engineering at all to bring a partner online; from then on, support and business development ran it entirely through our internal tooling.
Nearly a decade later, it’s still one of the moments I’m proudest of, not just for the impact but for how much gratitude came back from almost every team at the company, since it touched everyone’s job in some way. It’s also what got both of us hooked on internal tooling. We went on to rebuild two of the company’s largest internal web apps, one used by underwriters and support, the other by partners checking loan status, into a single application called Origin. The idea actually came to me in a dream: we kept building the same feature twice across two separate apps, and there was no good reason they were still separate at all. Origin is still the company’s central operating system today.
Promoted from here into Technical Engineering Manager.