Skip to content
FaxterBook a diagnostic

Essay

18 min readBuilding Faxter · Part 6

Our First Reseller: How a British Company Found Clerk and What the UK Deal Looks Like

How a deal that died two years ago came back as a UK reseller partnership — and what it taught me about product versus platform.

  • Company
  • Partnerships

The deal I just closed this week started as a deal that died two years ago.

I want to lead with that sentence because it is the most important thing in the essay, and also because it is the kind of thing I would not have believed if someone had told me it was going to happen. The conventional wisdom about startup relationships is that dead deals stay dead — you pitch, they pass, you move on, both sides forget, and the relationship defaults to zero. That is usually true. What is also true, and much less discussed, is that the conventional wisdom is about the deal, not the people. Deals die all the time. The people on the other side of a dead deal sometimes keep thinking about you, and sometimes resurface, and sometimes — if you are very lucky and have done the slow, unglamorous work of staying in touch without asking for anything — they come back with a completely different problem and ask whether the new thing you happen to be building solves it. That is what happened here, and I think the shape of the story is more instructive than the terms of the deal itself, so I want to tell it properly.

The company that almost hosted on Faxter

I’ll call them the Partner. They are a British ERP SaaS company, and I am keeping their name out of this essay because the deal is still fresh and I would rather write about what I am learning from it than about who they are. They sell accounting and back-office software primarily to small and medium businesses in the UK, and through an Africa representative they have been exploring expansion into the Nigerian and broader African markets for a while. Their Africa rep is a friend of mine — also one of the early investors in Faxter — and that relationship is where this whole story starts.

Back in the Faxter years, the Partner had a specific problem: they wanted a hosting partner in Africa. Their European infrastructure was fine for European customers, but serving African customers from a European data center produced the latency and data-residency issues you would expect, and they were trying to solve it by placing instances with a regional cloud provider who could give them decent connectivity, local hosting, and an actual human on the ground to talk to. We were exactly that provider. Faxter had the data center, the public cloud platform, the team, and — through our mutual friend — the direct line to the Partner’s leadership. The conversations were encouraging. The technical fit was real. For a few weeks it looked like Faxter’s first serious enterprise tenant was going to be a UK ERP company placing its African workloads on our infrastructure.

Then Faxter wound down. I wrote about this in the first essay in this series — the short version is that the capital-intensive bet on a regional cloud did not pay off fast enough to justify continuing to burn on it, and we made the hard decision to shut the business before we dragged it out. That decision killed the Partner hosting deal along with everything else. I had to call our mutual friend and tell him that the platform the Partner was about to host on was no longer going to exist. It was one of the more embarrassing calls I have made in my career, because the embarrassment was not about having failed — everyone fails — but about having recruited a serious customer into a platform that I was about to dismantle. I apologized. Our friend was gracious. the Partner was disappointed but understanding. The deal died.

Here is the part that matters. After that call, the relationship did not die. I kept in touch — not frequently, not systematically, not because I had any plan, but just because these were people I liked and respected and I wanted them to know that the failure of Faxter the business was not a failure of the people who had tried to build it. I sent occasional updates. I mentioned things I was working on. I answered questions when they had them. I did not pitch, because I had nothing to pitch. I was focused on Microscale and then, later, on the accounting tool I was building for Microscale, and I had no expectation that the Partner would ever be a customer of anything I did again. The relationship was on autopilot, maintained out of habit and affection, costing me nothing and producing nothing.

This is the part of the story I want to linger on, because I think it is the piece most founders underweight. The relationship had no immediate value. It was consuming no effort. It was, by any rational startup-productivity metric, a waste of calendar space — a lingering connection to a dead deal that was going nowhere. If I had been optimizing my network, I would have let it fade. I did not let it fade, not because I was playing some long game, but because I do not think of relationships as resources to optimize. I think of them as people I know. And that turned out to be the thing that made everything else possible, because the moment I had something new to show, there was someone on the other side ready to look.

The moment the conversation restarted

The restart happened the way a lot of these things happen, which is to say through a third party and a casual mention. Our friend — the Partner’s Africa rep, Faxter’s former investor — was catching up with me on something unrelated, and I mentioned that I had been building an accounting tool for Microscale, and that it had turned into something more than an internal tool, and that I was starting to let other people use it. I said it in passing. I was not pitching. I was describing what I was working on because he had asked what I was working on.

