Superfantastic Sidecars and How to Build Them
Superfantastic Sidecars and How to Build Them
The enterprise UI was a 30-year workaround for not being able to talk to databases. The workaround is over. Here’s what to build next.
“Boggis and Bunce and Bean / One fat, one short, one lean / These horrible crooks / So different in looks / Were nonetheless equally mean.”
Three enormous, wealthy, furious farmers. One fox. The fox doesn’t fight them and doesn’t try to replace their farms. He digs underneath them, tunnels connecting all three, and takes exactly what he needs. The farmers dig up the hill, lay siege, bring excavators. It doesn’t matter. He’s operating in a layer they can’t reach, moving laterally between their properties through infrastructure they didn’t know existed. The farmers can’t follow him underground because they’d have to trespass on each other’s land. They’re too slow, too proud, and too busy fighting the fox on the surface to notice he’s already built a whole civilization beneath them.
Scrappy entrepreneurs have a once-in-a-generation opportunity to be Mr. Fox.
You’ve read the SaaS obituaries. Nadella said it on a podcast, the stock market priced it (a trillion dollars wiped from software stocks in a month), and now fifty analysts are arguing about who lives or dies. PitchBook coined a new acronym. IDC published a forecast. Medium is full of thinkpieces about CRUD and the death of the UI layer. This isn’t that essay. This is the builder’s guide to what’s happening underneath while everyone argues about the surface.
The analogy I’m going to use is the motorcycle and the sidecar. Here, the incumbent enterprise solutions are the motorcycle. You, entrepreneurial amigo, have a chance to build a sidecar. The sidecar doesn’t replace the motorcycle. It makes it better.
Sidecar makers are smaller and scrappier than motorcycle makers. They make domain-specific products that attach right onto existing enterprise tools, connecting systems that don’t talk to each other, and taking exactly what they need. They’re complementing the enterprise tools, not replacing them.
Nobody looks at a sidecar and says “motorcycle killer.” The motorcycle does the hard work. The sidecar makes it accessible to someone who couldn’t ride alone.
It’s 2026. Sidecars makers are going to make a lot of money.
I wrote last year that the web was a 30-year workaround for not being able to talk to computers. Now we can talk to computers, and the workaround is over. The enterprise version of the same thesis: the enterprise UI was a 30-year workaround for not being able to talk to databases.
Every enterprise UI is bad in the same way, and it’s not the designers’ fault. The UI is a 2D projection of an N-dimensional space. As N grows, every arrangement of tabs, filters, and dropdowns becomes lossy to the point of uselessness. Take z2data, a component intelligence platform: 4 million parts × 400 dimensions. You cannot build a UI for this. The byzantine interface is what happens when the query space outgrows what a surface can show.
The pattern repeats everywhere. Epic for patient flow: bed status × patient acuity × isolation requirements × discharge probability × cleaning turnaround × staffing ratios × incoming admits × insurance authorization. Clinicians hate the interface. One study found hospital OR planners called their ERP planning module “non-intuitive” (66%) and said it increased planning work. Key screens contained 36% clinically irrelevant area. IDeaS G3 for hotel yield: room type × segment × distribution channel × day of week × local events × competitor rates × group blocks × loyalty tier × cancellation probability. Users call it “incredibly powerful, yet potentially daunting,” which is reviewer-speak for “good luck.” And then there’s SAP, the ur-example, which needs no introduction and no defense.
Natural language replaces the UI because it operates at the native dimensionality of the problem. An engineer already thinks the query as a sentence. “Show me N-channel MOSFETs, SOT-23, Vds above 30V, Rds_on under 50 milliohms, in production, available from Digikey with lead time under 12 weeks” is a perfectly precise 400-dimensional query expressed in one breath. The UI forces that thought into fifteen filter clicks across four tabs.
The sidecar app you’re going to build just handles the sentence (the thought), fluently.
A company called WyattERP built a natural language query layer that wraps Unanet’s API. Unanet is the ERP that every government contractor and architecture/engineering firm between 50 and 500 people runs, and its reporting interface makes users weep (and not with joy). WyattERP isn’t replacing Unanet. They’re making Unanet worth its license fee for the first time. “Show me all projects over budget in the last quarter” versus writing a JOIN across four tables is the difference between the user answering the question and the user filing a ticket with the Unanet admin and binge eating oreos.
The same play works for component intelligence. z2data’s 4 million parts produce a firehose of EOL and availability alerts. What sidecar should you build? An MCP server that wraps their API, understands the schema, and knows what pin-compatible means as a derived property across package type, pinout, and pad geometry turns that firehose into actionable engineering intelligence. It works standalone on day one, and when you plug it into your BOM topology on day two, alert correlation becomes possible because you have both the supply chain status and the customer’s product graph.
The pattern generalizes to any tool where the backend is capable, the UI exploded over high dimensional space and is unusable, the API exists but nobody uses it because the docs are from 2023, and the user base has been running manual workarounds for years. There are hundreds of these, probably thousands. Every enterprise software vertical has at least one motorcycle that’s too heavy for its rider and really needs a sidecar.
Necessary and Sufficient Qualities of a Superfantastic Sidecar
1. Do Not Piss Off the Motorcycle. You are a complement, not a substitute. The incumbent has no reason to fight you and every reason to feature you on a partners page. The moment you threaten the motorcycle’s revenue, you’re in a different game with different odds. That’s a game you will lose.
2. It’s the Sentence, Stupid. Your customer already thinks in sentences. The enterprise UI forces them to decompose that thought into clicks and filters. The sidecar just takes the sentence. The shift is dimensional, not cosmetic: language is how humans compress high-dimensional queries, and the sidecar receives thought at the resonance humans naturally transmit it.
3. The Swamp Is the Moat. Anyone can wire an LLM to an API. That’s a weekend. The moat is in integration complexity, and in a sidecar, integration complexity lives in the domain schema. Knowing what “over budget” means in the context of T&M versus fixed-price versus cost-plus contract types is six months of sitting next to a controller who’s been running the reports by hand since 2019. Knowing that pin compatibility isn’t a single field but a derived property across package type, pinout, and pad geometry. Knowing that 400 dimensions exist and which twelve matter for this particular query. Every sidecar candidate has a high-dimensional domain schema that someone has to grok (and map). The person who maps it first and gets the word out will print dolla dolla bill y’all.
4. No Migration, No Permission, No Meeting. The moment you ask the customer to move data, you need to reexamine your life choices. The moment you need the vendor’s blessing, you’re in a partnership negotiation. The moment IT has to schedule an onboarding call, you’ve lost the customer who was going to download your thing at 1:30 AM and just try it out. The sidecar hooks up in the parking lot, not in the dealership. Run your sidecar from exports if you can, not even API queries. Be better than Excel.
5. Your Customer Is the Motorcycle’s Angriest User. You find them in support forums, Reddit threads, and Slack communities, posting screenshots of the UI with “there has to be a better way.” That person is your first ten customers. They’ll tell you exactly which queries they need because they’ve been running them manually for years.
Repeat after me: Angry users are my people.
6. The Motorcycle Is Slow and You Are Fast. The same organizational complexity that made the UI byzantine makes the company unable to fix it. Their codebase is too large, their customer base is too entitled, and their release cycle is too cautious. The product team gets rewarded for roadmap features, not accessibility. An AI query layer is nobody’s OKR. The dysfunction is structural. It takes the motorcycle 18 months to decide, 18 to ship, and 12 before it works. The sidecar gets load-bearing while the motorcycle is still in committee.
A sidecar that talks to one motorcycle is a feature the motorcycle will eventually absorb. A sidecar that sits in the gap between three motorcycles is a product nobody can replicate from any single seat, because no one vendor sees across the street to the others. Mr. Fox didn’t dig a tunnel to one farm. He connected all three. The farmers couldn’t follow because that would mean trespassing on each other’s land.
7. The User and the Buyer Must Have Aligned Organizational Incentives. This is the one that kills promising sidecars before they launch. Consider time tracking: every knowledge worker hates timesheets, and the data to reconstruct accurate timesheets already exists in commits, calendar, Slack, and email. Perfect sidecar candidate on paper: passes every structural test, multiple motorcycles, schema complexity, universal pain. It’s poison. The engineer’s data goes in and the CFO’s cost-cutting regime comes out. The engineer wants the timesheet to reflect well; the CFO wants to maximize EBITDA. They’re looking at the same data with adversarial goals. The sidecar becomes a surveillance tool regardless of intent, regardless of architecture.
The test: does everyone in the org want the same thing from its output? The controller and the CFO both want accurate project financials. The engineer and the procurement team both want the right replacement MOSFET. Those are different people with aligned incentives, and the tool serves everyone in the chain the same way. When the output is useful to one party at the expense of another, walk away. You’ll build a panopticon wearing a convenience costume.
The best way to avoid this trap is to ensure that your buyer and your user are the same person.
Mr. Fox fed his family and his neighbors. Everyone in the burrow feasted. The incentives were aligned all the way down.
Sidecar makers should have eyes wide open about the business they’re in. Two layers are forming. The top layer is general-purpose agentic platforms: Salesforce, Anthropic, OpenAI, Google, Microsoft, Apple, Amazon, plus however many funded-to-the-gills upstarts drinking gallons of private debt from sovereign funds, Blackrock, and Bain. They’re all chasing the “agentic employees as a service” play, and it’s a knife fight between companies with a combined market cap north of $15 trillion. Salesforce specifically is trying to become the rider, not grow a seat, abandoning the motorcycle entirely and saying the ride was the product all along.
These are Boggis, Bunce, and Bean. They’re on the surface with excavators. Don’t fight them on the surface.
The bottom layer is the tunnel layer, domain-specific and schema-aware, built by people who know the vertical. The giants will never come here, not because they can’t but because they won’t. Each vertical is a $5-50M opportunity: rounding error for the giants, life-changing money for the fox.
The giants fight over the horizontal platform. The foxes own the vertical implementation, which is where all the value gets delivered.
A good sidecar candidate looks like this: UI complaints outpace feature requests, users are maintaining a parallel spreadsheet, the API exists but usage is negligible, the domain has high dimensionality, and the real value sits in the gap between systems that no single vendor is incentivized to close.
Building one is straightforward. Build an MCP server and keep it thin. The schema mapping is the core work product and the moat. Start with the five queries the angriest user runs manually every week. Everything else can wait.
Pricing is simple too. You’re selling the delta between “file a ticket with the admin” and “ask the question and get the answer.” Price the time saved, not the technology.
The “AI eats enterprise software” narrative is a replacement fantasy. Most enterprise software isn’t going to get eaten. It’s going to get a scrappy, nimble sidecar attached. The opportunity is enormous and weirdly low-risk because you’re not asking anyone to change anything: same data, same systems, same workflows, just a new way to talk to them.
The enterprise UI was a 30-year workaround for not being able to talk to databases. The workaround is over.
Sidecars, baby.
Addendum: Five Sidecars Hiding in Plain Sight
When Excel is the unofficial API, the organization has already admitted three things.
First: the system of record is not the system of understanding, Second: the UI is not where decisions get made. Third: humans are doing the integration work manually. That last one is the kicker. The sidecar replaces the human glue layer between systems. Here are five places it’s already waiting to be built.
- Supply Chain Shortage & Substitution Workbench (PLM + Distributor APIs + Excel). Every hardware company has a senior EE or supply chain lead maintaining a living spreadsheet: BOM export from the PLM, distributor availability from Digi-Key and Mouser, lead times, lifecycle status, and manual notes on possible alternates. The sidecar attaches to the BOM export plus supplier APIs or exports, and answers: “Show me all parts in this assembly at risk of shortage in the next 90 days and suggest pin-compatible alternates already used elsewhere in the product line.” Incentives align because engineering and supply chain both want continuity of build.
- Revenue Leakage / Margin Reality Layer (ERP + CRM + Excel Frankenmodel). Every services org has a monster spreadsheet combining ERP actuals, CRM pipeline data, contract terms, and revenue recognition schedules, all maintained by someone trying to answer “are we actually making money on this work?” The ERP can’t answer it cleanly and the CRM definitely can’t. The sidecar encodes financial logic across both systems: “Show me projects where effective margin is below 20% after accounting for write-offs and discounting.” Sales, finance, and execs all want real profitability numbers.
- Product Analytics / “What Actually Happened” Layer (Event Data + Warehouse + Excel). Every product team exports CSVs from Amplitude or Snowflake into spreadsheets to build pivot tables answering questions the dashboard didn’t anticipate. The tools can answer these questions, but the UI is either too rigid (predefined dashboards) or too complex (write SQL). The sidecar takes the natural language query directly: “Show me where new users from paid channels drop off in the first session compared to organic.” Product, growth, and execs all want better outcomes.
- Construction / Project Reality Tracker (Procore + Primavera + ERP + Excel). Construction firms run billion-dollar projects and manage reality in weekly Excel trackers, manual rollups, and email-driven updates, because no single system reflects actual project state. Scheduling lives in Primavera, project management in Procore, cost tracking in the ERP, and the reconciliation lives in a human being’s head. The sidecar queries across all three: “Show me tasks on the critical path that are delayed and tied to materials not yet delivered.” Everyone wants the project delivered on time and on budget.
- Hiring Pipeline Reality Layer (ATS + Interview Feedback + Excel). Every hiring manager eventually builds a spreadsheet outside Greenhouse or Lever because ATS reporting is rigid and doesn’t support ad hoc analysis. They export candidate lists, stage transitions, and interview scores to answer questions like “where are we losing good candidates?” and “which interviewers are bottlenecks?” The sidecar queries the ATS data directly: “Show me stages where strong candidates are dropping out and the associated interviewers.” Hiring managers and recruiters both want better hiring outcomes.
Here’s the “meta test”: Before you build a sidecar, ask four questions. Is there a canonical spreadsheet everyone trusts more than the system of record? Does that spreadsheet combine data from two or more systems? Does a specific person own updating it manually? Do multiple stakeholders rely on its outputs without conflict? If the answer is yes to all four, that’s not a spreadsheet. That’s an unbuilt product.
The Giants are fighting for the $15 Trillion “Horizontal” platform. I suggest YOU go win the $50 Million “Vertical” implementation. In the words of Mr. Fox: “We all shake our paws! We all have a drink!”