# Web Apps Aren't Dead. The Front Door Moved to AI. > Your users can now ask an assistant instead of opening your dashboard. What that means for a SaaS founder, and the one thing to build. Source: https://boringpush.com/blog/web-apps-front-door-moved-to-ai ## The claim, and what it does not say "Web apps are dead" is a good headline and a bad description. Your app still stores the data, enforces the rules and takes the payment. None of that moves. What moves is the first step. Some of your users will begin a task by typing a sentence to an assistant, not by opening a tab and hunting for the right page. That is the front door. The building behind it stays where it is. ## How people used to reach your app The old route was simple. A user remembered your address, signed in, found the right menu and clicked through to the thing they wanted. Every step in that chain was your design work. Navigation, search boxes, filters, onboarding tours. All of it exists because a person has to find their way around. It worked, and it still works. But it asks the user to learn your layout before they get any value. ## How people reach it now Picture a customer who wants to know which feature requests are planned for next month. Today they open your app, find the board, filter by status and read the list. With an assistant, they type that question in plain words. The assistant fetches the answer and shows it in the chat. They never see your menu. For the user, this is faster. For you, it changes where your product gets judged. ## What this means for a founder If the assistant is the first place a user looks, then your app is only as useful as the assistant can make it. An app the assistant cannot reach is an app the user has to visit by hand. That is not a disaster. It is a quiet disadvantage, the same way an app with no mobile layout was a quiet disadvantage a few years ago. Three things follow: - **Your screens matter less as a map.** Users will still land on them, but fewer will wander through them. - **Your actions matter more.** "Create a post", "show my billing", "mark this as done" are the real product. A screen is one way to reach them. - **Your rules matter most.** If an assistant can act on your app, the permission checks behind it are what keep people safe. ## What to do about it: expose actions as tools The fix is not a new app. It is a short, named list of things your app can do, written so an assistant can call them. There is an open standard for this called the Model Context Protocol, or MCP. Its [own site](https://modelcontextprotocol.io/) describes it as an open-source standard for connecting AI applications to external systems. In plain words, MCP is a shared plug shape. If your app offers it, any assistant that supports it can connect without custom work on either side. ## What a tool list looks like A tool is one action with a name, a short description and the inputs it needs. For a feedback-board app, the list might be: - `list_boards`: show the boards you own. - `list_posts`: show the posts on one board. - `create_post`: add a post to a board. - `set_post_status`: move a post from open to planned to done. That is close to what BoringPush ships. Its server offers twelve tools in total, such as `whoami`, `billing_status`, `get_board`, `vote_post`, `add_comment` and `list_comments`. There is no tool that calls any address it likes. A small, fixed list is a feature. The assistant can only do what you wrote down. ## An example, labelled as one This is an illustration of the idea, not a recording from a real session. A user types: "What is planned on our roadmap board?" The assistant calls `list_boards`, then `list_posts` for that board, and answers with the posts marked planned. The user typed one sentence. They did not open a dashboard, and your app did all the real work. ## Why start from day one Adding tools late is possible, but it is harder than it sounds. By then your actions are tangled into page code, and nobody remembers which checks live where. If every feature already runs through an API route with a permission check, a tool is a thin wrapper on top. That is the same order we argued for in [CLI first](/blog/cli-first-saas-run-your-app-from-terminal): route first, command second, page last. A tool is one more caller of the same route. BoringPush apps are built that way, so the assistant connection exists from the first deploy. The setup is described in the [AI assistants docs](/docs/18-ai-assistants-mcp). ## Which assistants can connect You do not pick one assistant and bet on it. You offer a standard connection and let your users bring their own. Claude supports remote MCP servers as custom connectors. Anthropic's [help article](https://support.anthropic.com/en/articles/11503834-building-custom-connectors-via-remote-mcp-servers) says they work over Streamable HTTP, with OAuth or no authentication, on paid plans, and that the feature is in beta. ChatGPT also supports connecting to MCP servers. OpenAI documents the sign-in requirements for them, including OAuth with PKCE S256, in its [auth guide](https://developers.openai.com/plugins/build/auth). BoringPush follows those documented connector requirements. ## What stays the same Your database does not change. Your billing does not change. Your login does not change. The connection signs the user in with the same account they already have. It then runs through the same API routes your website uses, so ownership, scope and plan checks are the same ones. That is why this is a small project and not a rewrite. You are adding a door, not moving the house. ## What this does not fix A tool list does not make your product good. If your app does not solve a real problem, an assistant will just reach it faster. It also does not remove the need for pages. People will still want to see a chart, review a long list or change a setting with their own eyes. And it does not remove risk. Letting an assistant act on user data needs care, which is the subject of our post on [letting AI change your app data safely](/blog/let-ai-change-your-app-data-safely). ## A short plan for this week You do not need a big launch. Do these in order: 1. **Write down your five most common actions.** Look at what users do most, and what you do by hand for them. 2. **Mark each as read or write.** Reading is low risk. Writing needs more care. 3. **Make sure each one runs through a route with a permission check.** If it only exists as a page, move the logic out first. 4. **Offer the read ones first.** Add write tools once you trust the checks. 5. **Try it yourself.** Connect an assistant to your own account and ask it real questions. If you use BoringPush, steps two to four are already done for the boards, posts, comments and billing features: each action is marked read or write, runs through a checked route, and the read tools come first. Steps one and five are yours. ## FAQ ### Are web apps really dead? No. The data, the rules and the payments all still live in your app. What changes is that many users will start from an assistant, not from your homepage. ### Do I need to know how to code to offer this? Not to turn it on in BoringPush, where the connection is built in. If you build it yourself, you or your developer will write the tool list and the sign-in flow. ### Which assistants work with MCP? Claude supports remote MCP servers as custom connectors, per [Anthropic's help article](https://support.anthropic.com/en/articles/11503834-building-custom-connectors-via-remote-mcp-servers). ChatGPT documents how to connect MCP servers in [OpenAI's MCP guide](https://developers.openai.com/api/docs/mcp). ### Will assistants send me more users? We can't promise that, and we have no numbers to show. What we can say is that an app an assistant can reach is easier to use for the people who already prefer to ask. ### Is it safe to let an assistant touch my app? It can be, if access is read-only by default and writes need approval. We cover that in detail in the safety post linked below. Related reading: - [CLI First: If Your Agent Can't Run It, You Didn't Ship It](/blog/cli-first-saas-run-your-app-from-terminal) — build the route and the command before the page - [Control Your App From Claude (MCP)](/docs/18-ai-assistants-mcp) — the BoringPush setup guide - [How to Connect Your SaaS to ChatGPT and Claude](/blog/connect-your-saas-to-chatgpt-and-claude-mcp) — the step-by-step version - [Let AI Change Your App Data Safely](/blog/let-ai-change-your-app-data-safely) — read-only defaults and approval for writes