Today, Ramp raised $750M at a $44B valuation. Last time we grew this fast, we were 1/20th the size. For 2000 years, business was built on two pillars. Today, a third: intelligence. It’s your least governed cost. It’s also your single greatest opportunity.

Full article and profile by @LilyMaeLazarus is online here: fortune.com/2026/07/05/how-d…

Great @Fortune piece on @davidsenra today. Years ago, David kept texting me and @karimatiyeh to back a podcast with fewer than 1,000 listeners. "Trust me on this one." We did. That podcast became @tbpn. It sold to OpenAI this April and along the way did more for @tryramp's profile than any ad money could buy. What the piece gets right about David and mostly leaves between the lines: he's read 415 biographies of the people who got it right and he turned that discipline into a place the rest of us go to study. @FoundersPodcast isn't a podcast so much as a school for builders. It's why the founders I asked didn't describe it, they revered it. When you've studied the greats that obsessively, you can tell the sublime from the merely great — and you'll bet everything on the difference before the rest of us can see it at all. David earned that audience one obsessed listener at a time. Summarizing a book a week, alone in a room, scraping by for years before anyone was listening. The fame didn't change him. Neither did the money: he turned down $50M buyout offers to keep Founders his, and he takes no equity in the bets he sends others. For David, great work itself is always the point. The lesson I keep relearning from him: when you find talent like that, don't hedge. Back them completely. The returns aren't linear. Nothing better than watching a friend succeed. Grateful to be in business with him too — Founders Podcast, the new show, whatever comes next.

finetuning open source models has been hard to justify. why invest in tuning one when a better model ships within a month? our team just changed that. a finetune can now transfer from one model to the next at a fraction of the cost, radically improving the economics.

Today @karimatiyeh and I are both taking new titles as Co-CEOs of @tryramp. If you know us, this won't feel like a change. From when we first started building together twelve years ago, our partnership has run on a couple of motivating principles. On decision-making, we trust each other completely to make critical calls for the company across every function. And on organization design, technology is not a distinct part of the company - it is the entirety of it. That is why Karim has for years directly managed risk, operations, and marketing. Most importantly, at Ramp there is no line between the people who build and the people who do everything else. Everyone is a builder. For the last 2,656 days, we have run the company this way. This only makes it formal. We thought it was important to do it now because of how we see the AI exponential reshaping what Ramp can be. Decisions of company strategy are increasingly decisions of technology and systems design. We have always believed every function should be approached as a systems-engineering problem (even when the system was primarily human) but the rise of machine intelligence makes this existential. Every part of the company must be positioned to leverage the continued explosion in model intelligence and capabilities. If we do this well, each step-change in what models can do compounds automatically into better products and faster execution without anyone having to rebuild the company to capture it. If we fail to operate this way we will ultimately be outcompeted by a new company that does. We are also making Rahul Sengottuvelu our CTO. @rahulgs has led Applied AI at Ramp since joining us three years ago through the acquisition of his prior company, Cohere. Before that, his first company was building customer-service agents on GPT-3 at a time when almost no one knew what a large language model was, and he has spent every year since pushing the frontier of what existing models can do. He has also been right on nearly every major technical direction in AI well before it was obvious. Building Ramp now means applying AI to every part of it, and Rahul is the person stepping up to lead that work. We are still very early in the history of Ramp. Our current chapter is perhaps the most dynamic, but we have never been more optimistic on where it is going and the mission has never been more important. The businesses that trust us are navigating the same shift we are, and we intend to be there for all of it: managing their token spend, supercharging their finance teams, and helping them get more out of every dollar and hour. - Eric & Karim

