Skip to main content

Is your next SaaS product just a textarea and a canvas?

There has been a lot of talk about SaaS platforms whose front page essentially just has a textarea for collecting the user's intent, and what comes after that is a canvas for the outcome.

Call these agentic or AI native startups, but I think there might be something in this pattern.

Most famous examples include Lovable and ChatGPT, but obviously, these will spread to other domains like legal, and I happen to know that some medical startup is also working on this.

So what's the big deal here?

Firstly, we can eliminate the endless form filling and table layouts. Not that there is that much bad in those - we are all used to them, and they play a part in making websites familiar and easy to use.

It’s more than the UIs become more personalized in the sense that you don’t need to squeeze all users through a funnel with forms that have tons of fields and tables or visualizations with dozens of variables.

The textarea approach flips this. Instead of asking users to fit into your data model, you start by asking a single question:

“What do you want to achieve?”

You start by querying the user's intent. What do they want to achieve in general with your product? Once you obtain that information, you can then utilize LLMs to gather more details and customize what your app shows.

A practical example. Let’s imagine we have a SaaS for some generic business reporting.

Instead of dropping users into a dashboard full of filters and empty tables, you start with a Lovable-style interface that prompts the user for what they want to do.

After that, you must show them something your product does - a sort of best guess, if you will.

Then, you start asking for more details. Here, we can utilize the good old HTML forms. LLMs are smart and can generate this pretty reliably. Many contemporary apps use a chat interface, which might be fine, but often a form can guide the interaction with the user more effectively.

This iteration can continue until the user is satisfied. The outcome in this case could be a report about a certain customer, where the eyewateringly complicated filtering is not done by clicking around dozens of dropdowns.

This flow feels natural, fast, and personalized. The user never has to think in terms of your backend models. You’re effectively priming the app to understand them before they ever hit “Submit.”

Then there is, of course, the usage after this. You want repeatability, and you likely don’t want the user to always hit that blank canvas and type the same “I want a report of yesterday’s sales for Acme.” You should not delete all those hundreds of thousands of lines of code defining the flows that are perfect for the power users.

LLMs are obviously non-deterministic, so building your business app fully reliant on them might not be what you want. The hundreds of thousands of lines of code that model a business process or a service are there for a reason. Mostly, you do not want any ambiguity or variance. The reason why a webshop forces you through a uniform funnel is obviously for business scalability, but also to ensure a salesperson does not give you too good or too bad a deal based on today's vibes (depending on which side you are).

The human “non-determinism” can provide much-needed flexibility to some parts of your SaaS app.

For example, customer support or onboarding flows could intentionally stay in this non-deterministic layer. An LLM-powered interface that interprets vague or incomplete user requests can feel far more human than a fixed decision tree. One user might type “I can’t find yesterday’s report,” another “sales report missing,” and a third “where did my numbers go?” and they should all reach the same place.

This kind of flexibility is powerful when you need empathy, personalization, or interpretation. It’s the part of your product where variation improves the experience rather than breaks it. You can let the LLM roam freely here, while the 500k lines of code that compose the safe, deterministic part of your system handle the actual business logic, billing, and data integrity.

Comments

Popular posts from this blog

Bird is causing high CPU on my macOS

There is no lack of people complaining about MacOS Tahoe, mostly about rounded corners and inconsistent design decisions. I have not paid that much attentention to that, but there is one mac bug i have paid attention to. It hasn't been a visual or ux but rather few system processes pegging the CPU. trustd , alongside with ecosystemd and ecosystemanalyticsd all reported high CPU usage. I can't exactly recall when this started, it might have predated my Tahoe upgrade but anyway, the trio of processes all had high CPU usage. Sure, it may have been the virtual efficiency cores and whether it affeced battery life or slowed down other processes i don't know to be hon...

I'm not a passionate developer

A family friend of mine is an airlane pilot. A dream job for most, right? As a child, I certainly thought so. Now that I can have grown-up talks with him, I have discovered a more accurate description of his profession. He says that the truth about the job is that it is boring. To me, that is not that surprising. Airplanes are cool and all, but when you are in the middle of the Atlantic sitting next to the colleague you have been talking to past five years, how stimulating can that be? When he says the job is boring, it is not a bad kind of boring. It is a very specific boring. The "boring" you would want as a passenger. Uneventful.  Yet, he loves his job. According to him, an experienced pilot is most pleased when each and every tiny thing in the flight plan - goes according to plan. Passengers in the cabin of an expert pilot sit in the comfort of not even noticing who is flying. As someone employed in a field where being boring is not exactly in high demand, this sounds pro...

How my work has changed in the past few years

When I started at my current job 3ish years ago, we had nothing but a few PowerPoint slides and a Figma prototype. I recall talking with one of the founders, whom I had worked with some 10 years ago, and pointing out that the very next step after PowerPoint and Figma was still the same as it had always been: translating those slides and mockups into CRUDs, forms, and other basic building blocks. Sure, all the new fancy tools and frameworks (we had jQuery then) help, but I still had to tinker with very basic primitives like tables and forms. I could not just say, "here is a table, here is a form." Well, yes, technically I could, but I still needed to write a lot of code to make a working form or table. This was around the time of GPT-3, Copilot beta, and very early Cursor. I did attempt to use them, but they could only perform very basic tasks and were pretty much useless for frontend work. We, being one of the first-wave "ChatGPT wrapper" startups has naturally pus...