He asked me to send him a link. I sent him a link. A couple of days later he told me the Partner wanted to see it. A few days after that we had a meeting scheduled. I prepared a demo the way I prepare all demos now, which is mostly by making sure Clerk was actually running and that I had some real Microscale data loaded in so I could show them the system working on a live business rather than on a fake one. I did not have slides. I did not have a deck. I had the product and a company running on it, which I have come to believe is worth more than any deck.

The meeting was today — earlier this same week that I am writing this essay, on April 9th, 2026. The meeting went differently than any sales meeting I have had before, and I want to be specific about how, because I think the difference is the thing I most want other founders to understand.

I have had a lot of sales meetings over the years. Faxter had many of them. The normal pattern of a sales meeting, even a good one, is that you spend half the time explaining what the product is, a quarter of the time answering objections about why it might not work, and a quarter of the time negotiating price while the buyer tries to figure out whether they can justify the purchase to their own internal stakeholders. A good meeting is one where the buyer leaves saying “send me a proposal and I will discuss it with my team.” A great meeting is one where the buyer leaves saying “send me a proposal this week.”

That is not what happened in this meeting. I showed the Partner the product — the AI agent, the document handling, the bank statement processing, the way you can drop a PDF into a chat and have the system reconcile your books in under a minute, the way the whole interface is conversational rather than forms-based, the way Microscale’s actual books tie out in real time on a live production system. I showed them maybe ten minutes of the product before the conversation changed shape. It stopped being a demo. It started being a negotiation. Somewhere around the fifteen-minute mark — I am not exaggerating, I checked the clock later — the Partner team told me they wanted to resell Clerk in the UK. Not “we are interested.” Not “let us take this back to the team and discuss.” An actual decision, made in the room, on the spot, before I had even finished showing them the product.

I want to be honest about what I felt in that moment, because I think it is diagnostic. I did not feel triumphant. I felt slightly alarmed. Sales are not supposed to happen that fast, and when they do, the default assumption should be that something is wrong — that you are going to have a failed implementation, or that the buyer has misunderstood what they are buying, or that they are going to back out once they talk to their colleagues. My training was to be suspicious of enthusiasm. I spent the next fifteen minutes actively trying to surface objections, the way you probe a tooth that doesn’t hurt to see if there is something underneath. I asked about their existing UK product, which overlaps with Clerk’s capabilities. I asked about whether they would prefer a deeper technical integration instead of a reseller arrangement. I asked about their customer commitments, their support obligations, their regulatory requirements under UK Making Tax Digital. I was trying to find the reason this was going to fall through, because I did not trust how well it was going.

The objections did not surface. Or rather, they surfaced and had answers. Yes, there was product overlap with their existing offering — but they saw Clerk as complementary, not competitive, because Clerk was targeting a smaller customer segment than their current ERP played in, and they had been looking for a way to serve that lower tier without building it themselves. Yes, they would prefer eventual deeper integration — but the reseller arrangement gave them a way to start now, validate demand with their UK customer base, and deepen the integration later without waiting on anyone. Yes, UK Making Tax Digital was going to require work — but it was finite, well-defined work, and they were willing to contribute the domain knowledge because their team already lived in that regulatory environment every day. Every objection had an answer, and the answers all pointed in the same direction: they had already thought through this deal before the meeting, and the meeting was not where they were deciding, it was where they were confirming.

By the end of the call we had agreed the broad commercial shape. A wholesale starter plan for small teams, with per-user tier pricing above it. Setup and onboarding sold at a day rate, with half-day and premium options. Support sold in packs of days that end customers could draw against. A setup fee to cover white-labeling and tenant provisioning. I am keeping the numbers out of this essay on purpose — they will evolve, and the shape matters more than the figures — but the structure was settled in the room, and the first pilot will launch against a roadmap I wrote up immediately after the call — branding system, sidebar restructure, pluggable LLM providers so the Partner’s customers can bring their own keys, EU hosting, Xero and QuickBooks push for Making Tax Digital. None of that roadmap existed before the meeting. It exists now because the Partner becoming a reseller forced it into existence.

What a reseller actually tells you about your product

