MintID Renewed at Twice the Original Budget. This Is the Work Behind It.

A case study written by the vendor is worth about as much as the fact at the bottom of it. Ours: MintID opened this engagement on a €200,000 budget. On the strength of the work delivered, they have signed a new engagement of €400,000 more — a renewal twice the size and the commitment.

The work underneath that number: three engineers and one delivery manager, all on Conectia's payroll, embedded in MintID's build since March 2026 and at full cadence by April. The same squad has built the protocol's core and, since July, its three verifier SDKs — TypeScript, PHP, Python — all tested. Every deliverable met its date. Zero bugs.

We write this from the delivery seat, and we should name the obvious: we sell embedded squads, and this is our own engagement. What keeps it honest is that the load-bearing facts are not ours alone — the client's five-star review is public and in his own words, and the engineering itself is documented in our walkthrough of the verifier SDKs. That post is the what. This one is the how it was delivered.

MintID's hardest code runs on machines MintID will never see

Most of the protocol lives on territory MintID controls: a frozen spec, consensus in Go, the anonymous-credential core in Rust. That perimeter is where the squad's first months went — building the core of the tool itself, from the client's architecture. The verifier SDKs are the first artifact to leave that perimeter. They run inside integrators' stacks, on infrastructure the protocol will never own, at the exact point where its guarantees are either enforced or quietly dropped.

That makes them a hard buy, for reasons that have nothing to do with volume:

• Nine acceptance conditions must always run in full — origin binding, fresh nonce, requested-policy match, current issuer state — with no partial path through them.
• Presentation lifetime is a constant in the code, not a setting an integrator can stretch.
• There is no policy surface at all. No verifyPartial(), no skipOriginCheck. The type system refuses to express a weaker verifier.
• One verification core wears three languages. TypeScript, PHP and Python are ergonomics; the acceptance pipeline underneath is one implementation with one behavior.

Zero knobs is a lovely property in a spec and an unforgiving one to build against. Every shortcut a tired engineer might reach for has been removed by design, which means the code has to be right on the way in. As the client put it in his review: «our project is a complex blockchain protocol system for Know Your Agent identity in the agentic era, so not every software developer can take on this challenge.»

We answered with four people on our own payroll, matched inside a week

The staffing shape was three engineers and one delivery manager, matched directly to the brief rather than handed over as a pipeline of CVs for MintID's architect to sift. The squad that showed up is the squad that shipped.

Three structural facts made that possible, and they are the same three on every engagement we run:

1. The engineers are directly employed by Conectia — across 2 countries, under enforceable contracts with IP assignment, not a marketplace chain of contractors. When the code in question is the most delicate in a protocol, «who legally employs the person touching it» stops being a procurement formality.
2. Vetting is CTO-led. The filter is production judgment rather than résumé keywords — which is what a zero-knobs codebase tests.
3. Matching runs in 72 hours, with no recruitment fee. In this engagement the whole team was standing inside a week, which is the part the client chose to lead his review with: «Conectia gave us a highly technical working team with outstanding project management within a week.»

The relationship started in March 2026 with the protocol core itself; the verifier-SDK phase — the first integrator-facing deliverable, and the publicly documented one — has been running since July. A squad that has built the core is also the squad you want writing the code that enforces the core's guarantees somewhere else.

The squad runs autonomously; architecture crosses the boundary every sprint

The working model is deliberately thin. There is one standing ceremony with the client: a weekly check-in. Everything else is a boundary drawn once and respected.

What crosses that boundary, each sprint:

• Inbound: high-level architecture, handed over by MintID's architect, Marc Miró i Rierola, at the start of the sprint.
• Owned by the squad: decomposition, implementation, tests, review, and delivery on the agreed date.
• Owned by our delivery manager: cadence, reporting, and being the single person the client escalates to.
• Never crossing: day-to-day coordination of individual engineers. That is our job, and charging the client for it in meeting hours would defeat the purpose of buying a squad.

