nucleusStart with a database and some tools. Finish with an app.
On Nucleus, a new product can start as a database and a set of MCP tools that Claude drives, before anyone has designed a single screen. When it's ready for people who don't work in Claude, give it a web interface, and Nucleus hosts it: signed in, permission-checked and kept live. You never set up a separate login, a separate server or a second copy of the business rules.
How Protolyth grew, without a rewrite
Protolyth is the lead pipeline behind a sales campaign. It stages leads, enriches them, flags problems, drafts outreach and tracks each lead until it signs up and pays. It wasn't planned as an app. It became one because people needed it to be.
A database and MCP tools
Vendor-enrichment tools and a database, installed in Nucleus like any other server. Claude was the whole interface: the operator asked, and the tools answered and wrote.
The rules took shape
Contentions that block bad sends, lead staging, enrichment that won't re-buy data, deals. Each rule was written once, as a tool, and tested in conversation before any screen existed.
A team app, hosted by Nucleus
A review screen for drafts, then sign-ups, lead claiming, each rep's book of leads, a leaderboard and role-based access, all on the same database and the same rules.
What the team sees
A rep opens Protolyth from Nucleus and lands on their own day: what they've closed, what they're working, and which leads need them. The same people reached the same data from Claude a week earlier.
Good morning, Sam
locales_disabledQuote covers 4 languages; 1 is switched off on the live site.
- Organization
- Example Yoga Studio
- Site seen?
- yes observed
- Script live
- yes observed
- Competitor
- none detected
- Locales
- en, de, fr, es
- Pageviews / mo
- 41,200 vendor
- Foreign share
- 38%
- Suggested tier
- Core
…
One set of rules, reached two ways
The app's API and the MCP tools run in the same process and call the same database functions. A person clicking Approve and Claude calling the tool can't get different answers, because there's only one implementation to disagree with.
Clicks Approve in the review screen
Same functions, same validation, same contentions, written as the person who acted
Calls approve_draft through Nucleus
What Nucleus gives every app
Hosting an app is a general platform feature, not something built for Protolyth. Registering one is configuration: an app name and an internal address on the MCP server's catalog entry.
Nucleus authenticates first
The app is reached through Nucleus at /apps/<name>/. Its API is served only after Nucleus has signed the person in, so the app never builds a login of its own.
Only people who have it installed
On every request, Nucleus checks that the person has the app's server installed. Removing the install removes access to the app.
A real name on every write
Identity headers sent by the browser are stripped and replaced with the ones Nucleus vouches for, the same ones it sends to the MCP server.
No public address of its own
The app container has no published port and no public route. The only way in is through Nucleus, and an app can only point at internal services.
Websockets included
Live connections go through the same authenticated path and are refused if they come from another site. That's what keeps the review screen in sync with Claude.
It shows up in Nucleus
Each person's Apps list shows the apps for the servers they have installed, and each app links back to Nucleus.
Protolyth runs a real lead pipeline. Here's the enrichment behind it.