1. as a mental model it is more correct to think of fable class models as english -> code interpreters - converts your idea into code into "correct" code regardless of problem complexity and output complexity (diff size). Fable 5 will be the worst of this new class of models 2. diff size/complexity is to be managed purely for review: small diffs - in high risk areas of code (auth/identity/data access/network access/money movement) large diffs for code that can be empirically verified (frontend/backend plumbing/code without network or db access/performance code that can be empirically verified) 3. time it takes to ship software is completely disconnected from time to produce the PR - how long the work takes depends fully on ability to review/merge code while managing risk at scale 4. solving the bottlenecks for above matter enormously- linters/testing/CI/shadow mode verification/empirical verification 5. agency matters enormously- what are the biggest bottlenecks to speeding up the loop and eliminating them? what are the problems that need solving and when do they need solving? what does it take to the solution to all of them today? 6. deep understanding of the full stack matters enormously- what problems are worth pursuing? is there a higher level of problem abstraction to address first? should I give it the sub-sub task, the sub task, or the task itself. what are the major risks with this PR (order of importance: security holes/correctness holes/performance holes). is there a higher speed way of producing data that allows me to merge this? should this be run in shadow or in a sandbox or a flag. understanding every line of logic may not be needed but understanding and managing risk matters enormously. 7. the cost of complexity itself is changing. it might be now worth "maintaining" 50% more code to get a 5% performance win. getting the right abstractions matter less because larger refactors are less tedious. code quality nits become huge drag. very likely, a much smarter model will be maintaining your code so worth taking on more technical debt now. taking the time to hand architect and rebuild systems comes with an enormous cost of velocity 8. if it quacks like a duck and walks like a duck, it's a duck. For low risk cases, it might be more sane to treat code chunks (services / functions) as a black box, like we do for neural networks: do full empirical verification only: has code produced correct outputs for the last 10,100,1000,10k inputs ? can we quarantine this large piece of code - no outbound access to network / database ? what happens when this code is wrong? do we get hacked/or crash(memory/cpu)/is an inconvenience? is it internal facing or external? what can we do to address these risks? 9. eventually, logical verification (line by line review) will come at an enormous cost- save it for where it matters and build systems that are tolerant to empirical verification. is there a decorator that prevents db / network access? correctness bugs are significantly easier to rectify than access bugs 10. what are the rails that allow for even faster iteration? code permissions can be opt in - db writes, db reads, network egress (to where?), PII access. how long does it take to get shadow mode data? how many PRs can be tested? What are the categories of diffs

public benchmarks are saturated. every frontier model has trained against them, and the leaderboard tells you near nothing. we built ours from inside ramp — code no model has seen, graded against the bar our engineers ship to. every company running on AI needs its own.

I grew up in Vegas. You learn to spot a slot machine...

Most companies raise to defend what they built. We raised because customers keep pulling us further. Accounting firms weren't on our core roadmap 6 mo ago, it's a $150B industry. AI spend mgmt didn't exist a year ago. Europe launches this year. Demand isn't the constraint. We're trying not to be.

As I wrote this, I saw X go into meltdown over tokens. You've seen the headlines: “Uber blows yearly AI budget in just one quarter.” “Meta employee burns 281 billion tokens in April.” But, the problem isn't spending. Spending works. Since 2023, the top quartile of our AI spenders doubled their revenue. The bottom quartile? Flat. It's blind spending. We don’t know which spend worked. A sales team has qualified leads. A support team has resolved conversations. These are units you can measure against. All a token tells you is the meter ran, not whether the work was worth it or not. Finance says, “half the budget,” engineering says, “double it” and you don’t know who’s right because there is no shared language of value. There’s no attribution, and no attribution means no allocation. For example, right now, all work, no matter the size or shape, defaults to frontier models. But meeting summaries and calendar updates don’t require GPT-5.5 Pro. In isolation this seems trivial, but re-route just 10% of a $10M AI bill from frontier to GPT-4 level intelligence you’ve saved nearly one million dollars. This sounds like a made-up stat — it’s not. It truly is that much cheaper. This is the future of finance: not blindly rubber-stamping or rejecting AI spend, but allocating it with the same rigor companies apply to headcount.

Thank you @nmasc_ and @RebeccaTorrenc5, appreciate the time and care you both put into this one bloomberg.com/news/articles/…

my meme team gets stronger with every billion. it's 44 strong now.

4,500 accounting firms already run on Ramp, including 92 of the top 100. We built Stack with our closest firm partners, for the work they do every day. Tag a CPA — we'll set them up with 3 months of complimentary access. ramp.com/stack

Stack learns your firm's playbook — how you close, how you reconcile, how you book journals for each client — and turns it into living SOPs. Then it runs them. Every action logged and reviewable. Early design partners are closing some clients' books in half the time.

Why this matters now: 300,000 CPAs have left the profession. Accounting degrees are at a 20-year low. Firms are turning away clients they can't staff. The winning firms aren't waiting for the talent market to fix itself. They're rebuilding around AI.

Introducing Stack. The AI operating system that lets accounting firms take on more clients without hiring. Learns your firm's process, runs the close, posts the journals. Fully auditable. We’re living through the biggest shift in accounting since the spreadsheet.

notes of automation, closed books, zero receipts

last time @tryramp grew this fast year-over-year, we were 1/20th the size ~170% TPV growth in March. growth usually decays with scale — ours re-accelerated on CNBC this morning with @carlquintanilla and @SaraEisen for the Disruptor 50

Scott Wu solved a Putnam problem in 90 seconds. beat Mango at Melee. raised from Peter Thiel over chess. I beat him at N64 Smash once. nobody's writing a Colossus piece about it, but I'd like it in the record.

two years ago i started screenshotting @pontusab and @viktorhofte's work. two designers in stockholm. 14k github stars. no marketing team. midday looked cleaner than every finance tool i'd ever seen. their obsession: let builders to run their company, not the admin. agents are finally getting good enough to make that real. they're joining ramp to build it. more soon.