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

RocksDB data recovery

I recently needed to do some maintenance on a RocksDB key-value store. The task was simple enough, just delete some keys as the db served as a cache and did not contain any permanent data. I used the RocksDB cli administration tool ldb to erase the keys. After running a key scan with it, I got this error Failed: Corruption: Snappy not supported or corrupted Snappy compressed block contents So a damaged database. Fortunately, there's a tool to fix it, and after running it, I had access to the db via the admin tool. All the data was lost though. Adding and removing keys worked fine but all the old keys were gone. It turned out that the corrupted data was all the data there was. The recovery tool made a backup folder, and I recovered the data by taking the files from the backup folder and manually changing the CURRENT file to point to the old MANIFEST file which is apparently how RocksDB knows which sst (table) files to use. I could not access the data with the admin tool, ...

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...

PydanticAI + evals + LiteLLM pipeline

I gave a tech talk at a Python meetup titled "Overengineering an LLM pipeline". It's based on my experiences of building production-grade stuff with LLMs I'm not sure how overengineered it actually turned out. Experimental would be a better term as it is using PydanticAI graphs library, which is in its very early stages as of writing this, although arguably already better than some of the pipeline libraries. Anyway, here is a link to it. It is a CLI poker app where you play one hand against an LLM. The LLM (theoretically) gets better with a self-correcting mechanism based on the evaluation score from another LLM. It uses the annotated past games as an additional context to potentially improve its decision-making. https://github.com/juho-y/archipylago-poker