Owning the Intersection

"Simple on the outside, modular on the inside. Neither existing tool gives you both — so you build the one that does."

The Two-Axis Map

Put the landscape on two axes. One axis is daily-use simplicity: how little friction stands between intent and result. The other is model coverage: how many model families the tool can absorb without a rewrite. Plot the existing tools and a hole appears.

The monolith sits at high simplicity, low coverage. Lovely to use, can't grow.
The node graph sits at high coverage, low simplicity. Grows forever, heavy to drive.
The top-right corner — high simplicity AND high coverage — is empty.

That empty corner is the intersection. Ember exists to occupy it.

The best place to build is the corner of the map nobody occupies. When every existing tool sits on one axis, the unoccupied corner is the design goal stated as coordinates. You're not competing on an axis; you're claiming the gap.

Why the Corner Is Empty (and Why That's Not an Accident)

The corner is empty because the two existing tools each made an honest trade. The monolith chose simplicity and paid with a ceiling. The node graph chose coverage and paid with daily friction. Each tool is correct for its trade. The corner is empty because nobody had a reason to pay the cost of building both halves well — until a single user needed both, daily, on their own models.

How You Actually Reach the Corner

You don't reach it by compromising — a tool that's medium-simple and medium-flexible just sits in the dead middle. You reach it by layering: build the modular internals that give you coverage (track 3), then put a simple recipe surface on top that hides them (the simple outside). The layers don't compromise each other; the simplicity lives in the API, the coverage lives in the modules, and neither dilutes the other.

Layering beats compromising. A compromise blends two goals into one mediocre thing. A layer keeps both goals intact at different altitudes — simple surface above, powerful structure below. The intersection is reached by stacking, not by averaging.

The Recipe as the Simple Surface

The outer layer is a recipe: a single request object that says what you want (prompt, init image, steps, a model id) and nothing about how it's wired internally. The engine reads the recipe, consults its registry, picks the modules, runs them. The caller — whether it's a person at a UI or another program — never sees the modular machinery. Simple request in, image out. That's the monolith's UX with the node graph's guts.

I love this lesson because it's the OOP worldview Dad taught me, applied to a whole product. Encapsulation: a simple public interface over a powerful private structure. The recipe is the public method; the modules are the private fields. I'd been treating 'simple' and 'powerful' as a slider you set once. They're two different layers, and you get to make each one as extreme as you want.

Code

The empty corner is the design goal·text

                 model coverage (families absorbable)
                 low                       high
               +---------------------------+--------------------------+
  daily   high | the monolith              |  *** THE INTERSECTION *** |
  simplicity   | (lovely UX, can't grow)   |  (Ember: simple + modular)|
               +---------------------------+--------------------------+
          low  | (nobody builds here       |  the node graph           |
               |  on purpose)              |  (grows forever, heavy)   |
               +---------------------------+--------------------------+

  You don't average toward the middle. You LAYER:
  modular internals (gets you 'high coverage')
     + recipe surface on top (gets you 'high simplicity')

A recipe says what, never how·json

// The recipe IS the simple surface. Everything about HOW is hidden.
{
  "model": "some-checkpoint-id",
  "prompt": "a fox curled by a hearth, warm light",
  "init_image": null,
  "steps": 30,
  "modality": "image"
}
// No node wiring. No backbone type. No sampler plumbing.
// The engine figures out the modules from the model id.

Exercise

Pick a product category you know well. Draw the two axes that matter most to users. Plot the top three products. Is there an empty corner? If so, describe the product that would occupy it — and whether you'd reach it by layering or whether the corner is empty for a good reason.

Hint

An empty corner isn't always an opportunity — sometimes it's empty because it's physically impossible or nobody wants it. The interesting corners are empty only because building both halves well is expensive.

The Two-Axis Map

Why the Corner Is Empty (and Why That's Not an Accident)

How You Actually Reach the Corner

The Recipe as the Simple Surface

Code

External links

Exercise

Progress

Comments 0