01 Intro
Most software strategy still talks like the war is fought on the screen.
Better UI. Cleaner dashboard. Faster command palette. Smarter chatbot. More integrations. More features.
That framing misses where the real lock-in happens.
The best software does not just give users a place to look. It gives them a place to start, decide, execute, hand off, check, and return. It becomes the route work follows.
That is the loop.
GitHub is not sticky because it stores code. It is sticky because issues, branches, pull requests, reviews, checks, merges, and deployments all orbit the same place.
Shopify is not sticky because it lets you create a storefront. It is sticky because products, orders, payments, fulfillment, refunds, apps, and merchant habits pile up in the same operating flow.
Stripe is not sticky because its API is nice, although it is. It is sticky because the messy parts of revenue live there too: subscriptions, retries, disputes, fraud, tax, payouts, onboarding.
The moat is not the page. It is the path.
02 What owning the loop means
A workflow loop is the repeated path where work moves from intention to result.
Someone starts something. A lead comes in. A bug gets reported. A customer places an order. A developer opens a pull request. A payment fails. A design is ready for dev.
Then the loop runs.
Context gets gathered. Someone decides what happens next. Work gets assigned. Another system gets updated. Someone approves or rejects the result. An exception appears. The team handles it. The next action begins.
Owning the loop means your product becomes the default place where that sequence happens.
Not the place where someone occasionally checks status.
The place where the work moves.
That difference matters. A tool can be useful and still be replaceable. A workflow owner is harder to remove because replacing it means rebuilding habits, permissions, automations, handoffs, reports, and all the ugly exception paths nobody documented.
The happy path rarely creates the moat. The weird cases do.
Failed payments. Rejected reviews. Delayed shipments. Approval chains. Changed requirements. Support escalations. Permission problems. Audit trails.
Once those live inside your product, you are no longer selling software. You are hosting operational memory.
03 A feature is too small
A feature can be copied.
A loop is harder to copy because it includes timing, state, roles, history, and trust.
A pull request comment box is a feature. GitHub's full review loop is the moat. The code changes, CI checks, reviewer comments, branch protection, merge rules, deployment hooks, and project references all sit close enough that teams stop thinking about the boundaries.
A bug form is a feature. Jira's state machine is the moat. Custom fields, statuses, transitions, automations, reports, permissions, and team rituals turn a ticket into a company process.
A checkout button is a feature. Stripe's revenue loop is the moat. The API starts the relationship, but Billing, Tax, Radar, Connect, disputes, refunds, retries, and payouts make the replacement painful.
This is why feature parity so often disappoints challengers. Matching the visible part does not match the operating path around it.
You can copy the button.
You cannot copy five years of team behavior around the button.
04 Owning the UI is not enough
Owning the screen means people look at you.
Owning the loop means work depends on you.
Those are related, but they are not the same.
Slack is a good example. The chat UI matters, but the real power is not chat. The power is that alerts, approvals, decisions, support pings, deploy updates, customer escalations, and random "can someone check this?" moments all land in the same channel structure.
Slack became the company's nervous system. Not because the message box was impossible to copy, but because everything started talking through it.
Figma followed a similar path. The original wedge was clear: browser-based multiplayer design. A link beat a file. Presence beat version chaos.
But Figma's deeper moat is now the design-to-development loop. Components, comments, branches, Dev Mode, annotations, ready-for-dev states, design systems, Jira links, GitHub links. The canvas became a handoff machine.
The UI got them in.
The loop made them hard to leave.
05 Systems of record are not enough either
A system of record stores the truth.
That sounds powerful, and often it is. Customers live in Salesforce or HubSpot. Orders live in Shopify. Inventory and accounting live in Odoo. Tickets live in Jira or ServiceNow.
But storing the record is only part of the job.
The stronger position is owning what happens next.
Who touched the record? Which step is it in? What approval is missing? Which automation fired? What exception blocked it? Who gets notified? What gets created after this?
That is where a system of record becomes a system of action.
Odoo is interesting here because it does not treat business functions as separate islands. A quotation can become a sale order. That can create delivery flows. That touches inventory. That can become an invoice. That ends in accounting.
The boring part is exactly the point.
The moat is the shared operational path, not any single screen in CRM, Inventory, or Accounting.
ServiceNow does this at enterprise scale. A request comes in. It gets routed, approved, worked, measured, and audited. The more departments connect to it, the less it behaves like an app and the more it behaves like company infrastructure.
At that point, replacement is no longer a product decision.
It is surgery.
06 APIs become stronger when they own loops
API-first companies complicate the thesis.
Stripe, Twilio, Plaid, and similar companies did not win by owning the main user interface. They won by disappearing into other products.
So is the loop thesis wrong?
No. It just needs precision.
An API can be a strong moat when it sits inside a high-frequency workflow. It becomes even stronger when it expands from a callable function into more of the surrounding process.
Stripe started as developer-friendly payments infrastructure. That alone was powerful. But the deeper moat came from moving up and around the payment event.
Checkout. Customers. Subscriptions. Invoices. Usage billing. Tax. Fraud. Disputes. Refunds. Payouts. Platform onboarding.
That is not just an API anymore. That is the money loop.
The same pattern explains why Zapier is strategically interesting. It began as cross-app plumbing. Trigger here, action there. Useful, sticky, boring in the best way.
Now Zapier pushes into Forms, Tables, Interfaces, and Agents because integration alone is vulnerable. If you only connect workflows, the app that owns the workflow can absorb you. If you own more of the intake, state, and action layer, you become harder to route around.
The best APIs do not stay pipes.
They become paths.
07 The handoff is where software gets sticky
The most underrated part of a workflow is the handoff.
Designer to developer. Sales to implementation. Support to engineering. Lead to account executive. Purchase request to finance. Pull request to reviewer. Order to warehouse. Ticket to field service.
Handoffs are where context dies.
That is why products that capture handoffs become much more important than they look from the outside.
Linear wins when unplanned work enters through Slack, lands in triage, becomes an issue, moves into a cycle, links to GitHub, and later becomes release notes.
Figma wins when a design stops being a picture and becomes a dev-ready object with status, annotations, comments, and linked implementation work.
Jira wins when a bug report becomes backlog work, sprint work, release work, and reporting data.
Slack wins when the handoff happens in the thread everyone already checks.
These tools do not always own the final system of record. That is fine. They own enough of the coordination layer to matter.
The handoff is where software becomes sticky because the handoff is where teams are most afraid to lose context.
08 AI makes loops more valuable
AI does not weaken workflow ownership. It makes the pattern more obvious.
A chatbot can answer questions from almost anywhere.
Acting is different.
The moment an AI system can create a refund, merge code, approve access, update a CRM record, change an invoice, message a customer, or trigger a deployment, the problem stops being "how smart is the model?"
The problem becomes: does it have the right context, the right permissions, the right tools, the right approval path, and the right audit trail?
That is workflow territory.
This is why the strongest AI products will probably not be standalone chat windows. The strongest ones will live inside products that already own real work.
GitHub Copilot becomes more powerful when it sits near repositories, issues, pull requests, review rules, Actions, and team conventions.
Microsoft Copilot becomes more useful when it can draw from mail, calendar, docs, Teams, permissions, and organizational memory.
ServiceNow's AI story works because requests, approvals, process rules, and enterprise actions already live there.
Slack's AI story works when messages, channels, workflows, apps, and permissions already contain the messy context of the company.
Cursor is fascinating because it owns more of the coding moment than a normal editor. But the bigger question is whether it can own enough of the full development loop. Prompt, plan, edit, test, review, merge, deploy. If the last four still live somewhere else, the loop is not fully owned.
AI agents need somewhere safe to act.
Workflow owners already have the fences.
09 The scorecard
You can measure workflow ownership. Not perfectly, but well enough to avoid fooling yourself.
Track these:
First-action share. What percentage of new work starts in your product?
Completion share. What percentage of work that starts there reaches a real endpoint there?
Steps captured. How many meaningful states or actions in the loop do you control?
Handoff share. How many cross-role transitions happen inside your product instead of leaking into email, chat, or meetings?
Exception share. How many weird cases get resolved inside your product?
Integration depth. Can connected systems only notify, or can they create, approve, update, and reconcile?
Permission depth. Are you useful, or are you trusted to govern who can do what?
Return rate. Do users come back because they like the product, or because the next step in the work is there?
Usage is not enough. A dashboard can have usage. A reporting tool can have usage. A nice internal portal can have usage.
The harder question is this:
If the product disappeared tomorrow, would work slow down, or would work break?
If work only slows down, you own a tool.
If work breaks, you own part of the loop.
10 The counterargument
This thesis can become lazy if you push it too far.
A narrow feature can still win. Sometimes the job is small, painful, and valuable enough that a focused product beats the suite.
A great UI still matters. Figma and Linear did not win by being process diagrams. They won because the product felt better. The loop came after the wedge.
APIs can still be deeper moats than workflows when the infrastructure is hard enough. Payments, telecom, banking connections, healthcare data, and logistics all have ugly details that most companies do not want to touch.
Flexible tools can beat workflow owners when the workflow is still changing. Notion wins in places where teams do not want a rigid process yet. Spreadsheets survive for the same reason. They are not elegant. They bend.
And sometimes workflow ownership becomes awful.
Too many fields. Too many statuses. Too many approvals. Too many automations nobody trusts. The software starts as a path and becomes a maze.
Enterprise software loves this failure mode.
The goal is not to own everything. That is how you build a prison with SSO.
The goal is to own the highest-value parts of the loop: the start, the handoff, the action, the exception, and the return.
11 What can break
Trying to own the loop creates its own risks.
Complexity creeps in first. Every customer wants one more status, one more approval, one more rule. Soon the product mirrors the org chart, which is rarely a compliment.
Lock-in resentment follows. Users tolerate switching costs when the tool saves them. They hate switching costs when the tool traps them.
Integration maintenance gets ugly. The more systems you connect, the more schemas, permissions, API changes, and edge cases you inherit.
Automation can become dangerous. A bad dashboard is annoying. A bad agent that issues refunds, merges code, or changes access rights is an incident.
Sales cycles get heavier too. Workflow tools touch more teams, more policies, more budgets. That makes the moat stronger after adoption, but it makes adoption harder.
Owning the loop is not a license to sprawl.
It is a demand for taste.
12 Closing
Software becomes durable when it stops being a destination and becomes a route.
The winners are not always the products with the most features or the cleanest screens. They are the products that become the default place where work comes in, gets interpreted, gets handed off, gets executed, gets checked, and comes back around.
That was already true in software delivery, commerce, CRM, payments, and enterprise operations.
AI just makes it easier to see.
Agents will not make workflows disappear. They will reward the companies that already own the context, permissions, tools, approvals, and action paths that real work requires.
So the strategic question is not "what screen do we own?"
It is sharper than that.
Which loop do we own?
And when the next action happens, does it come back to us?