I have been thinking through what it means to build software right now, especially as more of my own work has moved from "make a normal app" to "make something useful that an agent can also work with."
That sounds like a small change, but I think it changes the product question quite a bit. For a long time, the default SaaS model was pretty clear. You built a web app. Someone logged in. They learned your interface. They clicked through your workflow. The value was wrapped inside that experience.
There is still a place for that. People need settings, permissions, billing pages, audit history, admin views, and all the normal parts of software that keep a product usable. But I do think the center of gravity is moving. A lot of the people who are early to this next wave are already spending serious time inside ChatGPT, Claude, Codex, Claude Code, and similar tools. If you are running a business, those tools are becoming a real workspace, not just a place to ask questions.
The reason that matters is delegation. Before this wave, the choice was usually either do the thing yourself or hire/pay someone else to do it. Now there is a wider middle area where you can have an agent do a meaningful amount of the work, especially if it can connect to the systems you already use. That changes what people expect from software. They are going to want the product to be reachable from the place where they are already thinking and delegating.
That is the lens I am trying to use for the things I am building.
The traditional workflow asks for a lot of attention
Most SaaS apps ask the user to come to them. That is just how we have built software for years. Go to the site, log in, find the page, click the report, export the data, move the data somewhere else, interpret it, then decide what to do.
That flow made sense when the app was the main place where the work happened. It feels different when the user already has an agentic workspace open all day. If I am in ChatGPT or Claude working through a business question, it is clunky to leave that context just to perform one narrow action somewhere else.
So the product question becomes more specific. Can the software still provide value when the user does not want to open the web app? Can it expose the right actions, data, and permissions so the user's agent can do something useful on their behalf?
I do not think that removes the need for a normal app. It changes the role of the app. The browser experience becomes one surface among several. It is the place for setup, review, control, and workflows that are better visual. The agent path becomes the place for the user to ask for outcomes directly.
Where the value actually sits
The "moat" conversation around software can get a little defensive. I understand why. If anyone can build more than they used to, it is natural to ask what protects the business.
I find it more helpful to start with the value question. What is the product actually doing that is worth paying for?
In 2026, the cost of making a digital thing has dropped a lot. The time and learning curve are much flatter than they were even a few years ago. That is a good thing. More people can build useful tools for their own needs. At the same time, it makes the old version of SaaS harder to justify when the product is mostly a thin workflow around basic data entry and reporting.
There is still a big gap between a prototype and a real product. I think that gets lost in a lot of online discussion. Someone can post that they vibe coded a QuickBooks replacement, and maybe they did build an impressive demo. But a demo is not production software. Production still means permissions, edge cases, data integrity, hosting, support, billing, compliance questions, backups, migrations, logging, and a bunch of unglamorous maintenance work.
That is where I think the value moves. Clean data boundaries, real business logic, dependable integrations, sensible defaults, and the willingness to keep the thing working after the demo is over. Those pieces are still valuable.
Build for bring-your-own-agent
One pattern I like is bring-your-own-agent.
Instead of trying to build AI directly into every product, you make the product available to the agent the customer already uses. The user brings ChatGPT, Claude, Codex, a local model, an enterprise agent, or whatever setup they trust. The product exposes the useful actions in a way that is callable, permissioned, and understandable.
That has a practical benefit for product builders. If I embed AI directly into my product, I inherit a lot of complicated questions. Which model provider am I using? What data is retained? Are prompts logged? Can the customer turn training off? How are sensitive requests handled? What happens when a user connects financial or customer data?
Those questions still matter with bring-your-own-agent, but the customer has more control over the AI environment. If they have an enterprise setup with the policies they need, they can use it. If they are comfortable with a consumer tool, that is their choice. If they do not want to use an agent at all, the regular app can still work.
That is probably the transition path I trust most. Do not force every user into an AI experience. Make the core service useful from more than one place.
FormulaFun as a simple example
FormulaFun is a good small example because it started as a hobby project with a very normal app shape.
Years ago, some friends and I wanted to run a Formula 1 pick'em league without using the official fantasy products. We had our own scoring style, did not want a bunch of ads, and did not need a heavy product. So we made a small app. You logged in, had a profile, made your picks, checked standings, and competed with friends.
When I brought it back up in 2026, I still wanted that regular web experience. It should be easy to make an account, join a league, make picks, and see results. That is the base product.
But I also found myself thinking that the more natural interaction might happen somewhere else. If someone is already in ChatGPT or Claude, they should be able to ask things like: what are my picks, who won our league last weekend, what were the finishing positions, how did my picks compare to the actual race, or make me a recap card for the group.
That is a different relationship with the product. The user is not necessarily browsing around the app. They are asking for the thing they want done. The app still needs to store the picks, score the race, manage the league, and produce the data. The agent just becomes another way to reach that capability.
Pricing gets harder to hand-wave
I also think this changes pricing.
People are tired of subscriptions, and a lot of SaaS pricing was built during a period when software was harder and slower to create. There are still legitimate recurring costs. Hosting, storage, support, payment processing, integrations, security work, and maintenance do not disappear. If the product uses models directly, usage costs can be meaningful too.
But the value has to be clearer. If the product is mainly a durable service layer that the user's agent can call, then maybe the pricing should look different. In some cases a subscription will still make sense. In other cases, a one-time fee, usage-based model, paid connector, or hosted plan might fit better.
I do not have a universal answer here. I just think builders need to be honest about the value being delivered. "We have a dashboard" is going to be less compelling when the customer increasingly expects their agent to interact with the underlying service directly.
What I am building toward
The phrase I keep coming back to is capability.
For an accounting product, the capability might be querying the GL, explaining a variance, preparing a reconciliation, pulling support, or drafting a client-ready explanation. For FormulaFun, the capability is collecting picks, scoring races, managing leagues, producing standings, and creating recaps.
The dashboard is one way to access those capabilities. An API is another. An agent connector is another. Email, spreadsheets, and other interfaces might also make sense depending on the product.
That framing helps me think more clearly about what to build. It pushes me to separate the useful thing from the surface it happens to appear in first. A good web interface still matters, especially for trust and review. But if the underlying service cannot be used by an agent, it may feel increasingly closed off from how people are starting to work.
The bet I am making is that more serious users will expect software to fit into their delegation layer. They will still use apps directly when that makes sense. They will still care about controls, security, and visibility. They will still need clean interfaces.
But when they are already working inside an agentic system, they will want to ask for the outcome and have the agent carry it out through the tools they have connected. For product builders, that means the real work is exposing a useful, reliable service that can be reached from the places where work is actually happening.
That is how I am trying to think about SaaS now. Build the normal app because people still need it. Build the service layer carefully because that is where the long-term value sits. Then make the important actions available to the agents users are already bringing into their work.
That feels like the direction software is moving, and it is the direction I want my own projects to move with it.
-Bennett