George Kurdin

The through-line

Kurdin's work is organised around a single deliberate bet: that the best use of a career is a large, boring, unsolved problem rather than a fashionable one. He and his co-founder were "very methodical about, you know, what we're going to spend our 40s on" [1][2], and the criteria were explicit: a massive market, no incumbent winner, and a genuine fit between the problem and what large language models can now do. Accounts receivable qualified on all three, being "a $3 trillion problem" that is "anti-hype" and "good for the world" with "no obvious category winner yet" [1][2]. The corollary he keeps returning to is a talent argument. He believes "some of the smartest people are not working on the right problems," and that a company attacking a huge unglamorous market can assemble a more talent-dense team than its competition, which is itself an edge [2].

The second recurring strand is method. Poker gave him expected-value thinking, and it shows up everywhere: in product bets, in go-to-market bets, in tolerance for risk, and in an operating rule that reversible decisions should be made at roughly 60% certainty and handed to customers to judge [2][3]. The third is craft under constraint. Because Monk touches revenue and customer relationships, he treats correctness as non-negotiable, which shapes both the architecture and the hiring bar [3].

On picking an anti-hype problem

The thesis was assembled deliberately rather than discovered by accident. Size came first, and Kurdin frames accounts receivable as a $3 trillion problem, and notes it extends beyond receivables into factoring [2]. Then came competitive structure: unlike code generation, where "cursor is obviously a monster," or CX, where a few strong players have emerged, receivables has no category winner [2]. Then technology fit, where he concluded it was "very obvious" that LLMs at the application layer could solve it [1][2]. Finally, the business had to be big enough to attract exceptional engineers and give them "an incredible experience building with us," a condition he says matters to him even in a scenario where the company never goes public [2].

The talent misallocation point is the one he presses hardest. People gravitate to consumer, as he did earlier in his own career, and leave supply chain and accounts receivable understaffed by the best builders [2]. That gap is both a social waste and a commercial opportunity.

Discovery was systematic. He and his co-founder Joe spoke with a little more than 100 CFOs and kept hundreds of pages of notes [2], and across sectors talked to finance and accounting leaders "an obscene amount of time" before honing in [3]. Rather than describing concepts, he built polished Figma mockups of five products as if they already existed, under the original company name Atlas, and asked prospects which they wanted [2]. Pain coalesced on AR. He was struck by how low the bar was: CFOs were paying six-figure annual contracts for tools whose entire value was pulling a sales lead's name from the CRM into a collections email, and finding that amazing [2]. High pain plus high willingness to pay settled it.

On why accounts receivable resisted software

Kurdin gives three reasons the function still runs on spreadsheets and email. The first is the nature of the problem, which he frames as relationships rather than "raw collections" [3]. Getting paid is more than sending a rigid email, because there are people and systems at the other end, contacts to find and maintain, and a commercial relationship to protect. Pre-LLM software could only encode rigid workflows, which is why it never fit [3]. He describes the practical mess with some relish: internal taxing as sales, post-sales, accounting and support all chase down who the right contact is, then after the invoice goes out come the W-9 requests, the demands to upload into Coupa or Ariba, the questions, the disputes about pallets that never arrived at the warehouse [3]. All of it drags on cash flow.

The second reason is data sensitivity. "We're never allowed to make a mistake," he says, because the company is "trusted to touch revenue and customers," and with LLMs in the loop "we can never hallucinate. We can never dispatch something incorrectly" [3]. Without an engineering-first team, he argues, that standard is unreachable, which is part of why nobody has succeeded. The third is integrations: whatever cash is collected has to be written back into NetSuite or whichever ERP the customer runs, and that plumbing cannot be brittle [3].

He also insists the emotional register matters. Collections work "has to get done with max empathy because these are ultimately my customers," and it is hard for a human to move from sending angry collections emails to sending happy partner emails, which is an argument for a system that handles it consistently [2].

On what broken receivables actually cost