I want to pull back from the narrative now and talk about what I am learning from this deal, because the value of having a reseller is not, or not only, the revenue. The revenue is useful. It is not the main thing. The main thing is that a serious reseller, especially one who operates in a different market than the one you have been building for, is the most honest critic of your product you will ever have.

Here is what the Partner has already taught me about Clerk, in the few days since the meeting, that I did not know before.

Clerk is more product-ready than I had been telling myself. I have been running Clerk for Microscale for months, and I have a long list of things I want to fix and polish and round off before I would be willing to “really” show it to a customer. Every founder has this list. Every founder’s list is longer than the product deserves. The the Partner meeting compressed that list, because I had to show the product in the state it was actually in, not the state I wished it was in, and the product in the state it was actually in was good enough to close a reseller deal in fifteen minutes. The polish list was real. The polish list was also not the bottleneck. There is a category of work I had been telling myself was required-to-ship that was actually not required-to-ship, and the reseller meeting is how I found out.

Branding is structural, not cosmetic. Before this deal, white-labeling had not been a category of work I was planning for. I assumed that when the time came, I would add a logo upload and some color variables and call it done. The moment the Partner signed on as a reseller, I realized that branding is not a feature — it is a structural property of the product, and it touches the database schema, the request routing, the email templates, the PDF generation, the public-facing URLs, and the multi-tenancy model. Every place in the codebase where I had hardcoded “Clerk” is now a place that needs to resolve a partner brand at runtime. I have been mentally treating Clerk as a single product with one name. It is now, as of this week, a platform that happens to ship with one default brand, and every line of code I write from here on has to respect that distinction. That is a significant architectural shift, and I would not have been forced to make it until much later — probably too late — if not for this deal.

Bring-your-own LLM key is a market requirement, not a nice-to-have. One of the first things the Partner asked, about forty minutes into the conversation, was whether their customers would be able to use their own API keys with their preferred LLM providers. Not for cost reasons — for data residency and vendor relationship reasons. UK customers wanted to know that they could run Clerk on top of OpenAI or Anthropic or a specific EU-hosted provider of their choice, because their own contracts and compliance regimes required it. I had been operating Clerk on DeepSeek primarily and treating the LLM choice as an implementation detail the user did not need to care about. the Partner made it immediately clear that in the UK enterprise market, the LLM choice is not an implementation detail — it is a procurement decision the end customer expects to control. So now Clerk needs to support pluggable LLM providers with per-tenant key management, and the router that currently reads from a global environment variable needs to read from a per-tenant configuration instead. Again: I would have gotten to this eventually. the Partner compressed the timeline from “eventually” to “immediately,” because they have customers who will not sign without it.

Hosting location is a feature. I had been hosting Clerk in the region that was cheapest and most convenient for Microscale, which is to say Nigeria and nearby. the Partner’s customers will need EU hosting for GDPR reasons. This was not a surprise — I knew GDPR existed, I knew data residency was a thing — but it moved from “I will deal with it when a customer asks” to “a customer is asking” in the span of one meeting, and the infrastructure work of offering region selection at tenant creation is now on the near-term roadmap. The lesson is not that I should have done this earlier. The lesson is that a serious reseller pulls the “when a customer asks” work forward by months, and you have to be ready to do that work in a compressed timeframe or the reseller deal stalls.

The Nigerian-first tax stack is not enough. I built Clerk’s tax capabilities around Nigerian VAT, PAYE, and CIT — the things Microscale needed — and I was vaguely planning to add other jurisdictions “later, when it mattered.” the Partner is the moment when it matters. UK Making Tax Digital compliance is a hard requirement for the Partner’s customers, and “vaguely planning to add it” is not going to cut it. The good news is that I built Clerk’s knowledge base to be pluggable for exactly this reason — tax rules are data, not code, and adding a UK tax regime is the kind of thing you load into a vector database rather than the kind of thing you rewrite. The bad news is that “pluggable” is still work, and the work has to happen on a pilot-launch timeline rather than a leisurely one.

The sidebar is too flat. This one I love because it is so mundane and so immediately actionable. the Partner’s team looked at Clerk’s sidebar — which currently lumps things like customers, vendors, invoices, and purchase orders into a single “Contacts” and “Transactions” bucket — and told me that no ERP customer in the UK would accept that. They expect Sales, Purchases, and Inventory as distinct modules. Quotes and Sales Orders and Invoices and Customers belong together under Sales. Purchase Orders and Bills and Vendors belong together under Purchases. It is obvious in retrospect. It is the kind of thing I would never have thought about because Microscale’s workflows did not require the distinction. A single meeting with a partner who has spent years selling to UK SMBs was worth more user research than I could have done in six months on my own. I wrote down the sidebar restructure the same evening, and it will ship in the first sprint of the partner-enablement roadmap.

