Skip to content

Go to journal index

Mantequilla-Soft and the small-team pattern that ships the Hive surface area.

A walkthrough of the github.com/Mantequilla-Soft repositories, the lightweight tooling patterns that hold them together, and why this is the kind of work Labs is built to amplify.

Lab Notes

Most of the Hive network is held up by infrastructure most people never see. The front-ends that render posts, the helpers that handle account creation, the wallets that store keys — that work is shipped by small teams and solo developers who treat the network as a place to build, not a place to speculate.

Mantequilla-Soft is one of those teams.

What the repos look like

The github.com/Mantequilla-Soft organization is a small set of focused repositories. The pattern across all of them is the same:

  • One problem per repo.
  • A working front-end, not a half-finished backend.
  • Public issues, public PRs, public roadmap.
  • A README that explains what it is and why it exists.

There is no token. There is no Discord with a 50-message welcome. There is no “coming soon” landing page. There are just tools, in a state where you can clone, run, and ship.

The tooling patterns

Three patterns show up across the repos. They are worth naming because they are the patterns that let a small team ship real surfaces.

Micro-frontends over a shared account model

Every repo is a separate front-end, but they all read from the same account model. The Hive account is the unit, and the front-end is just a view on the data. That means a new app does not have to negotiate data access — it just reads the chain.

The result is that the cost of building a new tool is roughly the cost of the front-end itself. There is no integration tax.

Public, idempotent endpoints

The helpers in the repos are not SDKs you have to install. They are endpoints you call. The endpoints take an account, return a result, and stay the same shape over time. You can build a whole product on top of public endpoints without ever talking to the team that runs them.

This is the difference between a product and infrastructure. The Mantequilla-Soft repos consistently choose infrastructure.

Ship-the-simplest-thing-that-works

There is no over-engineering. There is no premature abstraction. There is no “we will support that in v2”. The repos ship the smallest thing that is useful today, and let the next repo handle the next thing.

This is the discipline that lets one or two developers maintain a public surface area indefinitely.

Why lightweight works on Hive

The reason these patterns work is that Hive does not penalize them. The chain is fast, the actions are free, the data is open, and the account model is shared. A small team can ship a real product without a treasury, without a token, and without a permission round.

That is the structural advantage we wrote about in the low-cost scale thesis. The Mantequilla-Soft repos are that thesis in production.

What we are learning from them

Labs is using the Mantequilla-Soft patterns as a reference for our own prototypes. The Profile Studio prototype, in particular, follows the same shape: one problem (build a Hive profile), one front-end, public endpoints, no SDK required.

The plan is to publish Profile Studio as a public repo, fork the Mantequilla-Soft patterns where they apply, and credit the upstream work. None of this is a partnership announcement. It is just the right way to ship a small tool on a shared network.

If you maintain a small Hive repo

Three things we would like to see more of:

  • A clear “what is this” in the README. Two sentences, no more. “This is a Hive profile builder. It reads the chain and writes the JSON.” That is enough.
  • A public issue template. The fastest way to get contributions is to make it obvious what a contribution looks like.
  • A “no token” line in the README. It is clarifying. It signals to users that the project is not a vehicle for speculation. It saves everyone time.

The Mantequilla-Soft repos already do all three. The pattern is reusable.


If you ship a small Hive tool and want it surfaced in the journal, send the repo URL to [email protected]. We read every submission and publish the ones that match our editorial bar.