Hey yinz! I'm starting a little experimental podcast, where I interview people that don't fit neatly into one box. The hope is to have forward looking conversations with entrepreneurs, artists, and researchers at the edges of their fields, and talk about what they're working on and what they're looking forward to. Each episode will be a 1-1.5 hours long recording and will result in one summary article and likely 2-3 more articles based on the content (+ more research). I'll be posting it all on my new Substack, Edge Cases, and here on Buy Me A Coffee. Still working out audio quality, format, and more but hopefully it'll be fun and interesting!
Quick Links:
🎙️ Audio recording + transcript
📝 Edge Cases Substack (please subscribe if you have Substack!)
Ep. 01: Reverse Engineering the Rules w/ Alex Klarfeld
I have a bad habit of romanticizing how people end up where they are.
As a person with many interests, who’s meandered from working as a software engineer for big tech companies to design and engineering consulting for early stage startups to working on science museum exhibits, I know the flipside of the phrase “the power of intention”.
So, when I meet someone who’s built two companies, I assume there was a plan. A specific moment where they looked out a window, had a revelation, wrote a 5 year business plan on a napkin, and started building.
Alex Klarfeld did not have such a moment.
Alex is the founder of Supergood, a company that builds unofficial APIs for enterprise software that either can’t, or simply won’t, give its customers programmatic access to their own data. He’s also a Carnegie Mellon alum, a former Cisco and SpaceX engineer, and one of the original founders of Divvy Homes, the rent-to-own housing company that was once worth a couple billion dollars on paper.
Such a stellar CV would imply that he was building up to the next big thing very intentionally, but he did not plan any of this. He just kept building things and opportunities naturally arrived at his feet.
Intrigued, I sat down with him for a friendly conversation of how one goes from not knowing what a startup is to suddenly founding two by accident.
Alex and I went to university together; he studied Electrical and Computer Engineering, and I Computer Science. Back then, I would have told you he was going to end up in hardware. He wanted to work on rockets. He interned at NASA in high school working on the Ares 1X rocket, the precursor to the SLS, then he interned at SpaceX while in undergrad. He owned all the dev boards and loved tinkering with electronics, but after watching many of his peers get into Y Combinator and move to California to work at startups, he felt the pull from his peers to the fast paced startup lifestyle:
“I wanted to work at a startup. I didn’t really understand what that meant. I just truly didn’t understand the concept.”
So, upon graduating, he joined a networking startup called Meraki as an embedded engineer, with the expectation being that he’d write very low level code for hardware. However, five days after he started, they got acquired by Cisco, and soon his job shifted more into application software development.
It was a common bait-and-switch for more hardware-leaning engineers back in the 2010s. They’re wooed over to the sunny, promised land of San Francisco with a 6-figure starting salary, told they’ll work on cool new hardware, and inevitably the hardware aspect of the company is dropped or is “solved” by the time you get there and you find yourself thrust into application development.
‘Twas the burgeoning era of Web 2.0 after all, and why would a company want to invest in the long cycle of hardware development when they could iteratively deploy to the web on a daily basis?
So, Alex stayed at Meraki for a year, then left to figure out what he actually wanted. He tried a few small startups that went nowhere. Then a friend from home who worked for a VC introduced him to HVF, a startup studio run by Max Levchin (Affirm founder, and esteemed member of the PayPal mafia coup that ousted Elon). The job: come in, sit next to an entrepreneur in residence and help build and validate their idea.
The idea that landed on Alex’s desk was a real estate idea for improving the ability of many to achieve home ownership. Alex was tossed a book about mortgages to read, and next thing you know Alex was the technical cofounder for a real estate company named Divvy Homes.
The premise was elegant: there’s a gap between renting and owning a house. What if you could help people close it? Divvy would buy homes outright, rent them back to tenants, and let each monthly payment build toward a down payment. Their primary customers were working-class people in the Midwest and South who were close to homeownership by most measures, but not quite there on paper.
At their peak, Divvy was buying a thousand homes a month. That’s thirty to forty houses every single day.
“Every day I would have standup. It was me, our data science lead, and our entire sales team. And we’d go through the houses one by one to make sure we paid the right amount of money.”
“Did we pay the right amount of money for forty houses today” is, in retrospect, a completely insane question to have to answer every morning. Especially during COVID, when the housing market went somewhere between irrational and unhinged and nobody had a handle on pricing, not even Redfin, Zillow, not anyone.
“The cost of buying 40 homes and paying more than we should have was costing us a couple million dollars a day. It was that kind of problem that you can’t really look up on Stack Overflow. You have to figure out an answer yourself.”
That’s the part of company-building nobody advertises. The biggest difficulties aren’t preparing the pivot deck or negotiating a term sheet. It’s those anxiety-inducing moments where the problem you’re faced with is genuinely new, there’s no playbook, but it’s your call and there’s millions of dollars on the line.
Divvy Homes went on to achieve the coveted $1 billion unicorn status two-fold, eventually being valued at $2 billion dollars. Alex learned to love real estate, but he was ready for something else. He left Divvy at this bright and shining peak to the shock of his colleagues and set his eyes on exploring credit scores and better ways to evaluate it to help open up the path to homeownership:
“All these folks had credit scores that are all over the place, but by all other accounts, they were very reliable tenants who were pretty close to homeownership. So I was actually playing with ideas in terms of this concept of what if there was a different way to evaluate credit.”
He started poking at it, but it was, by his own description, a tired idea. After all, everyone and their mom in fintech was trying to reinvent the credit score.
So he decided he wanted to start a side project instead. Something small that he could sink his teeth into while he noodled on what his true grandiose idea will be. Something that he himself would find useful.
Back at Divvy, Alex was the designated “computer guy” on vendor evaluation calls. Every time the ops or sales team wanted to buy a new piece of software, he’d get looped in with one question: do you have an API?
On one of those calls, he got his answer from a salesperson who was, in his words, the “most stereotypical sales bro you could imagine”:
“Do we have an API? Bro, you’re gonna LOVE our APIs. Our APIs are super good, man.”
When Alex finally got the API docs, it was “the worst thing you’ve ever seen: some sort of SOAP API with XML that’s half not documented.”
Not only did this experience frustrate Alex, his work at Divvy also exposed him to a plethora of API vendors doing expensive, unreliable things with no visibility into any of it. I think any of us who have worked in some capacity for a software company has had that pain, whether you have to deal with angry customers during a vendor outage or whether you find out your bill is 20x what you thought it would be because you accidentally went way over the standard rate limit and got charged for each additional call.
With this in mind, Alex started working on a tool that monitors and categorizes the API calls going out of a system and can tell you what’s charging too much, what’s breaking, what’s not doing anything at all. Of course, he codenamed this project “Supergood”: a pointed jab at that salesperson who ever so confidently sold him a terrible API. Only this time, Alex was determined to ensure his product truly was super good.
When he met with people, he started mentioning Supergood incidentally while pitching his actual credit score idea. “People really liked that,” he said. “And then I got, unprompted, a term sheet.”
I was floored. People don’t just receive unexpected term sheets! If anything, founders are often just trying to get in the same room as an investor to pitch an idea they’ve been noodling on for months or years, let alone get to a point at which they can negotiate terms.
But that’s the funny thing about this journey; when you’re a founder who just left a company that reached a $2 billion-dollar valuation in order to start something new, people look at you differently. It’s a whole other ballgame than raising money cold. Now, two for two, he found himself founding a company unexpectedly.
He took the term sheet and started building more seriously. He even hired a few engineers.
And at first, nobody bought the product.
“Pointing out problems with APIs is pretty much a nice-to-have. I think they call them vitamins, not painkillers.”
Months of that, and then suddenly he landed a customer who actually loved the product for reasons not fully understood. It turns out they were using Supergood to monitor a bunch of scrapers and unofficial integrations that powered their business. The real value wasn’t in observability, but rather the integrations themselves.
“I’m an engineer. So I was like, I’ll build more of these for you if you guys want.”
They said yes, and that was the pivot.
It’s a good pivot, but it’s also not as novel as it might sound, and Alex is the first to say so:
“I truly think that every company starts off by solving this problem in some specific way. Not even just the Plaids of the world (‘there are no APIs at banks so we made one’). Even Divvy, we were interfacing with Zillow because there were no APIs they would give to us.”
The unofficial API isn’t a workaround. It’s usually just how companies get started.
If you work in high tech as an engineer, a lot of the time you’re spoiled when it comes to integrations. Often the only APIs you work with are made for software companies and created and maintained by other software companies. The higher tech industry truly can feel like a strangely incestuous and self-contained ecosystem.
But most often aren’t so lucky. A lot of enterprise software doesn’t have an API. Or it has one, but you can’t access it. Imagine your company has been using this property management system or dealer management software or EHR for fifteen years. You have all your data in it, you want to automate something, and the software vendor either hasn’t built the access. Or worse, like a dragon protecting a hoard of gold, they actively block you from having access.
Supergood reverse engineers those portals at the network level. They create a service account, log in, record the button presses and network calls and page loads, map it to what they know about how login flows work (turns out, everyone builds them the same way), and spin up a clean REST API over the whole thing. Fully instrumented: if anything changes, if the underlying network calls shift, the system flags it and they can repair it.
“Once you’ve seen one ASP.NET platform, you’ve kind of seen them all.”
The part that’s easy to miss here is how different this is from the obvious alternative, which is browser automation. A lot of companies trying to solve the same problem point a browser at the portal and tell it to click through things. That works, functionally. It’s also slow, fragile, and completely useless at scale. If you’re trying to run twenty thousand API calls a month, spinning up a Chrome instance for each one isn’t a strategy.
Supergood cuts out the browser entirely. They’re only looking at the network calls underneath the visual layer. The thing humans see is irrelevant to them.
I asked Alex what Supergood looks like in two or three years, and he said he wants it to be self-service: any engineer should be able to sign up, point it at some legacy enterprise portal they’re stuck in, and have an API in a reasonable amount of time.
“The whole goal is to make the web fully interoperable. Efficiently interoperable.”
I like that framing. Not just connected, efficiently connected. The not-via-browser caveat is doing a lot of work there, and it’s the kind of distinction that only matters once you’ve actually tried to run things at scale and watched a browser-based solution fall apart.
Given that Supergood utilizes AI tooling to construct unofficial APIs, I was curious as to how Alex views AI’s place in the developer workflow, the future of work, and what skills are needed to start or advance a career in tech in today’s world.
Alex’s take on what makes a good engineer in 2025 is less about LeetCode and more about systems thinking: the ability to hold a complex system in your head, understand how the parts connect, and know where things break. Not because AI can’t write code (it obviously can), but because once the code is written by an agent, your job is to understand what it did well enough to know if it’s right. He sees the work of future IC engineers the same as those of tech leads in years past, except instead of leading teammates you’re leading LLMs to implement your architectural and product vision:
“In the world that you and I come from, there were two tracks, and a hybrid third. There was the IC, and then there was the manager. But there was always this intermediary role of the tech lead: an engineer who could go really deep on specific technical knowledge, but also had to pseudo-manage the people and the products and the features. Good systems knowledge, solid technical knowledge, good product instinct.”
But how does one hone that level of systemic thinking today? How do we stay sharp?
The theme he kept coming back to was debugging. Not in the narrow sense of fixing a bug, but in the sense of being willing to sit with something that doesn’t work and figure out why, without immediately reaching for another tool to do it for you. That’s what our CMU education beat into both of us, for better or worse. Hell, the motto of our university is “My heart is in the work.” You have to love the work and continue to fail until you figure it out.
“If you’re a junior engineer and you get stuck from vibe coding, power through. You’ll learn so much in just trying to figure out what’s going on and actually solving the problem.”
He also said something I’ve been turning over since. There are senior engineers right now who can’t keep up with AI-native junior developers. Not because the junior devs know more, but because they’re not fighting the tool. There’s a distinction worth naming here: I’d call it Code as Craft vs. Code as Tool. The engineers who built their identity around Code as Craft are having a harder time with this transition than people who always treated writing code as the means to a product end, not the end in itself.
Alex was always in the second camp.
So am I when it comes to building most products. If your end goal is a product that streamlines a process or provides a service to a user, coding is simply the tool to achieve it.
I asked Alex at the end what advice he’d give to anyone trying to start a company, learn, or build something right now. His answer was pretty simple:
“Find something that you’re uniquely good at, or have unique expertise in, or are uniquely passionate about, and go after that. I love reverse engineering. It’s fun. It’s also ended up being kind of weird, not everyone is going down this path, and a lot of people thought it was weird, and some people still think it’s weird. But it works out well. Don’t be afraid to go deep in something very specific that excites you.”
Alex didn’t set out to build a real estate company or an API company. He followed problems that interested him, built things that solved them, and let the market tell him what worked. It’s a messy, nonlinear process, and it’s also the one that seems to work.
What I took away from hearing this journey is that all the career strategy in the world, the networking, the intentional skill-building, the industry pivots timed to trends, might just be noisier versions of what Alex did: find the thing you can’t stop thinking about, and go embarrassingly deep on it. The market has a way of finding people who actually give a damn about their specific weird thing. It found Alex twice.