This is the forward-deployed doctrine applied to a protocol build: the client keeps the architecture and the stakeholder-facing work; the squad takes the delivery arc end to end. The client's own description of what that bought him is the cleanest statement of the model we have seen from the buyer's side: «Conectia has allowed me to focus on White Paper writing, high level architectural decisions and stakeholder management while they handle EVERYTHING on engineering and I know I do not need to worry.»

The delivery record is three SDKs tested, every date met, and zero bugs

All three SDKs — TypeScript, PHP and Python — are tested. Every deliverable landed on the date it was committed to. No bugs have been raised against what we shipped.

«The deliverables will come on time and in excellence beyond expectations. No bugs, no delayed deploys, no surprises. Just solid planning and execution.» — Marc Miró i Rierola, architect, MintID

The renewal is the only review that costs the client something

Every vendor can show you a testimonial. A testimonial costs the person writing it a few minutes. A renewal is a review with a price tag on it — and this one is priced at €400,000 more, on top of an engagement that opened at €200,000. Added together, the client has now committed €600,000 to the same four people.

That is the fact we would want a skeptical CTO to check first, because it is the only one in this post that the client paid to make true.

What a case study proves, and who should not buy an embedded squad

One engagement is one data point. It says nothing about the counterfactual — we cannot tell you what MintID's core or SDKs would have cost or looked like with a different team, and no case study can. What it does establish is narrower and still worth something: a four-person embedded squad, dropped into a demanding cryptographic build, hit its dates without generating defects, and the buyer doubled down with his budget.

It also does not generalize to every buyer. An embedded squad is the wrong purchase when:

• The work is a well-specified backlog and you need hands. Buy staff augmentation instead, and keep the coordination in-house where it is cheaper.
• No one on your side can own architecture. The model runs on a sprint-by-sprint handover; with nobody to make that handover, you need a different squad shape — a Managed Squad or a Discovery Squad, which we break down in our guide to roles and squad shapes.
• You want to direct individual engineers daily. Then the autonomy you are paying for is friction rather than leverage, and you should say so before signing, not in month three.

What we would check before signing any embedded squad

Hold us to the same list you hold everyone else to:

1. Ask who legally employs the engineers, and in which jurisdiction the IP assignment sits. Get the answer in writing before the technical conversation, not after.
2. Ask what crosses the boundary each sprint. If a vendor cannot tell you exactly what they expect from you and what they own in return, there is no model — only bodies.
3. Ask what the ending looks like. Documentation, handover, credential deletion. A partner who has never thought about the last week has not thought about the whole engagement.
4. Buy small first. A 14-day Pilot Sprint with a 30-day replacement guarantee is a cheaper way to test all of the above than a six-figure commitment made on a slide deck.

Frequently asked questions

What does an embedded engineering squad cost?

It is priced per engagement, not per hour worked — a flat, scope-bound commitment covering the engineers, the delivery manager, and the management overhead that would otherwise land on your side. The MintID engagement gives you two real reference points: it opened at €200,000 and was extended with a further €400,000 for the next phase. Your number depends on squad size and engagement length; the shape of the commitment does not change.

How fast can an embedded squad start?

We match in 72 hours from a defined brief, because the engineers are already employed rather than sourced on demand. For MintID, the full team — three engineers and a delivery manager — was working inside a week, which is how the client describes it in his own review.

Who manages the engineers day to day?

We do. The delivery manager owns cadence, reporting, and escalation, and is the single person on the client's side of the line. In this engagement the client's involvement is a weekly check-in plus the architecture handover at the start of each sprint.

Is an embedded squad the same as outsourcing a project?

No. The client keeps architectural ownership and the product decisions; the squad owns the delivery arc from decomposition to shipped, tested code. MintID's architect sets direction every sprint — he simply does not spend his week coordinating engineers.

---

The verifier SDKs were the deliverable where MintID's protocol had to survive contact with infrastructure it does not control. The parallel question on the delivery side was whether a squad of four could take on that code with the client's architect at a weekly remove — and the answer he gave, with his signature, was to double the budget.

If you have work that fits that description — hard, specified at the architecture level, and unshippable by adding one more pair of hands — start with a Pilot Sprint.