The Interesting Part Is Not That A Chemist Shipped Apps
Gian Pierre is a chemist, not a software engineer. He still managed to ship multiple real apps.
GlassBank, HealthBridge, and his coaching platform are the proof. The details matter less than the pattern.
That is interesting, but it is not the real lesson.
It also does not mean every business analyst can do this cold today.
What it means is narrower and more important: the method can cross the boundary from software engineers to domain experts when the business logic is explicit enough.
The real lesson is that he started in the right place: the requirement.
Most developers still start too low in the stack. They open a repo and think about routing, components, folders, state, database tables. They start implementing before they have really described the system.
Gian Pierre did the opposite. He thought in terms of what the system should do. Not React. Not architecture diagrams. Not framework identity. Just capabilities, constraints, and user outcomes.
That is why the apps shipped.
The Secret Of Building Any App
At one point, I thought the answer was to generate endless user stories and push them through browser automation.
That was a mistake.
That is when I started pushing Gian Pierre toward the BAZDMEG method.
The real trick is to work with PRD files.
A good PRD is not corporate theater. It is the smallest honest version of the business plan:
- who the user is
- what the system must do
- what states exist
- what must never happen
- what counts as success
- which edge cases matter
My current test for a requirement is simple:
Ask the agent to explain the business plan back to you with the minimum number of tokens possible.
If it cannot do that clearly, the product is still fuzzy.
That is the first BAZDMEG rule:
Requirements are the product. Code is just the output.
Why PRDs Beat Prompt Soup
Developers love to start with implementation details. Folders. Routes. Hooks. State containers. Database adapters.
Users do not buy folders. They buy outcomes.
A PRD keeps the conversation where it belongs:
- capabilities
- constraints
- invariants
- failure modes
- edge cases
When that is clear, the implementation stops feeling heroic. The UI becomes a rendering problem. The code gets lighter because it is no longer carrying product confusion inside it.
That is also why a domain expert can suddenly move very fast. They no longer need to learn the entire software stack first. They only need to explain the system clearly enough that an agent can build against it.
MCP Is The Formalization
This is where MCP becomes more than a protocol.
An MCP tool is a capability with a name, a schema, a contract, and a plain language description. In other words: a formal slice of the requirement.
Instead of telling an agent “build my app,” you give it the actual working parts of the system:
create_client_profilebook_coaching_sessionscore_life_satisfactionrecommend_next_action
Now the agent is not guessing what the system should do. It can inspect the capabilities directly. It can call them during planning. It can see the input shapes, output shapes, and constraints before it writes the UI.
This is the key move.
PRD first. MCP second. UI last.
This is also where spike.land fits.
spike.land is a full-stack framework for MCP-native software. On spike.land, a deployed MCP server is not just an API endpoint. It becomes a usable app surface, a callable runtime, and a distribution unit built on the same typed capabilities.
Quality Gates Are What Make It Real
MCPs alone are not enough. Plenty of people can generate tools. That is not the hard part.
The hard part is admitting confusion early and enforcing quality gates.
If a tool contract is vague, fix the contract.
If a state transition is ambiguous, fix the PRD.
If the failure path is unclear, make it explicit.
If the test is missing, the requirement is not finished.
This is the pragmatic part people keep skipping. They want magic prompts. They want the vibe. They want the illusion that software now writes itself.
No. The leverage comes from clarity plus verification.
When you know how to write MCPs and enforce them with quality gates, the code suddenly becomes weightless. It stops feeling like construction and starts feeling like rendering. The code is naturally cleaner because it is no longer trying to invent the product while implementing it.
Yes, You Can Unit Test Business Logic Through MCPs
You absolutely can, and you absolutely should.
That is not a side benefit. That is the whole point.
Once the business logic lives behind typed MCP tools, you can test the rule itself:
- validation
- permissions
- calculations
- state transitions
- failure paths
No browser. No DOM timing. No UI guesswork. No trying to infer business rules from buttons.
You test the actual capability.
This is how spike.land stays coherent with one developer. The agent plans against the tools, the product calls the tools, and the test suite verifies the same tools.
One interface. Three jobs.
What Gian Pierre Actually Proved
He did not prove that software engineering no longer matters.
He did not prove universal repeatability either.
He proved that most teams still start too late in the stack.
If a domain expert can explain the business clearly, compress it into a PRD, formalize it as MCP tools, and guard it with tests, the rest becomes much easier.
That is the actual trick.
Not vibe coding. Not heroic prompts. Not giant context windows.
The secret of building any app is the requirement.
The framework matters too, but in a different place.
Once the requirement is clear, the framework should make that clarity executable. That is the job spike.land is trying to do.
That same discipline applied in the other direction — reading architecture out of an existing codebase instead of building from scratch — is the basis for the Next.js migration service.
Write the PRD. Turn it into MCPs. Enforce the gates. Test the business logic. Let the UI be the easy part.
The next step is not to romanticize one exceptional builder.
The next step is to make this repeatable with templates, guardrails, and verification so the method works beyond exceptional individuals.
And yes: once you work this way, the code starts to feel naturally beautiful. Not because the model became magical, but because the requirement finally became clear enough to build.