Owner.com Did an AI Rebuild to Accelerate Past $100M ARR. The 7 Top Lessons, and What It Takes to Copy Them

extract

Their own customer research said restaurant owners feared AI. It was three months old and completely wrong Adam Guild CEO of Owner.com gave one of the more useful operator talks at SaaStr AI 2026 this year: three years of rebuilding Owner.com around AI, from a website and online ordering product for independent restaurants into something where more than 83% of new customers now start their journey inside an AI product. They’ve rocketed past $100M ARR, growing at triple digits and faster than the year before I led the seed round at SaaStr Fund and am a board member, so I’ve watched most of this happen in real time. We just closed our growth round at a $2.3B valuation. So … it worked. Owner wasn’t slowing down when Adam made the call. It was winning. They were exceeding the triple triple double double trajectory and growing efficiently. The rebuild was elective. But it also wasn’t a week too late. The usual takeaway from founders is “be opinionated, automate the busy work, hire more builders,” which is … almost useless in practice. Here are the 7 things Adam did to move the needle for a vertical B2B / SMB leader starting to truly scale. The top things Adam did to rebuild Owner for AI: - Rebuilt the acquisition path, not the product features. Owner was 100% sales-led inbound: book a demo, talk to a salesperson, then an onboarding specialist. Grader replaced both with a free AI build that finishes in five minutes. - Made the free product deliver the whole outcome. A finished website, upscaled photography, generated video, and a full SEO and CRO audit, before anyone pays anything. - Inverted the engagement metric. Every login to fix what the software did is counted as a failure of the software. - Pointed agents at internal coordination. Owen absorbs about 90% of builder coordination work, and finance moved its primary artifact out of Excel and into Claude. - Kept building himself. Five products shipped personally in the past two months, by a CEO who had never written production code at Owner. #1. With AI, your customer should never have to log in In the old model, daily and weekly and monthly actives were the quality signal. Adam’s position now is close to the inverse. If a restaurant owner is logging into the website builder to manually fix how the software set up their business, the software failed and the customer is cleaning up after it. Waiting on log-ins and direct human engagement is holding up three other systems: - Your pricing unit. Per-seat and per-active-user pricing bill you for exactly the behavior you just declared a defect. If the agent works, seats stop being touched and your renewal conversation becomes an argument about shelfware. Owner is insulated because they take a cut of payment volume, so the money follows the restaurant’s sales rather than the restaurant’s clicking. If you’re on flat per-seat pricing, the metric inversion and your revenue model point in opposite directions, and one of them has to move. - Your growth funnel. Most activation definitions are some version of “came back within 7 days.” Most retention cohorts are login cohorts. Ship an agent that works and D7 return rate falls, and a growth team measured on that number will spend two quarters building re-engagement emails to drag customers back into a product they no longer need to open. - Your board deck. Engagement charts sit in every deck. A declining engagement line with no replacement metric next to it reads as churn risk, and you’ll spend the meeting defending rather than reporting. Owner’s replacement is outcome instrumentation, and they had to build it. Their lead qualification agent estimates gross payments volume for a restaurant it has never worked with to within about $250, before anyone talks to them. A company that can predict a prospect’s payment volume that precisely can also see, without asking, whether an existing customer’s sales went up after activation. #2. An LLM can build a website. But only Owner knows which version sells more food Grader checks roughly 90 SEO and CRO factors on a restaurant’s existing presence before it rebuilds anything. It crawls every place the restaurant appears on the open web, pulls in nearby competitors for comparison, audits the Google Business Profile for the settings, descriptions, and keywords that drive discovery, and reads the restaurant’s reviews to find what customers actually praise. The restaurant Adam demoed had a homepage consisting of a photo of napkins and the words “Welcome to.” Missing alt tags, broken SEO, no content. Under five minutes later it had upscaled photography, a generated video, dish spotlights built around what people were saying on Reddit and Instagram and Facebook, and full menu and bar sections. Ask Claude Code (or Replit or Lovable) to build that same site today and you’ll get something better than what most independent restaurants have. What the model doesn’t have: which of those 90 factors moved order volume, learned across thousands of live restaurant sites and the ordering behavior of tens of millions of consumers on them. Two different things get called proprietary data. A corpus is public, already inside the model, and worth roughly zero as a moat. Outcome data comes from your own deployments, closes the loop between a decision and a result, and compounds with every customer you add. It’s why restaurants keep the site: activating it raises their orders and their Google discovery. The opinionated product is the mechanism that produces it. Enforcing one system across every restaurant is what makes outcomes comparable across restaurants. Configuration flexibility destroys that. If every deployment is customized, you don’t have thousands of experiments, you have thousands of experiments with a sample size of one, and none of them tell you what works. Three questions to audit your own position: - Do you record what happened after the customer used the feature, or only that they used it? - Is the outcome linked to a specific product decision you made, or just to the account? - Is it comparable across customers, or did configuration make every row unique? If the answer to any of these is no, the “AI can’t copy us because we have proprietary data” line in your board deck is a corpus argument, and the model already ate the corpus. #3. With AI Moving This Fast, Customer Research Goes Stale in 90 Days. Or Less. Everyone at Owner.com repeats the Pizza Expo moment. Adam is at the booth demoing the website and ordering product when a pizzeria owner walks past him and starts scanning a QR code on a poster at the back, one a PM had brought as an afterthought, advertising a terrible MVP: analyze what’s broken about your restaurant online and fix it with AI. Joe, a 55-year-old pizzeria owner from Pennsylvania, was the most excited person at the booth. By the end of the day AI was the single most common thing owners wanted to talk about, at a booth where almost none of the collateral mentioned it, and they were asking how to use it to drive customer discovery and cut labor cost. The recap version of this is “trust your gut over the experts.” That’s the wrong lesson and it’s dangerous advice. Look at who was wrong. Discovery interviews three months earlier said restaurant owners were afraid of AI. Industry experts who had spent careers in restaurants said pivoting would alienate the customer base. They were wrong. Investors said this was CEO thrash and that a working, efficiently growing product shouldn’t be raided for an unproven one. Product managers said they personally knew a hundred customers asking for something else. Every one of those objections is correct reasoning from inputs that had gone stale, in a market where ChatGPT had just reset what small business owners believed was possible. The decay was invisible because the data still looked like data. Conviction doesn’t fix that. Cheap anomaly generation does. Stated preference said one thing, revealed behavior said the opposite, and revealed behavior was right. So keep one or two half-finished things where customers can move toward them unprompted, and watch the walking. #4. Your Devs Already Have Claude Code. Almost Nobody Has an Agent Handling Coordination. Build (or Buy) One. Every engineering team is already writing code with agents, and that’s the single biggest internal lift there is. Owner did that too. What’s unusual is that they also pointed an agent at the coordination overhead sitting on top of it. Owen handles about 90% of builder coordination work. It listens to GitHub, Slack, Notion, Linear, and Google Meet transcripts pulled from Gemini, and keeps the team aligned automatically, so Will, their strongest builder, stopped attending standups and chasing status updates to know where projects stood. As Grader took off and more engineers and PMs got added around him, Will had been spending his time on Linear hygiene and alignment meetings instead of building, which is the fastest way to lose your best IC. Owen also files the boring front-end work. Someone posts a screenshot in Slack saying the bullets in the agentic chat look too small. Previously that became a Linear ticket, then a front-end engineer hunting for the component. Now Owen calls Claude Code, which has full visibility into the codebase, and replies in the same Slack thread with a first-draft PR. No ticket ever exists. Their co-founder and CTO Dean built the same shape on the input side. The Product Insight Command Center pulls from Salesforce, Intercom, Momentum, TalkDesk, and call transcripts, and flags every time a prospect asks for a feature that doesn’t exist or a customer contacts support because of a bug. The build priority list assembles itself, replacing the hours per month Dean spent interviewing support, sales, and CS to reconstruct the same picture worse. The finance version is the most copyable and the least discussed. Their CFO Will and Meera moved the primary financial artifact out of Excel and into Claude about a year and a half ago. When an investor asks how Q3 rule of 40 compares to Q4, or how CAC has moved, Adam queries the model instead of saying he’ll follow up. All three are the same move: a senior person’s context assembly, automated. Coordination overhead is what makes a 40-person engineering org slower per head than a 10-person one. If agents keep the team aligned and hold the record of what was decided, what is the engineering manager for? Part of that job was context brokering, and that part is now automatable. Part of it was coaching and judgment, and no agent is doing that. Companies that automate the first and assume they got the second will find out in about a year. #5. AI Doesn’t Necessarily Make You Leaner. If You Have More Demand Than You Can Build For, Hire More Builders. A lot of CEOs came out of the last two years asking how many fewer people they need to hit the original plan. Adam thinks that’s the wrong question, and he’s right at Owner. His version: how much more could we build, how many more customer needs could we meet, and how do we compress ten years of roadmap into one or two? So Owner is hiring more high-agency builders. The reason it works there is specific. Owner sells to independent restaurants, a market of hundreds of thousands of operators, and they’ve barely scratched it. Kyle Norton joined as CRO at $2M ARR and they’re past $100M now, still accelerating. They have more demand than they can build for, and every builder they add turns into product surface aimed at customers already waiting. Plenty of companies don’t have that condition. If you’re growing 10% to 20% in a market that isn’t expanding, adding builders adds coordination cost against a ceiling. You get the meetings and the Linear tickets without the revenue. We run SaaStr with three humans and more than twenty AI agents in production, which sounds like the opposite conclusion and isn’t. We aren’t held back by how much product we can ship (or maybe … we are?). Owner is. Same technology, different answer, because what matters is what’s limiting you. Before you decide whether to hire builders or run leaner, answer one thing: do you have more customer demand right now than you can build for, even with Claude Code and Cursor running 24×7? If yes, Adam’s answer is yours. If no, more builders won’t fix it. #6. When Someone Says AI Saved Their Reps Time, Ask What It Did to Revenue “More than a 90% increase in call volume and rep time with customers” is an input metric. Their pre-call research agent kills the 20 to 30 minutes reps spent researching each restaurant before every demo, running the Grader report, surfacing the nearest successful customer as social proof, and estimating payments volume. Reps get more selling hours. That’s the mechanism. Bookings per rep is the result. CRO Kyle Norton’s session put it at more than $2M in ARR per rep on a $150K OTE, roughly 4x their direct SMB competitors, and over $100K in closed-won ARR per outbound BDR per month.That’s the number that proves the ROI on GTM AI. Ask for it any time you’re handed activity data. #7. Measure How Long It Takes You to Go From Customer Complaint to Shipped. Owner Did It in a Day. Juliana Vasquez, who owns Somos Oaxaca, told Adam on a Friday that she’d spent $2,000 and half a day on a commercial photo shoot, then added new items for spring and couldn’t afford to bring the photographer back. Her iPhone photos looked bad enough next to the professional ones that she almost didn’t want to put the new dishes on her menu. By Saturday afternoon Adam had built Owner Photographer. Upload the photo, pick a style, and about 30 seconds later a chain of models describes the image and passes it to Nano Banana with anti-prompts that keep the food from going uncanny. Juliana’s blurry taco photo comes back matching the exact style she’d paid $2,000 for. Hundreds of customers use it now. Adam had never written production code at Owner before this, and has personally shipped five things in the past two months. Friday complaint to Saturday afternoon, in production. Call it customer-to-feature latency. At most B2B companies that number is a quarter, and almost none of the delay is coding time. It’s intake, prioritization ritual, a roadmap already committed, and the fact that whoever heard the complaint has no ability to act on it. Measure yours. Take the last five things you shipped, find the date a customer first said the words out loud, and count the days. Then look at where the days went. That number will tell you more about how AI-native you are than any agent count, and you can start measuring it without rebuilding anything. What Almost Went Wrong, And What Owner Could Have Done Faster and Better They’re three places where his own account shows the outcome turning on something fragile. - The signal arrived by accident. The poster that changed the company was brought to the Pizza Expo by a PM as an afterthought, advertising an MVP Adam calls embarrassing. Nobody planned the experiment that produced the most important data point in Owner’s history. - The research process failed and nothing caught it. Discovery interviews three months earlier said restaurant owners feared AI. That answer was wrong and stayed unchallenged until a trade show accident overturned it. There was no cheap, continuous mechanism for catching a stale finding, which is the thing worth building before you need it. - The coordination fix came after the damage. Owen got built because Will, their strongest builder, was already suffering, buried in Linear hygiene and alignment meetings as the team grew around him. That’s the standard pattern and it’s reactive. The predictable version is that every great IC gets buried the moment you staff up around them, and you can build the agent before you watch it happen.