I rewrote a paragraph on my consulting site this week.
The old version said: "I diagnose your operations, redesign the system, and build the custom tools your team needs. You keep the keys."
The new version says: "I design the operational spine your team actually needs. Your people render it however they work — email, chat, voice, dashboard. You keep the keys."
Two sentences. Same service. Completely different sale.
Here's what changed my mind.
The week the model broke
Salesforce went fully headless.
If you don't live in software, here's why that matters. For twenty years, business software has been priced per seat. The entire model assumes a person logs in, clicks around, and gets value from a dashboard. That's what you're paying for when your CRM costs $120 per user per month.
Agents don't log in. They make API calls. One company running 50 agents can do more work in a day than a whole sales team does in a month. None of those agents need a dashboard. They need the data model and the workflow logic underneath it.
When the biggest name in business software strips out the dashboard entirely and sells only the API, the signal is not subtle. The UI is not the product anymore. It never was. It was the delivery mechanism.
The durable asset was never the screen. It was the data model and the workflow logic.
I've been building exactly that for small nonprofits for three years. I just didn't have a word for it.
What I thought I was selling
For three years I've been pitching Groundwork — my consulting practice — as "custom operations systems." That's accurate but fuzzy. When a nonprofit executive director hears "custom operations system," they picture a dashboard. Something they'll log into. A thing with screens.
So I'd build the screens. Clients would use them for a few months. Then usage would taper. Not because the system stopped working — the automations kept running, the integrations kept firing, the thank-yous kept getting drafted. But because logging into a dashboard is work. Staff would rather see the result in the inbox they already check than open a new tab.
I kept building the dashboards anyway because that's what the sale implied. The client expected screens. I delivered screens. Everyone walked away happy the day we launched. Six months later, the screens were the least-used part of the system and I couldn't articulate why.
I can now.
What I actually build
The spine is the data model plus the workflow logic. For a venue like the one I run, that's:
- The donor table, with every gift, every thank-you, every impact credit
- The partner table, with every relationship, every past collaboration, every decay signal
- The event table, with every show, every budget line, every post-event report
- The workflow logic — when to draft a thank-you, when to surface a stalled grant, when to flag a donor relationship that's been quiet too long
That's the asset. That's what has to be right. Once it's right, the rendering is almost trivial. Thank-you drafts land in an email queue. Decaying relationships surface in a Friday digest. Stalled grants ping Slack on Monday morning. No dashboard. No login. No tab.
I built an automation engine for my own venue — 18 evaluators behind a single API. It has no UI at all. It still delivers the full operational outcome, because the spine is what does the work. The rendering is whatever the user wants it to be.
Enterprise architects have called this a "data spine" for years. Small organizations need the same idea, rendered differently — for people who don't have attention budget for another dashboard.
That's the thing nobody else is selling to nonprofits. Everyone is selling dashboards.
Why this matters for small orgs
Most small nonprofits have tried a dashboard-based tool and bounced. They bought a CRM. They bought a donor management platform. They bought a volunteer scheduler. After six months, one or two people were logging in, the data was stale, and the tool had quietly become a line item nobody wanted to cancel but nobody wanted to defend.
The instinct is to blame the team. "We never adopted it properly." That's wrong.
The tool was the wrong shape. A three-staff nonprofit doesn't have attention budget for a dashboard. What it has is an inbox everyone already checks. A Slack channel that's always open. A five-minute voice note on the drive home. A Friday digest the ED can scan in the parking lot.
If the spine is right, the rendering can meet people where they already are. That's the thing that makes operations stick.
The question stops being "what software do we buy." It becomes "what should our operational spine actually do, and how should it show up for each person on our team." Those are different questions with different answers.
What I'm telling clients now
The new sales conversation is short.
"You don't need another dashboard. You need the thing the dashboard was supposed to do, delivered however your team actually works. I design the spine. Your team decides the rendering. When the rendering needs to change — because someone prefers voice over email, or you hire someone who wants a dashboard after all — the spine doesn't change. Only the surface does."
Nonprofits I've talked to this week get it immediately. Their eyes focus when I say "you don't need another dashboard." They've been that person. They bought the dashboard. They bailed. They blamed themselves.
The spine framing gives them permission to stop looking for the right tool and start asking the right question. That's worth more than whatever software they were about to evaluate.
The part I'm still figuring out
I don't have this fully worked out. The assessment template still leads with tool questions instead of spine questions. The proposal deck still opens with dashboard screenshots. The website hero is halfway into the new language and halfway into the old.
What I know is the direction. The durable asset is the spine. The rendering is whatever fits the moment. The sale is the design of the spine, not the construction of the screen. Everything that follows has to align to that.
The work doesn't end at "pivoted." It just gets more interesting.