There is a pattern in all of these lessons that I want to name explicitly: a reseller is not a customer; a reseller is a compressed, weaponized version of every customer they represent. When a single customer gives you feedback, you weigh it against all the other customers who have not given you that same feedback. When a reseller gives you feedback, the feedback comes with the implicit force of the entire customer base they serve, and you have to treat it that way. the Partner’s UK customers are not in the room. But the Partner is in the room, and the Partner will not close deals with their customers unless the product handles the things their customers will demand, and so every piece of feedback from the Partner has a customer count attached to it that a single user’s feedback never does. That compression is valuable and also stressful. You cannot cherry-pick. You have to treat the partner’s entire punch list as real requirements, because the partner is, in effect, presenting you with the aggregated requirements of a market you have not yet entered.

The two things this deal is worth more than

I want to end by saying, plainly, what I think this deal is and what it is not, because I am aware that writing about your first reseller is the kind of thing that can tempt a founder into overclaiming.

This deal is not a validation of Clerk’s business model. One reseller in one market is not validation. It is a signal, and a pretty strong one, but signals are not the same as models, and I would be lying to you and to myself if I pretended this deal proves anything about whether the BOS thesis will work at scale.

This deal is not a material revenue event. The numbers are real, the pilot will generate real money, but the size of an early reseller pilot in a single market is not going to move the needle on what Clerk needs to be financially. The revenue matters but the revenue is not why this deal matters.

What this deal is worth, in my current read, is two things that are much harder to buy than revenue.

The first is a compressed roadmap of all the work Clerk needs to do to be a real platform rather than an internal tool with other users bolted onto it. The partner-enablement roadmap I wrote up after the Partner meeting is the most valuable document I have generated for Clerk since the lessons-learned prompt that powered the original rebuild. It is the list of everything I have been politely not-thinking-about — branding, pluggable LLMs, region selection, EU data residency, Making Tax Digital, multi-tenant scaling, SLA commitments, status pages, partner portals — compressed into one ordered backlog with clear priorities. I could have produced a list like this by myself, but I would not have, because the things on the list are all the things that feel deferrable when you are serving only yourself. They stop feeling deferrable the moment you have a reseller. The list writes itself when the buyer is in the room with you, and that list is worth a lot more than the first few months of invoices.

The second, and the one I am more quietly happy about, is proof that the relationship work was not wasted. I spent two years keeping in touch with people from a company whose deal had died, for no reason beyond finding them worth keeping in touch with, and when I finally had something worth showing them, the door was already open. I did not have to find them. I did not have to build a relationship from zero. I did not have to convince them I was someone worth taking a meeting with. They already knew who I was. They already knew I built things seriously. They already knew that when Faxter died, I had handled the death of the deal well enough that they were willing to take another meeting two years later when a new product came along. That groundwork was invisible. It produced nothing for years. And then, in one meeting, it produced a reseller deal that is going to shape the next twelve months of Clerk’s development. I do not think this was luck. I think it was the natural outcome of the slow, patient, non-transactional work of treating people as people rather than as pipeline, and I want to name it explicitly because I think it is the kind of lesson that is easy to nod along with and very hard to actually live by when you are under pressure to ship.

If I have a single piece of advice to extract from this story, it is that one. The deals that die are not the relationships that die. If you handle the death of a deal with grace and keep in touch without asking for anything, you are building an option. The option has no value for a long time. Then one day you build something new, and the option is in the money, and the deal you closed in fifteen minutes is actually a deal you have been closing for two years, just in a form neither side could see at the time.

That is what happened this week. That is why the first reseller of the Business Operating System is a UK ERP company whose previous deal with me died two years ago on a different product. And that is what I would want any other founder reading this to remember: the failure that looks like an ending is often just the first move of a relationship that only pays off later. Do not burn the people on the other side of a dead deal. Keep showing up. Build the next thing. Let them find you again.

They might. Mine did.

Faxter

We build the co-workers this is written about.