The first-order cost is the net present value of money, worsened if the business is factoring or borrowing [3]. In practice he finds that when Monk partners with a company, somewhere between 5 and 10% of top line is sitting in the accounts receivable balance at 30 days or over, which he calls egregious given what that cash could be doing today [3]. The second-order cost is the opportunity cost of good people spending their time on back-and-forth instead of driving the business, plus the demotivation of doing the work at all. His summary is blunt: "people shouldn't be doing this stuff" [3].

On the other side of the ledger, he tracks time saved, on average more than 10 hours a week, though he concedes it is hard to measure and that the metrics differ across a customer base ranging from pre-seed to over $300 million in revenue [2][3]. The headline number is days sales outstanding, where customers see at least a 30% reduction, with extreme cases above 90%, typically an immediate jump in the first month and a half followed by a new equilibrium once the system settles [3]. Deployment runs three to four days, live in the same week, which he believes is fast for a billing provider [3].

On where the AI actually sits

Kurdin is precise about what is in production rather than what is promised. The core workflow he calls contract to cash: everything between a signed contract and money landing in the bank [2]. AI appears in three places. First, processing contracts through OCR, where Gemini and a rotation of other models have replaced open-source tools like Tesseract or offshore manual teams, with per-customer tuning [2]. Second, the reasoning and negotiating on collections, done "with like maximum empathy and professionalism," which he considers the special part [2]. Third, payment matching, so that when money hits the bank the system knows which invoice it belongs to, stops the collection sequence and updates the databases [2].

The intelligent collections module is the piece he claims as category creation, on the grounds that before it, collections was "just a robotic done email" [3]. Today it is email only, and he is unapologetic about that scope: the team is "extraordinarily good at email," at reasoning, shifting tonality, absorbing business context and multi-threading conversations, all of which he says was impossible before LLMs [3]. He also rejects the idea that model access is a moat, since competitors have the same API keys; the difference lies in deployment, guardrails, and the craft in the client [3].

On wrapping agents in a deterministic layer

The hardest technical problem, in his account, is diffusing frontier-lab progress into a domain with zero tolerance for error. He describes the application layer as a beautiful position, taking everything the frontier labs are investing in and handing it to customers, and puts Monk alongside Harvey, Arogo and Profound as businesses doing that diffusion [3]. The catch is that agentic actions have to be wrapped in a deterministic layer, because "you can't just let an agent send an email" when a customer sells into Apple or Ferrari or L'Oreal [3]. The answer is craft in the emails themselves, testing, internal benchmarks, and deterministic code that "hugs the agent code" [3]. He is candid that they are "scratching the surface of making this perfect" [3].

This is the same argument he makes about architecture generally: the power comes from building a compound solution at the app layer that gives agents enough context, which he calls "very very powerful for agents" [1][2]. He contrasts Monk's design choice with the norm in the category, saying most systems are built from the ground up on the general ledger, whereas Monk started with the relationship and the collections workflow, and spent its thinking on contacts, emails and guardrails to make collections context aware [3]. On the client side he brings consumer instincts from Minecraft, Streamlabs and Snapchat to the office of the CFO: software that is fast, modern, beautiful, and fully traceable so customers can see every action the agent takes [3].

On thinking in bets

The poker inheritance is expected-value thinking over results-oriented thinking [2][3]. He frames decisions as probability times payoff rather than the outcome that happened to occur, on the reasoning that "we can't control the world and just because you get a result doesn't mean that the attitude or the thought process that went into the product was bad," which lets the team take on more risk [2]. The corollary is a fixation on inputs and a willingness to detach from results, which he says matters especially for a small team [2]. He also pushes back on the idea that poker is mainly math or game theory: "a huge huge aspect of the game is just discipline," being cognizant of your mind state, putting in ridiculous hours, and playing enough volume for your edge to show, all of which he considers directly relevant to startups [3].

