Grubhub’s $23.8 million FTC settlement is being discussed as a case about deceptive advertising, blocked accounts, and restaurant listings. It is also a software buying lesson that most businesses still miss.
The dangerous part of a platform is not simply that it makes a mistake. The dangerous part is when the platform controls customer access, business data, and the process for leaving, while making responsibility difficult to see.
The FTC says Grubhub misled drivers about earnings and diners about fees and discounts. The agency also challenged how Grubhub handled restaurant listings, including allegations that the company resisted removing some restaurants and pressured businesses into paid partnerships. The settlement requires changes including more honest driver pay advertising, a way for users to dispute blocked accounts, and explicit restaurant consent before listings appear on the platform. The FTC’s announcement says more than $23.8 million is being distributed to affected drivers and diners.
That outcome should change how we evaluate business software. We should stop treating the right to leave as a legal footnote. It is an operating requirement.
Compliance failures often start as control failures
When a platform publishes information about your business without clear consent, blocks access without a meaningful dispute process, or makes removal difficult, the problem is not only compliance. It is workflow design.
The platform has decided who can access the business, what information represents it, and which actions require the owner’s permission. Those decisions may be buried in account settings, partner agreements, support queues, ranking systems, or opaque review processes.
That is where operational risk begins.
Imagine a local plumber whose company appears on a lead marketplace. The listing contains an old phone number, an inaccurate service area, and a price estimate the plumber never approved. A customer calls, receives the wrong information, and leaves a poor review. The owner asks for the listing to be corrected or removed. If the platform controls the listing but does not provide a clear owner-controlled workflow, the business has a reputation problem it cannot directly fix.
The same pattern appears in less obvious software categories:
- A scheduling platform owns the only usable copy of appointment history.
- A marketing tool stores customer consent records but cannot export them with campaign history.
- A payment provider controls transaction data while support decides whether an account can transact.
- An AI system sends customer messages, but the business cannot inspect which context produced them.
- A review platform lets customers see a profile that the business cannot fully manage.
In each case, the feature may work exactly as designed. The design is the problem.
Dependence is not the same as lock-in
Every useful system creates some dependence. If a tool reliably handles bookings, follow-ups, payments, or reporting, we will build habits around it. That is normal. Good software earns a place in the operation because replacing it would mean giving up proven value.
Lock-in is different. Lock-in appears when the vendor makes switching expensive by controlling the information, permissions, integrations, or customer relationships needed to continue operating elsewhere.
The distinction matters because dependence can be healthy while lock-in is a liability.
A good platform should make itself difficult to replace because it performs well. It should not make itself difficult to replace because your records are trapped, your customers cannot be reached outside the platform, or your account can be restricted without an intelligible process.
This is also why data portability alone is not enough. An export file containing thousands of contacts is not a real exit if it omits consent history, message status, appointment relationships, payment references, or the identity of the person who changed a record. You need the context that makes the data operationally useful.
Our earlier post, The $57M AI Backend Bet Is About Memory, made a related point from the infrastructure side: software needs durable state to finish work. The next buying question is whether that state remains usable when the vendor is no longer involved.
The five questions to ask before signing
Feature checklists tell you what a platform can do on its best day. Exit questions reveal who controls the business when something goes wrong.
Ask these before you buy:
Can we export the complete operating record?
Ask for a sample export, not a promise. Check whether it includes customers, communication history, consent records, invoices, appointments, attachments, status changes, and timestamps. Ask whether the export is available in a documented format that another system can use.
Can we reach our customers without the platform?
Customer relationships should not disappear when an account is closed. Confirm that you can retrieve contact details where permitted, communication history, opt-in status, and the records needed to continue service through another provider.
Who can change or publish information about our business?
Identify every public profile, directory listing, automated message, review response, and pricing display the platform controls. Ask how approval works, how changes are logged, and how quickly you can correct or remove inaccurate information.
What happens when an account is restricted?
A fraud or abuse control may be necessary, but the business needs a clear dispute path. Ask what triggers suspension, whether access to records continues during review, who investigates, and what service-level commitment applies to appeals.
Can we test the exit before we need it?
Run a small migration exercise. Export the data, import it into a spreadsheet or alternate tool, and verify that the important workflow still makes sense. If the vendor refuses to let you test, treat that as evidence.
These questions are not asking a vendor to guarantee uninterrupted service. They are asking the vendor to make control visible.
Put ownership into the workflow
Small businesses do not need to eliminate every third-party platform. They need clear boundaries around what the platform may do and what remains under the owner’s control.
For every automated workflow, document four things:
- The trigger that starts the action
- The data the system uses
- The action the system is allowed to take
- The human who can review, reverse, or escalate it
Then document the exit equivalent. Where does the data go? How are pending appointments handled? What happens to scheduled messages? Can customers still contact the business? Which records must be retained for accounting, disputes, or service history?
This is practical governance, not bureaucracy. It reduces the chance that a software failure becomes a customer failure.
The strongest platforms will welcome these questions because reliable operations create durable trust. They earn dependence by helping the business respond faster, keep better records, and recover when something breaks. A vendor that needs hidden switching costs to retain customers has already told you something important about the product.
Hitch is built around the operating work a small business needs to keep moving, with customer context and follow-up tied to the business rather than a temporary campaign. The standard is simple: software should make the owner more capable, not less able to leave.
Before your next renewal, try the export, trace the permissions, and ask who can undo the system’s decisions. If you cannot answer those questions, you do not fully control the workflow yet.