My bio lists two lines most people scroll past: 2010, "first startup — sold, learned what to never do again," and 2015, "led engineering on a fintech platform serving 30 million users." Both get a sentence and no explanation. That's a gap worth closing, because neither was a footnote — they're the two experiences that actually built the engineering judgment behind IMPT, four years before IMPT existed.
The startup that got sold, not scaled
The first company wasn't a failure in the way founders usually mean it — nobody lost their savings, the doors didn't close overnight. It was sold because we ran out of a better option, and the reason we ran out of a better option is the part worth telling. We built the product before we'd nailed down who was paying for it. We had users, we had engagement, we did not have a repeatable answer to "why does this specific customer hand over money, and will they do it again next month." By the time that question became unavoidable, the runway to answer it properly had gone. A sale was the responsible exit, not the ambitious one.
The lesson wasn't "validate before you build," which is a slogan, not an operating rule. The actual rule I took from it is narrower and harder to violate by accident: never let the codebase get ahead of the unit economics. If I can't draw the loop — what the customer pays, what it costs to deliver, what makes them pay again — on one page, I don't get to add the next feature, no matter how obviously good it seems. IMPT's carbon-offset model exists because of this rule specifically: the offset is funded from IMPT's own commission, not billed as a surcharge, precisely because a surcharge is a feature bolted onto a loop nobody had proven yet. Fund it from margin you already understand, or don't ship it.
What breaks at 30 million users that never breaks at 30 thousand
The fintech role, five years later, taught the opposite lesson from the opposite direction. By then the unit economics were somebody else's solved problem — my job was keeping a payments and account platform correct and available for tens of millions of real account holders. At that scale, the failure modes stop being "the feature has a bug" and become "the system disagrees with itself." Two ledgers that should reconcile to the cent, and don't, at 2am, with real money sitting in the gap. A retry policy that's individually correct and collectively duplicates a transaction under load. A migration that's fine for 99.97% of accounts and produces a support queue of edge cases for the other 0.03% — which, at 30 million users, is still nine thousand people.
The specific thing I carried out of that job wasn't a technique, it was a posture: treat reconciliation as a first-class system, not a cron job you bolt on afterward. Most teams build the feature, then build a script that checks the feature worked. At scale that ordering is backwards — the checking system needs to be built with the same rigor as the thing it's checking, because it is the only thing standing between a silent data error and a very loud, very public one. I watched incidents get caught in minutes because reconciliation was taken seriously, and I watched near-misses in adjacent systems where it wasn't. That difference is the entire reason IMPT's carbon-retirement records are written the way they are — each retirement is hashed and made independently checkable, deliberately not "trust the dashboard," because a dashboard is exactly the kind of thing that quietly drifts from the truth while still looking fine.
The trade-off nobody warns you about
Here's the part that doesn't fit neatly into either war story: the two jobs taught opposite instincts, and knowing when to apply which one is the actual skill. A startup rewards moving before you're sure — ship the smallest thing, watch what real people do with it, throw away the parts they ignore. A 30-million-user platform punishes exactly that instinct. Move before you're sure at that scale and you don't get a cheap lesson, you get an incident review with legal, compliance and a support queue attached. Nobody had told me, going in, that "good engineering judgment" isn't a fixed setting — it's knowing which of two genuinely contradictory instincts the current stage of the business needs, and switching deliberately rather than defaulting to whichever one you learned first. Most of the bad calls I've watched other founders make weren't a lack of skill; they were the startup instinct applied at platform scale, or the platform instinct applied when the company still needed to move fast and cheap.
Two lessons, one architecture
Put the two together and they stop being war stories and start being a design brief. The startup said: don't build ahead of a proven loop. The fintech platform said: whatever you do build, verify it independently of itself, because scale finds the gap between what you think is true and what's actually true. IMPT's architecture is a direct answer to both.
- Lean by design, not by accident. The team is small enough to fit around a dinner table for a platform spanning 8 million hotels and apartments across 195 countries — not because hiring is hard, but because the 2010 lesson says every additional person is another feature-shaped commitment, and I only want commitments attached to a proven loop.
- AI agents instead of headcount for the operations layer — sales conversations, follow-ups, scheduling, content — covered by systems built with the same verified-action discipline the fintech platform demanded of its ledgers: no unverified claim goes out, no state change happens without a check.
- Protocol-first, not feature-first. Territory ownership, carbon retirement, revenue share — each is specified as a rule that has to hold everywhere, the way a ledger reconciliation rule has to hold for every account, not case-by-case exceptions layered on top of a feature.
Neither experience was glamorous while it was happening. Selling a startup you built feels like a loss even when it's the right call. Reconciling ledgers at 2am is not a founder-story anecdote, it's just the job. But the two together — one teaching me to distrust an unproven loop, the other teaching me to distrust an unverified system — are why IMPT looks the way it does: a small team, a protocol instead of a headcount plan, and a rule that nothing ships until it can be checked against reality, not just against itself.
Common questions
What was the fintech platform Michael English worked on before IMPT?
In 2015 he led engineering on a consumer fintech platform serving roughly 30 million users — a payments and account system where reconciliation correctness and uptime carried direct financial consequences, not just inconvenience.
What happened to his first startup?
Founded around 2010, it was sold rather than scaled independently. It taught him what to never repeat: shipping before the unit economics were understood, and building features before establishing who the customer actually was.
How did those two experiences shape IMPT?
They produced three standing rules at IMPT: reconciliation is a first-class system not an afterthought, ship the smallest provable loop before the vision, and put verification ahead of headcount so a lean team can safely run a platform spanning 8 million hotels and apartments across 195 countries.