He applies the same frame to messy practical calls. Rebranding from Atlas to Monk was a bet rather than a cerebral exercise: atlas.com was priced at $12 million and the owner would not sell or take equity, there were around twenty Atlases already doing well in fintech, and when a broker surfaced a clean, scarce .com with gravitas he took it, reasoning it is easier to change early than to rewrite code paths later [2]. He also frames the whole company as a domain-crossing exercise, noting that poker, D.E. Shaw, the Minecraft in-game economy and creator incentives at Streamlabs all involved incentives, people and money, and that D.E. Shaw taught him about risk and markets while Minecraft and Streamlabs taught taste for people and product and how to ship ridiculously fast, because in consumer, Amazon and YouTube simply copy whatever you do [2][3].

On how the team is run

Monk's operating principles are manic urgency, ownership and craft, and clarity, and Kurdin's test for values is whether people actually practise them [3]. Ownership is concrete: whoever architects a module owns the front end and back end, and their decisions on it supersede everyone else's, including his own despite the title, because the person closest to the work is empowered to move fastest [3]. The meeting load reflects that. There is one all-hands on Monday morning and after that builders build [3]. He is equally firm against one-on-ones, saying he has not held them for more than a decade and doubts he ever will, because relationships are built by working with people daily on problems and showing care outside a scheduled slot, whereas a standing half-hour tends to become a forced status update. He offers the caveat that he could be wrong and would like to talk to someone for whom it works [3].

Speed comes from the reversibility rule: if a decision can be changed quickly, and it is not an architectural or hiring decision, ship at 60% plus certainty and let customers decide rather than debating model X versus model Y internally [3]. The team is LLM native and obsesses over using AI in every function, not only engineering but marketing, ops and finance, with a lot of in-house tooling to accelerate shipping, while holding the line that code touching customer revenue must be world-class [3].

He also publicly names the engineers who ship. He describes no ulterior motive beyond pride in an engineering-first, builder-first team, a belief that people buy from founders and that celebrating the builders matters too, and a specific wish for anyone who joins the founding team: that when they go on to raise money as founders themselves, there is a public trace of their work, with "your name and your fingerprints and your taste and decisions" visible in artifacts and backlinks [3].

On who Monk sells to

The go-to-market path was a correction. Kurdin started selling very large enterprise contracts and failed, in part because the company did not yet have SOC 2, then went all the way down market to seed, Series A and Series B customers, which is the focus today [2]. What that segment buys is time back. He observes that at seed and Series A the founder's ask is simply saving time and making their life easier, while more mature companies get reporting on top [2]. The pain he is solving is the fully manual chain many small teams still run: downloading a signed PDF, hand-keying an invoice in QuickBooks with items, discounts, dates and terms, creating the customer record, then relying on inflexible reminder emails at seven, three and one day out, then chasing overdue payers by hand every day with nudges [2]. Those dunning emails, he notes, are "archaic and boring" and nobody wants to open them, and humans make mistakes doing this work [2].

Takeaways

• Choose problems by explicit criteria: massive market, no category winner, real technology-problem fit, and a business big enough to attract exceptional engineers; accounts receivable met all four as "a $3 trillion problem" that is "anti-hype" [1][2].
• Treat talent misallocation as a competitive edge; because the best builders gravitate to consumer over supply chain or receivables, a talent-dense team in an unglamorous market outguns its competition [2].
• Accounts receivable resisted software for three reasons: it is a relationship problem that pre-LLM tools could only model as rigid workflow, the data is too sensitive to permit any hallucination or misfire, and ERP write-back integrations demand serious engineering [3].
• Quantify the cost of broken AR as the net present value of cash plus team time; typically 5 to 10% of top line sits in the 30-days-and-over bucket [3].
• Wrap every agentic action in a deterministic layer that "hugs the agent code," because an autonomous email to Apple, Ferrari or L'Oreal asking to be paid is unacceptable [3].
• Validate demand by showing polished mockups of several products that do not exist yet and letting pain coalesce; more than 100 CFO conversations pointed at AR [2].
• Run on expected value rather than results, and ship reversible decisions at 60% certainty rather than debating them, letting customers adjudicate [2][3].
• Give module owners decision rights that supersede the founder's, hold one all-hands a week, skip one-on-ones entirely, and name the engineers publicly when they ship [3].