Last year I turned a Victorian physics toy into five architecture principles. Last week I shipped the tool that reads the board.
During holidays last year, I got obsessed with a Galton board. A 130-year-old device: drop a ball into a triangle of pegs and it bounces left or right at each one, apparently at random. Drop a few thousand, and they always pile up into the same shape — a perfect bell curve. Individual chaos, collective order.
I couldn’t stop seeing Salesforce orgs in it. Every transaction is a ball. Every architectural decision is a peg. No single record’s path is predictable, but the shape the whole system settles into absolutely is — and it’s decided by where you placed the pegs. I wrote a post about it: five principles hidden in falling balls. Emergence, Accumulation, Distribution, Path Dependency, Observability.
That post wasn’t a passing curiosity. It was me writing down the rules I actually design by — a spec for how a healthy org is supposed to hold its shape. And a spec is only worth the paper it’s on until you build something to it.
A principle you can’t measure is just a poster
Here’s the catch with a good architecture principle: it diagnoses beautifully and measures nothing. “Design for the distribution, not the average” is completely true and completely useless — until something can take your org, in its specific load-bearing mess, and show you where your balls actually landed.
So that was the plan the whole time: write the theory first, then build the instrument to it. The instrument is orgspark — a free, zero-install Salesforce assessment that runs entirely in your browser. I wrote up the what in the launch post. This one is the why it’s shaped the way it is — because four of those five falling-ball principles aren’t decoration on the tool. They’re the blueprint it was built from.
Accumulation: the pile, counted
The board’s cruelest trick is that no single peg looks like a problem. One extra trigger. One “temporary” flow. One permission set nobody remembers. Each is a small deflection. But debt compounds through the pegs — the balls keep landing in the same corner until the shape is unmistakable.
orgspark’s job is to count the pile. It lists every component — Apex, flows, validation rules, objects, sharing, agents — each with its own verdict, and rolls the mess into a plain-language forecast and a prioritized plan. Not “you have tech debt.” Here is the pile, here is where it’s deepest, here is the order to dig out.
Path Dependency: the peg that bent everything after it
This is the principle I care about most, and the one I most deliberately built the tool to catch.
Early decisions constrain every option downstream. On a Galton board the first pegs matter most — a ball nudged early lands a world away from one nudged late. In an org, the earliest pegs are the data model. Get an object wrong and you don’t get one bad object; you get a decade of flows, reports, and integrations built on the tilt.
So orgspark now looks at your custom objects and asks a path-dependency question out loud: was this a fork someone took on purpose? A custom object whose fields are First Name, Last Name, Email, Phone, Mailing City isn’t really a new object — it’s a standard Contact someone rebuilt from scratch, and everything since has been paying rent on that choice. orgspark flags it, shows the field shape as evidence, and frames it exactly the way an architect would: was that deliberate? You might have a great answer. The tool doesn’t overrule you — it surfaces the peg and lets you decide.
That’s Path Dependency, turned from a paragraph into a check.
Distribution & Observability: never trust the average
The last one is the principle the whole tool is built around. On a Galton board, the average ball lands dead center — and tells you almost nothing. The story is in the tail: the 3-sigma outliers, the 0.3% that break your assumptions and, not coincidentally, where the business value concentrates.
A single “org health score” is that useless average. It hides the tail. So orgspark refuses to give you one number and stop. It shows every component — the healthy ones included, because an assessment that only shows problems can’t prove it looked. And it does the thing most tools quietly skip: it names what it hasn’t judged. There’s an “Unassessed Surface” list, per org, and the rule there is blunt — silence means unassessed, never healthy. Measuring the average is easy. Refusing to let the average lie is the actual work.
The honest edge
Here’s where I keep myself honest. The board orgspark reads today is structure — the metadata, the pegs you can see in the config. That’s a real slice of the whole board, and it’s genuinely useful. It is not the whole board.
But the part it doesn’t read yet isn’t hidden — it’s on that Unassessed Surface list, in your own report, staring back at you. The engine was built to grow into it. This is version one of a long idea, and the idea started with a bunch of balls falling through pegs.
Read your own board
You don’t need an account or even an org to see it work — there’s a bundled sample seeded with 50+ real problems, and you can watch exactly what gets caught.
→ salesforcebinge.github.io/orgspark
Want it on your real org? The page hands you a read-only script, shows you everything it found, and asks before it retrieves a thing. Nothing uploads — it all runs in your tab. Drag the folder in and read your board.
Last year I said Salesforce orgs fall like balls on a Galton board. I still believe it. The difference is that now you can drop your org into the top and watch where it lands.
Until next time! 🙂
