Can an Ecosystem Scale Through Independent Projects Instead of Accumulating Users?
Tonight, Nicola and I completed a small but important step for the MyZubster ecosystem.
We did not add a registration counter.
We did not announce an unfinished platform as if it were ready.
We completed one capability—and made it verifiable.
Nicola’s independent MyZubster project
Nicola is developing an independent MVP inside the broader MyZubster experiment.
The repository is public:
github.com/nicolaususnicola-lgtm/myzubster-mvp
Tonight, we completed its first end-to-end user story:
Create an observation → HTTP 201 → save it → retrieve it → verify it automatically
The application can now:
- accept a valid observation through its API;
- generate an observation ID;
- persist the data to JSON;
- retrieve the saved observation;
- reject missing or invalid input;
- validate latitude and longitude ranges;
- prove the full workflow through an automated test.
What verification revealed
Testing the complete workflow uncovered issues that were not obvious when examining each component separately.
The timestamp was being created when the Python module loaded, meaning multiple observations could potentially share it.
The API could also return an internal error when receiving missing JSON or invalid coordinates.
We corrected both problems.
Each observation now receives its own UTC timestamp, and invalid requests produce controlled 400 responses.
We also improved persistence by writing through a temporary file before replacing the destination JSON file. The automated test uses isolated temporary storage, so it never changes the repository’s real observation data.
A transparent development process
We did not modify main directly.
The work was completed on a separate branch:
zorgax/observation-e2e
We then opened a public pull request:
PR #1 — Verify observation creation, persistence and retrieval
GitHub Actions executed the complete test suite.
The CI passed successfully.
The changes are now public, reviewable and supported by reproducible evidence.
Why this is relevant beyond one Python MVP
MyZubster is based on a simple hypothesis:
An ecosystem does not have to scale only by accumulating users. It can scale by accumulating useful, independently developed capabilities.
Each participant can begin with a small project.
That project does not need to become a giant platform. It needs to solve something real and pass through a transparent development cycle:
Build → Validate → Connect → Measure → Verify → Replicate → Expand
If the project proves useful, it can later become a capability available to the broader network.
Instead of forcing every idea into one centralized application, the ecosystem can grow through independent modules, experiments and services.
One human + one AI
Tonight’s work also tested the one human + one AI model.
Nicola remains the owner of his project and its direction.
Zorgax, the AI coordination layer, can help inspect the repository, identify technical risks, prepare changes and build verification processes.
The AI does not replace human approval.
It helps transform an idea into smaller steps that can be inspected and verified.
The intended relationship is:
- the human defines purpose and maintains control;
- the AI assists with analysis and implementation;
- automated tests provide evidence;
- public repositories make the work auditable;
- the community can review, challenge and improve the result.
What we have—and what we do not have yet
Nicola’s repository is still an MVP.
It is not production-ready.
It does not yet provide a complete MyZubster integration, advanced authentication, scalable storage or a finalized observation standard.
What it does provide is one working and verified capability.
That distinction matters.
Open-source development becomes more credible when we clearly separate:
- ideas from implementations;
- implementations from verified workflows;
- verified workflows from production systems.
Tonight, Nicola’s project moved from the second category toward the third.
The next steps
Possible next steps include:
- reviewing and merging the pull request;
- adding Docker support for reproducible local execution;
- defining a stable observation schema;
- reorganizing application and test data;
- evaluating stronger persistence options;
- documenting how an independent observation project could connect to MyZubster;
- measuring whether the capability is genuinely useful to others.
The goal is not to expand quickly.
The goal is to expand through evidence.
The broader experiment
If the answer eventually becomes yes, MyZubster will not expand simply because more people register.
It will expand because every useful independent project can become another capability available to the network.
That is the experiment.
Build → Validate → Connect → Measure → Verify → Replicate → Expand
MyZubster — Open-source ecosystem
Zorgax — AI intelligence and coordination layer
Principle — Human-controlled, evidence-driven development
Main repository: github.com/MyZubster-Ecosystem/myzubster
Website: myzubster.com
What do you think?
Can an ecosystem scale through independently built and verified projects instead of simply accumulating users?
AI · Open Source · Software Development · AI Agents · Architecture · IoT · Sustainability