Mandatory and recurring 22
Obligation beats enthusiasm. A renewal nobody enjoys is a better foundation than a purchase everybody debates.
LABS · WORKING NOTE
Can your industry be Shopified?
Shopify did not make retail simpler. It moved the complexity behind a button and let a person who knew nothing about payments, tax or logistics open a shop on a Tuesday. Most industries still make the customer learn the industry first. This page is a test for which ones do not have to.
Six worked models and one system already running. Score your own industry below.
The question is not how to add intelligence. It is why the customer has to understand any of this.
A manufacturer shipping four pallets should not need to learn freight forwarding. A property manager should not need to hold twelve inspection calendars in their head. Behind most of these professions is a coordination layer: moving information between people who each hold one piece of it. That layer is the product opportunity, and it is almost always boring.
The test
Six dimensions, weighted. Weights are fixed and shown, so the score is arguable rather than magic. Nothing here calls a model — same answers, same result, every time.
Fragmentation 18
Every extra party is a handover that currently runs on somebody chasing somebody. That is the layer a system can absorb.
Manual coordination 20
Not a measure of how backward the industry is. It is a measure of how much of the work is already structured data trapped in the wrong container.
Capturable inputs 15
If the input cannot be captured without a two-hour meeting, there is no front door, and without a front door there is no product.
Definable output 15
A certificate, a booked shipment, an approval, a filed submission. Ongoing advice with no artefact is hard to sell as a button.
Value of removing the pain 10
Weighted lowest on purpose. Willingness to pay follows the other five; it rarely rescues a process that fails them.
Score your industry
Worked cases
One system that exists, and five designs that do not. The distinction is marked on every card and it matters more than the ideas do.
Sales follow-up inside a CRM
An enquiry arrives, someone is supposed to notice it, gather context from four places, write a reply, and update the record. The step that gets dropped is always the last one.
A lead arrives → the next action is prepared → a person approves → the record closes itself.
- Capture the event
- Gather context and score
- Draft the next action
- Human approval
- Write back to the CRM
- Interface
- The CRM the team already opens every morning. No new app.
- Intelligence
- Context assembly and qualification over records the team can inspect.
- Automation
- Deterministic capture, routing and write-back around the model.
- Human layer
- A named reviewer owns anything customer-facing or hard to reverse.
- Business model
- Part of an embedded engagement, not a per-seat product.
Output. A complete customer record and a timely reply that a person signed off.
Read how this one is builtFreight forwarding
A manufacturer who wants to move four pallets learns about incoterms, customs paperwork, carrier quotes and insurance, because the industry has never offered any other way to buy.
4 pallets, Thessaloniki → Rotterdam, 1,850 kg, must land before the 18th → €1,420 · 5 days · Ship.
- Structured intake
- Carrier rate aggregation
- Customs document generation
- Booking and tracking
- Exception handling
- Interface
- A quote-to-booking surface. The freight vocabulary stays behind it.
- Intelligence
- Routing and pricing comparison; classification of goods for customs.
- Automation
- Carrier APIs, document assembly, milestone tracking, invoice reconciliation.
- Human layer
- A forwarder on exceptions: held shipments, misdeclared goods, damage.
- Business model
- Margin or fee per shipment.
Output. A booked shipment with the paperwork already correct.
Where it breaks. Carrier integrations. The abstraction is easy; the supply side is the moat and the cost.
Read how I would build thisCE certification
"Can I sell this in Europe?" turns into applicable directives, harmonised standards, conformity assessment routes, test reports, a technical file and a declaration. Most of it is a documentation problem wearing an engineering costume.
Upload the product file, pick the markets → Ready / Action required / Blocked.
- Product intake (BOM, drawings, manual)
- Applicable-requirements mapping
- Evidence gap analysis
- Test coordination
- Technical file generation
- Engineer sign-off
- Interface
- A persistent product record, because compliance is never finished at launch.
- Intelligence
- Retrieval over legislation and standards, scoped to the product type.
- Automation
- Document generation, evidence tracking, version control on the technical file.
- Human layer
- Engineers, accredited labs and notified bodies where the law requires them.
- Business model
- Fee per product plus recurring monitoring when standards change.
Output. A defensible technical file and a declaration someone qualified signed.
Where it breaks. Liability. The system can assemble the evidence; it cannot be the one who certifies.
Read how I would build thisElevator compliance
A property manager with twelve buildings holds inspection dates, maintenance contracts and certificates across a filing cabinet, three inboxes and one person who remembers things.
Add your building → 37 elevators · 35 compliant · 2 need action → Resolve.
- Asset registration
- Obligation discovery per asset
- Compliance calendar
- Contractor coordination
- Certificate storage
- Renewal alerts
- Interface
- A portfolio dashboard. The whole product is knowing what is not fine.
- Intelligence
- Modest. Mostly obligation rules and document classification.
- Automation
- Scheduling, reminders, contractor requests, certificate capture, invoicing.
- Human layer
- Licensed inspectors and maintenance firms do the physical work.
- Business model
- Per asset, per year.
Output. A building that stays legal without anyone tracking it by hand.
Where it breaks. Cold start. The value only appears once the whole portfolio is loaded.
Read how I would build thisPublic procurement
Tenders sit across portals in inconsistent formats. Finding the three worth bidding for costs more attention than writing the bids, so most firms find none of them.
Tell us what you sell → here are the four contracts worth bidding for, and what each one demands.
- Tender discovery
- Qualification against capability
- Requirement extraction
- Bid assembly
- Deadline tracking
- Interface
- A pipeline of qualified opportunities, not a search engine.
- Intelligence
- Extraction from long tender documents; fit scoring against a capability profile.
- Automation
- Portal monitoring, document parsing, reusable bid components.
- Human layer
- The bid owner. Nothing is submitted by a machine.
- Business model
- Subscription, with a success fee where the rules permit one.
Output. A shortlist worth someone actually reading, and a bid that starts at 70 percent.
Where it breaks. Qualification precision. A false positive costs the customer a week and buys you a churn.
Read how I would build thisProperty due diligence
A buyer coordinates a lawyer, an engineer, a registry search and a tax check, then assembles the answer themselves from four documents that do not reference each other.
Enter the property → what you are buying, what is wrong with it, and what it will cost to fix.
- Property identification
- Registry and encumbrance retrieval
- Document extraction
- Risk assembly
- Professional review
- Interface
- A single report with a plain verdict at the top.
- Intelligence
- Extraction from deeds, permits and registry records; contradiction detection.
- Automation
- Data source retrieval, cross-checking, report generation.
- Human layer
- A lawyer and an engineer sign the parts that carry liability.
- Business model
- Fee per property, paid by a buyer under time pressure.
Output. A yes, a no, or a priced list of what to negotiate.
Where it breaks. Data access. Registries are the whole game, and they are rarely an API.
Read how I would build thisWhat a system means here
None of these are a model in a chat window. Each one is a customer-facing surface, a set of rules that are written down because somebody legislated them, retrieval and extraction over documents, integrations with whoever holds the data, and a named person who approves the steps that carry liability. The reasoning is usually the smallest part.
The hard question is never whether the intelligence is good enough. It is whether the supply side will connect, whether the registry has an interface, and who is legally allowed to sign.
Have an industry that feels unnecessarily complicated?
If you run one of these processes, you already know which part is absurd. Describe how it actually works today — the spreadsheet, the four inboxes, the person who remembers things — and I will tell you honestly whether it collapses into a system or whether it does not.