Case study · AI + SaaS Products
Building an AI product around a real business workflow
The workflow already runs. It lives in a spreadsheet, a shared inbox, and the heads of the two people who know how it really works. Bolting a chatbot onto that does not make it a product. The work is turning the workflow into software people use, with the AI placed where it earns its keep inside the flow.
- 01Model the workflow
- 02Roles and permissions
- 03The screens
- 04AI in the flow
- 05Human decision
- Focus
- Operations-heavy teams running a daily workflow on spreadsheets, email, and disconnected tools
- Problem
- A workflow the team runs every day lives in spreadsheets, email, and tribal knowledge, with no software that fits how the work actually happens.
- Approach
- A product built around the workflow: a real data model, roles and permissions, the screens the work happens on, and AI embedded in the flow where a person would otherwise stall.
The problem
A team runs the same operational workflow every day. Intake arrives by email, the state of each item lives in a shared spreadsheet, decisions happen in a thread, and the parts that are not written down live in the two people who have done the job longest. It works, until it has to scale, onboard someone new, or survive one of those people being away.
The common first move is to bolt a chatbot onto the existing tools and call it an AI product. It does not fit the work. The assistant sits in a side panel while the real workflow still runs in the spreadsheet, so people answer the chatbot, then go do the actual job somewhere else. Nobody adopts a tool that sits beside the work instead of inside it.
The reality behind the problem
The obvious fix, add AI to what exists, skips the part that makes a product. The workflow has structure: entities, states, who is allowed to do what, and the specific moments where a decision gets made. None of that is captured when the AI is a side panel on top of a spreadsheet. The model can draft text, but it has no model of the work, so it cannot sit inside the flow where it would actually help.
The failure mode is adoption. A demo impresses in the meeting and then the team quietly goes back to the spreadsheet, because the spreadsheet is still where the work lives. Without a real data model, the roles the work already has, and the screens the work happens on, there is nothing for the AI to be embedded in. The product never becomes the place the job gets done.
What was assumed
We need to add an AI assistant to our tools.
What Stallwart asked
What is the workflow, who runs each step, and where inside it does a person actually get stuck?
The desired outcome
Before any AI was placed, the engagement defined what the software had to be for the team to run the workflow inside it rather than beside it.
- Model the real workflow: the entities, their states, and the transitions the work actually moves through.
- Give the work the roles it already has, so each person sees and does only what their part of the flow allows.
- Build the screens the work happens on, so the whole workflow runs in one place instead of across a spreadsheet and an inbox.
- Place the AI inside the flow, at the steps where a person stalls, not in a side panel bolted on top.
- Keep a person in control of every decision that carries consequence, with the AI drafting and the person approving.
- Make it adoptable: the software fits how the team already works, so moving into it is less effort than the status quo, not more.
The system we designed
Stallwart builds a product around the workflow, not a wrapper around a model. The work is modeled as software: a real data model for the entities the team handles, the states each one moves through, and the roles and permissions the work already implies. On top of that sits the interface the work actually happens on, the screens where items are triaged, reviewed, decided, and handed off, so the whole workflow runs in one place.
The AI is placed inside that flow, at the specific steps where a person would otherwise stall: drafting a response, classifying an item, summarizing a long thread, proposing the next action. A person stays on every decision that matters, approving or editing what the AI proposes. That is the standard Stallwart holds across every build: the AI assists inside the workflow and a human decides, with an auditable record of what was proposed, what was approved, and by whom.
How it works
- 01
Map the workflow, then model it
The work is traced as it really runs, including the steps that live in someone's head. That becomes a data model: the entities, their states, the transitions between them, and the roles that govern each step. The product is shaped around the actual flow, not around a generic template.
- 02
Build the screens the work happens on
The interface is the workflow made usable: the views where items are triaged, reviewed, and decided, scoped by role so each person sees their part. The goal is that running the workflow in the software is less effort than the spreadsheet it replaces.
- 03
Place the AI where a person stalls
The AI is embedded at the steps where it earns its keep: drafting, classifying, summarizing, proposing the next action. It proposes, a person approves or edits, and every proposal and decision is recorded, so the AI is inside the flow rather than a side panel on top of it.
How it works
From a workflow that lives in a spreadsheet to a product the team runs inside.
- 01
Model the workflow
Entities, states, and transitions as a real data model
- 02
Roles and permissions
Each person sees and does only their part of the flow
- 03
The screens
The interface the work actually happens on
- 04
AI in the flow
Drafting and classifying where a person stalls
- 05
Human decision
A person approves or edits, with the record kept
Each stage turns an informal step into software, with the AI placed at the step where a person would otherwise stall.
Architecture
What sits underneath.
Underneath the product run the same four layers as every Stallwart build, so a guarantee made in one layer holds across the whole system.
Intelligence
The model work sits behind the workflow steps that need it: drafting a reply, classifying an item, summarizing a thread, proposing a next action. Each is scoped to its step and given only the context that step holds, so the AI operates on the real state of the work rather than a free-floating chat.
Orchestration
The data model and state machine are the spine of the product: entities, their states, the transitions allowed between them, and the role required for each. The AI steps are wired into these transitions, so a proposal only appears where the workflow actually reaches that point.
Governance
Roles and permissions govern who sees and does what, applied at the data layer rather than hidden in the interface. Every AI proposal and every human decision is written to an audit trail, so there is a record of what was suggested, what was approved, and by whom.
Production
The product runs as software a team depends on: the screens, the services behind them, observability over both the workflow and the AI steps, and the ability to roll a change back. The AI is a part the team operates, not a demo wired on the side.
The hard parts
Where the engineering judgment was.
Model the workflow before placing any AI
The product is the workflow turned into software. If the entities, states, and roles are not modeled first, the AI has nothing to live inside, and it falls back to being a chatbot on top of a spreadsheet. The data model is where the product is won or lost.
The trade-off
Modeling the real workflow, including the parts that only live in people's heads, takes discovery and iteration up front, rather than shipping a generic assistant in a week.
Put the AI in the flow, not in a side panel
An assistant beside the work gets answered and then ignored while the real job happens elsewhere. Embedding the AI at the exact step where a person stalls is what makes the product the place the work gets done.
The trade-off
Each embedded step has to be designed and built into the workflow rather than dropped in as one generic chat box, which is more product engineering, spent on purpose because it is what drives adoption.
A person decides, the AI proposes
The workflow carries consequence: the wrong action sent to the wrong item is a real cost. Keeping a person on every decision that matters, with the AI drafting and the person approving, is what makes the product trustworthy enough to run daily.
The trade-off
Some steps stay a human approval that could in theory be automated, a deliberate bias toward a controllable workflow over full autonomy the team cannot yet trust.
Reliability & guardrails
How it avoids the wrong call.
The guardrails exist so the AI helps inside the workflow without ever making a consequential move on its own.
Human-in-the-loop on consequence
The AI drafts, classifies, and proposes, but any step that changes the state of real work or leaves the system waits for a person to approve. The default is a person in control, not an action taken automatically.
Confidence thresholds
Each AI step carries a confidence signal. Below the threshold, the proposal is flagged for closer review or routed to a person rather than presented as a confident default, so a weak suggestion never looks like a strong one.
Permission-aware actions
Roles are enforced at the data layer, so neither a person nor an AI step can act on an item outside the asker's scope. The workflow cannot be driven past a permission boundary.
Audit trail
Every proposal, edit, and approval is logged against the item and the person, so when an outcome is questioned the team can see exactly what the AI suggested, what a person changed, and who decided.
Productionization
What turns it from a demo into software.
What separates a product the team runs every day from a demo that impressed once in a meeting.
Evaluation harness
The AI steps are graded against a set of real workflow cases, so a change to a prompt, model, or classifier is measured against known-good behavior before it ships, not discovered by the team mid-shift.
Observability
Both the workflow and the AI steps are instrumented: where items sit, where they stall, how often a proposal is accepted or edited. When something is wrong, the team can see which step and which proposal produced it.
Rollback
A change to a model, a prompt, or a workflow step can be rolled back cleanly, so the team is never stuck with a regression in the software they run the business on.
Onboarding built in
Because the workflow lives in the software, a new person learns the job by using the product, with roles and the AI guiding each step, rather than by shadowing the one person who holds it all in their head.
What changed
The operational change is where the workflow lives. Instead of running across a spreadsheet, an inbox, and two people's memory, it runs in software: the entities are modeled, the states are explicit, each role sees its part, and the AI sits at the steps where a person used to stall. The team does the work in the product, not beside it.
Because the AI is inside the flow and a person stays on every decision that matters, the product earns the adoption a bolted-on chatbot never does. It fits how the team already works, so moving into it is the easier path rather than extra overhead on top of the old one.
- The workflow now lives in software people use, not in a spreadsheet and an inbox beside it.
- The AI is embedded at the steps where a person would stall, instead of sitting in a side panel nobody opens.
- A person stays in control of every consequential decision, with the AI drafting and the person approving.
- A new team member learns the job by using the product, rather than by shadowing the person who holds the knowledge.
Ownership & handover
What you receive, and keep.
At handover, the product is yours to run and extend, with nothing held back.
- Source code for the product: the data model, the workflow engine, the screens, and the AI steps.
- Infrastructure as code for the services, data store, and deployment.
- The evaluation set and harness, so you can keep grading the AI steps as the workflow grows.
- Runbooks for adding a role, changing a workflow step, and tuning or replacing an AI step.
- Documentation of the data model, the permission model, and where each AI step sits in the flow.
What we learned
The lesson that generalizes: an AI product is a product engineering problem before it is a model problem. The value is not in the chatbot, it is in modeling the workflow as real software, giving it roles and the screens the work happens on, and placing the AI at the exact steps where a person would otherwise stall. A tool that fits inside the flow gets adopted. One that sits beside it gets ignored.
This work connects to
- AI + SaaS Products
- Workflow software
- Human-in-the-loop AI
- Product engineering
- Production AI systems
Frequently asked
What does it mean to build an AI product around a workflow?
It means turning the workflow a team runs every day into software: a real data model for the entities and their states, the roles and permissions the work already implies, and the screens the work happens on. The AI is then placed inside that flow, at the steps where a person would otherwise stall. The product is the workflow made usable, with the AI embedded in it, not a model with an interface wrapped around it.
How is this different from adding a chatbot to our existing tools?
A chatbot bolted onto existing tools sits beside the work: people answer it, then go do the real job in the spreadsheet or inbox where the workflow still lives. Building a product around the workflow moves the work itself into software, with the AI embedded at the steps where it helps. The difference is adoption. A tool inside the flow becomes the place the job gets done; a side panel gets ignored.
Where does the AI actually sit in the product?
At the specific steps where a person would otherwise stall: drafting a response, classifying an incoming item, summarizing a long thread, proposing the next action. Each AI step is wired into a transition in the workflow, so a proposal only appears where the work reaches that point. The AI proposes and a person approves or edits, which keeps a human on every decision that carries consequence.
Why model the workflow before adding AI?
Because the product is the workflow turned into software, and the AI needs something to live inside. Without a data model of the entities, their states, and the roles that govern each step, the AI has no model of the work and falls back to being a chatbot on top of a spreadsheet. Modeling the workflow first is what lets the AI be embedded in the flow rather than bolted on beside it.
How do you make sure the team actually adopts it?
By building the software around how the team already works, so running the workflow in the product is less effort than the spreadsheet and inbox it replaces. The screens match the real steps, each role sees only its part, and the AI removes the friction at the points where people used to stall. Adoption comes from fit: when the product is the easier path, the team runs the work inside it rather than beside it.
Is your most important workflow still running in a spreadsheet and a few people's heads?
Show us the workflow. We build the product around it: the data model, the roles, the screens, and the AI placed where it earns its keep inside the flow.
Last updated: October 6, 2026