How SaaS Founders Are Actually Using AI Right Now

A question came up on a recent call that I think about a lot: are your peers using AI the way your team is, or are you ahead of them? The founder who answered had a good response. He does not consider himself the vanguard, but he is confident he is pushing the boundaries harder than most, and when he looks at his own peer group, most of them are still using AI as a chatbot. They open a window, ask a question, copy the answer out, and go back to work.

Another founder in the conversation put a sharper edge on it. He described being in a bubble, then talking to people still sharing a single twenty-dollar account across a whole team, and realizing that far more companies are in that world than in the one he lives in. The gap between how the most aggressive companies use these tools and how the median company uses them is enormous right now, and it is producing real differences in output. Here is what the aggressive end actually looks like in practice.

Front of the house and back of the house

The most useful mental model I heard is splitting AI usage into front of the house and back of the house. Front of the house is anything customer-facing or close to the customer. Back of the house is engineering, data, and internal operations. Most founders have done something in one half and nothing in the other, and the ones getting real results have built in both.

On the front of the house, one member's team was early to AI note-takers on sales calls, which by itself is not remarkable. What they did next is. Their note-taking tool exposes an MCP server, so they connected it to Claude, and now the entire team can query past meetings directly. Anyone can ask what a customer said about pricing in March and get an answer without going to find a recording.

• Front of the house. Sales calls, CRM records, onboarding, support, and how you show up to the models your buyers now research in.
• Back of the house. Engineering, data pipelines, billing, and the internal operations nobody outside the company ever sees.
• Audit both honestly. Most companies have done something in one half and nothing in the other, and the untouched half is usually where the biggest gains sit.

Then they went further. They run a modified version of the MEDDIC sales methodology, with specific pain points they want surfaced, a specific way of identifying who holds the power in a deal, and a specific read on the age and stage of the prospect's problem. They trained the system to hunt for the answers to those questions inside every sales call and write them straight into the CRM record. When a call ends, the rep opens the record and the qualification framework is already filled in, ready for the follow-up. The tedious part of sales discipline now happens whether or not anyone remembers to do it, which is a much bigger deal than saving a rep twenty minutes of typing.

Building an org chart of agents

The framing I keep coming back to from that conversation is thinking about AI as an organization rather than a tool. This member's team does not think in terms of prompts, they think in terms of roles. They have a billing agent that runs their billing process and closes invoices every month, connected through their billing platform's MCP server. They have a project management agent. Back of the house, their data engineering pipelines are managed with AI assistance.

That shift in framing changes what you build. If AI is a tool, you look for tasks to speed up. If AI is a set of roles in your org chart, you look for functions to hand off entirely, and you design the handoff, including what the agent has access to and what it reports back. The word agentic has become a marketing term, but the underlying idea is real, and the companies that got there early did it by asking what job they were giving the thing rather than what task.

• Pick a repeating function, not a one-off task. Billing close, project status, meeting summaries, CRM hygiene. Things that happen every week and that nobody wants to do.
• Give it real access. MCP servers into your billing, CRM, and meeting tools are what turn a chatbot into something that can actually do the job.
• Define the output. The agent should produce something a person acts on, like a completed CRM record, not a wall of text somebody has to read.
• Put it in the org chart. Decide who owns the agent and who checks its work, the same way you would with a new hire.

The engineering side of the same company tells a similar story. Their developers have largely settled on Claude Code after trying alternatives, and when a new model dropped, the CTO rewrote an entire API in about a day and a half. This is a small, lean team that has been that way on purpose for years, and the founder's description of what happens when tools like this land in the hands of an already-strong engineer is that productivity becomes, in his word, astronomical.

Access and sharing are what make it stick

Two operational details from that team stood out to me, because they are the difference between a few power users and an actual company-wide capability. The first is that everybody has their own subscription. Not a shared account, not a license for the engineers, everybody. The second is that non-technical people are using coding tools too, because you no longer need the terminal. The desktop app opened that door, and their support and sales people use it. Their own developers are rarely in a terminal anymore.

The third thing they do is maintain a shared skill library. When someone builds a skill that works, it goes into the library and everyone can use it. That is a small piece of infrastructure that compounds quietly, because the alternative is that every person on the team solves the same problem alone, and nobody's good work escapes their own machine.

• Everyone gets a seat. Not a shared login, not engineers only. A person cannot change how they work on a tool they do not have.
• Skip the terminal. Coding tools now run in a desktop app, which is what puts them within reach of sales, support, and operations people.
• Keep a shared skill library. When someone builds something that works, it should be one click away for everyone else rather than trapped on their machine.

None of this is expensive relative to the payroll it affects, so cost is rarely the real obstacle. What holds companies back is that nobody has decided this is simply how the company operates now, and that is a leadership call rather than a budget one.

The uncomfortable part: the gap between good and great is widening

One founder raised something on the call that I think a lot of us are seeing and not saying out loud. Now that these tools genuinely perform tasks rather than just draft text, the distance between a good employee and a great one has become much more visible. Hand the same tools to both and the great one goes from being twice as productive to being an order of magnitude more productive, while the good one improves by a factor of three. Three used to be excellent. Next to a hundred, it does not read that way anymore.

He told us his company parted ways with two people for exactly that reason. They were good. Good was no longer good enough for what the business needed. I am not holding that up as a template, and I would encourage anybody in that position to think hard about whether the person was given real training, real access, and real permission to change how they work before concluding they cannot. But the underlying dynamic is not going away, and pretending otherwise does not help anyone.

• Give everyone the tools before you judge the output. A person cannot be an A-plus performer on an account they do not have.
• Change the job description, not just the toolkit. The expectation is shifting toward owning an outcome, not filling a specialist slot.
• Expect smaller teams with wider scope. The era of broad teams with narrow individual specialties is fading, replaced by people who own an area end to end.

That last point is the one I would sit with. What is coming is not simply that people do more with less, though that is true. It is that the shape of a role changes. Instead of a specialist who does one thing well within a team, you get a person who owns an area and an outcome, and who is expected to get there with tools rather than headcount. Whether that is exciting or unnerving probably depends on where you sit, but it is the direction of travel, and the companies that are already organized that way have a real head start.

Where to start if you are behind

If you read all of that and recognized your company in the chatbot description, the gap is closeable and it does not require a transformation program. Get everyone their own subscription. Pick one repeating operational job, something like the monthly billing close or CRM enrichment after sales calls, and hand it off properly with real system access. Start a shared library so that good work spreads. Then do it again next month with a different function.

The founders who are ahead did not get there through a grand strategy. They kept asking which part of the work a machine should be doing now, and they moved a little faster than they were comfortable with. That is the whole trick, and the window where doing it early is worth something is still open.