Skip to content
Think Space
Concept FlowAIProduct DevelopmentResearchStrategyModel13 min read · 29 May 2026

The software you use was built for someone else. It shouldn't be.

Why is it that the more expertise you build over a career, the more time you spend translating it into forms, fields, and workflows that were designed by someone who has never done your job?

ShareLinkedInTwitter/XWhatsApp

Every knowledge worker today is trapped inside software appliances designed by someone else, reflecting someone else's mental model. A sales rep with ten years of pipeline instincts is forced to use a CRM's opinion of what a pipeline is. A designer with a precise handoff process crams it into status fields that were never built for her workflow.

The mismatch between how experts think and how software is structured is constant, invisible, and expensive.

This product — a capability engine — resolves that with one idea:

Domain expertise should be executable. The system builds software around you — not the other way around.


2. The problem

2.1 The software appliance trap

Most tools in use today are appliances: fixed, opinionated, and built for an average user who doesn't exist. The ceiling of what you can do inside them is the ceiling of what their designers imagined.

⊕ View

This creates a permanent structural mismatch:

Who you areWhat you're forced to use
A sales rep with proprietary pipeline logicSalesforce's generic pipeline fields
A designer with a precise handoff ritualFigma's generic status columns
A researcher with a non-linear review processLinear's sequential sprint boards
An ops lead with a custom approval chainWhatever the enterprise IT team installed

2.2 The imagination gap

The problem isn't AI capability — it's the interface to that capability.

Research from Ink & Switch, MIT, and Microsoft found:

  • 📈 AI usage in knowledge work jumped 13% in 2025
  • 📉 Confidence in using AI tools dropped 18% in the same period
  • 🤔 75% of employees don't feel competent using AI in their day-to-day work
People use it because they must — not because they believe they're doing it well. A text box requires the user to already know what to ask. That's the wrong interface.


3. The concept

The Capability Engine - A New Model for AI-Powered Software

3.1 Core thesis

The next major shift in software is the collapse of the boundary between tool user and tool builder. This product is built for that shift.

The capability engine lets anyone build the exact tool their work demands — without writing a single line of code. Not by drag-and-dropping components from a template library. But by describing how their work actually functions, and having the system construct software infrastructure around that description.

3.2 The grain model

The atomic unit of this product is a grain: a discrete piece of logic that represents how you work.

```javascript Grain examples: → A decision rule ("escalate if unresolved after 48h") → A stage ("approved" means two sign-offs, not one) → A relationship ("every brief has one owner and one reviewer") → A trigger ("when status changes to live, notify the client") ```

Users compose grains into capabilities — functional units of workflow logic. The AI amplifies them at every layer: suggesting connections, filling gaps, and maintaining the system as the work evolves.

3.3 How it compares

DimensionTraditional SaaSNo-code toolsThis product
Mental modelVendor'sVendor's + your configYours entirely
Customisation ceilingLowMediumNo ceiling
AI roleFeatureCo-pilotInfrastructure layer
Requires codeNoNoNo
Scales from solo → enterpriseNoRarelyYes, same kernel

4. The world model

One structural decision that defines the product:

A solo user's personal workspace and a 10,000-person enterprise deployment run on exactly the same kernel, use the same grain model, and share the same capability library.

The world scales. The kernel does not change. No re-platforming, ever. This mirrors the Minecraft model — a solo player and a multiplayer server run the same game engine. The world scales; the kernel doesn't.

4.1 Architecture layers


5. Market context

Key numbers

  • $187B — Projected no-code market by 2030
  • 4:1 — Citizen-to-professional developer ratio in enterprise
  • 43% — Citizen dev programmes shut down without delivering value
  • 18 — Validated use cases found across research, sales, design, and ops

Why now

Three forces converge in 2025–2026 to make this the right moment:

  1. LLM reasoning quality has crossed the threshold where natural language → executable logic is reliable enough to build on
  2. No-code fatigue is real — enterprises have tried and abandoned template-based citizen dev at scale
  3. The workforce expectation shift — a generation of workers expects software to adapt to them, not the other way around


6. Positioning

One-line positioning:

This product turns your domain expertise into living, AI-powered software — without code.

What it is not:

  • Not a better CRM
  • Not a smarter project tracker
  • Not a no-code form builder
  • Not an AI assistant bolted onto existing software
What it is:

  • A capability engine
  • Infrastructure for a new relationship between expertise and software
  • The foundation layer for the post-SaaS era of work


7. What's next


_Concept stage — May 2026. Some statistics from Ink & Switch, MIT CSAIL, and Microsoft WorkLab research._

Discussion (0)

Loading...