A Thousand Settings Is Not a Feature. It's an Apology.
There's a particular moment that happens when a company buys a new business tool. The contract is signed, the champagne metaphor has been deployed in the all-hands, someone logs in for the first time — and lands on a screen with fourteen tabs, each containing between nine and forty toggles, at least three of which contradict each other in ways that will only surface in production, in March.
Then somebody says the sentence. "We should probably get someone in to set this up properly."
That sentence is the product's real price tag. Everything before it was just the invoice.
How we got here
The classic playbook for building business software has been unchanged for thirty years. Pick a category — CRM, ERP, scheduling, ticketing. Build a version that fits your first ten customers. Then sell to customer eleven, who works slightly differently. You can't rebuild the product for one account, so you do the only thing the architecture allows: you turn the difference into a setting.
Repeat that four thousand times.
Nobody ever decided to build a monster. Every single toggle was a reasonable answer to a real customer's real problem. The monster is emergent — it's what you get when the only mechanism you have for absorbing variance is exposing it in the UI, and the cost of that exposure lands on everyone who comes after.
And the cost isn't linear. Two hundred settings aren't twice as complicated as a hundred; settings interact. Options multiply against each other into a state space that no one at the vendor has fully mapped either, which is why support's first question is so often some variant of "who configured this originally?"
The tell
You can spot a platform that's gone through this by looking for one thing: a professional class that exists solely to operate it.
Google Ads started as a keyword auction you could understand in an afternoon. It is now a system with a certification program, an entire agency industry, and enough surface area that Google's own automated modes exist mostly because most advertisers can no longer be trusted with the manual ones. Salesforce ships a genuinely powerful platform and a global ecosystem of admins, architects, and certified consultants whose living is made translating between "how our sales team works" and "how the object model needs to be bent." SAP is the boss level: implementations measured in years, budgets measured in millions, and a folk tradition of horror stories that predates most of the people telling them.
None of these are bad products. They are extremely good products at the thing they became. But notice what happened: the vendor outsourced its user experience to a services industry. When your software requires a trained intermediary to be usable, you haven't shipped flexibility. You've shipped a translation problem and let the market solve it at the customer's expense.
The consultant is not a bug in enterprise software. The consultant is the interface.
What actually changed
Here's the thing worth sitting with. That whole architecture — the settings screens, the configuration exports, the implementation partner — exists to solve one problem: the software has to be written before it knows who it's for.
That constraint was real and absolute. Code was expensive and slow to write, so it had to be written once, generically, and then bent at runtime by whoever bought it. Configuration was the only affordable form of customization. Settings screens are a compression artifact of expensive engineering.
Engineering isn't expensive in that way anymore. Not all of it — I'll come back to that — but the specific act of turning a described set of business rules into working, deployed logic has collapsed in cost by something like an order of magnitude. Which means the variance between customers no longer has to live in the UI. It can live in code that is generated for exactly one customer and nobody else.
That's a different product shape entirely.
The case in hand: scheduling
Scheduling looks trivial until you actually sell it. Every business schedules differently, and every one of those differences is load-bearing.
A dentist has thirty-minute appointments, except hygiene is forty-five, across two chairs, with a fifteen-minute buffer for new patients and nothing on Wednesday afternoons. A padel club rents ninety-minute courts to groups of four, with a member-only booking window that opens seven days out and a non-member window that opens two. A physiotherapist has one room, three treatment types, and refuses to accept two of the same type back to back. A language school runs recurring group classes with a minimum of four attendees and a cancellation rule that varies by course level.
The traditional path: build the union of all of it, expose it as configuration, hire someone to explain it. Alternatively, the modern SaaS path — pick a niche, serve it well, and tell everyone else their business is wrong.
What we do instead is the boring-sounding thing that isn't boring at all. The client describes their schedule in their own words. Or they paste in what they already have — the spreadsheet, the timetable printed on the door, the exported calendar, the three paragraphs they send by email to every new customer. Whatever form the truth already lives in.
The AI reads it, asks about the parts that are genuinely ambiguous — and there are always a couple, because business rules that live in someone's head are never fully specified — and compiles the result into a working bookable system. Durations, service types, resources, capacity, attendee minimums, buffers, blackout windows, notice periods, who's allowed to book what and when.
Then the schedule changes, because schedules always change. New service, seasonal hours, a second room, a rule that turned out to cause chaos in practice. That isn't a support ticket, a change request, or a call to whoever set this up originally. It's another message in a chat. New rules, deployed.
No settings page. Not because we hid it — because the thing it was compensating for stopped existing.
Let me spoil my own pitch
If you take one thing from this, don't take "AI runs the bookings." That would be a terrible product and I'd like to be clear that it isn't what I'm describing.
Underneath, there is an ordinary, deterministic, extremely dull scheduling engine that does the same thing every time and never improvises about whether a slot is free. The AI writes the configuration. It does not be the configuration. Nothing generated goes live unreviewed, every rule set is versioned, and any change can be read in plain language and rolled back to the previous state in one move.
That distinction is the entire ballgame. Replace a thousand settings with a black box and you haven't fixed the problem — you've made it worse, because at least the thousand settings could be audited. What you want is the opposite: rules that are more legible than a settings screen, not less, expressed the way the business actually describes them, with a machine doing the tedious translation into something a computer can execute.
The old promise was: our platform can do anything, once configured correctly by a professional. The new one is smaller and, I think, much better: describe how you work, and get software that works that way. When how you work changes, say so.
Everything else was scaffolding for a constraint that has quietly stopped applying.
What's the most baroque configuration screen you've been handed in the last year — and did anyone on your team ever fully understand it?