What we mean by 'we ship solutions'

Four words sit on the home page of xipherlabs.xyz: we ship solutions. They are the most important sentence we wrote this year — not because they are clever, but because they are exclusionary. Most consultancies cannot honestly say either word.

This is what each of those four words means, and what they are explicitly meant to leave out.

"We"

There are two of us. There is no scaled team behind the website. The two founders do the work, with a small set of senior operators brought in by name when a project needs a discipline we don't carry full-time.

That is the entire company. No account managers. No "delivery leads". No staff augmentation. The person who writes you back from the contact form is the same person who will write the spec, run code review, and stay on the line when something breaks at 2am.

This is a constraint, not a virtue. It limits how many projects we can take on. We accept that on purpose — it is the only way "we" remains true.

"Ship"

We use "ship" in the literal sense, not the marketing one.

Ship means a real user is running real code against real data, today. Not a demo, not a Figma flow with click-through, not a "production-ready prototype". One of those is a deliverable; the rest are advertisements for deliverables that may not exist.

Demos are not products. Demos are advertising for products that may not exist yet.

When Marty Cagan separates "discovery" from "delivery" in Inspired, he is making the same distinction. Discovery is necessary. It is not shipping. You ship when the user can do the thing.

The reason this matters: agencies sold demos as products for a decade and got away with it because the gap was hard to measure. AI commoditised the demo. Anyone can produce one in an afternoon now. The work that still has scarcity is everything after — the production code, the migration plan, the observability, the on-call rotation. That is what we mean by ship.

The DORA research, summarised every year in the State of DevOps report, is unsparing on this: the teams that score highest on delivery performance are not the ones with the fanciest demos. They are the ones with deployment frequency, lead time, and recovery time inside known bands. We measure ourselves the same way.

"Solutions"

This is the most important word and the most over-used.

A solution, the way we use it, is a piece of work whose value can be observed, not asserted. You can point at it and say what is different now. Some example concrete shapes:

• A backlog of public-procurement tenders that used to require four interns to monitor — now handled by Licit.ar for a fraction of the cost, with audit-grade traceability built in.
• A patient who can revoke access to their medical record in one click and verify the revocation propagated within seconds — what BioVault is designed for.
• A community that distributes rewards by contribution rather than by who holds the most tokens — what Membership OS makes permissionless.

A feature is "we built X". A solution is "Y no longer happens to the operator".

Confusing the two is the most common failure mode in B2B engineering work. Teresa Torres in Continuous Discovery Habits calls this the difference between opportunity and solution in product discovery — we like the framing but use it harder. If we cannot describe the Y no longer happens before kickoff, we are not yet at the solution stage. We are at the feature stage. We say so.

What we are not saying

The sentence is also useful for what it excludes. By committing publicly to "we ship solutions", we are deliberately not saying:

"We deliver consulting engagements." Consulting is opinions delivered in slides. We have opinions, and we deliver some of them, but the deliverable is software that runs in production with our name on the git blame.

"We build MVPs." Most MVPs are demos with extra paperwork. We wrote about why that fails before code starts. We will help shape an MVP, but only if the path to a shipped solution is plausible from the first whiteboard session.

"We scale your team." Staff aug is a different business and we are not in it. We bring our own bench and bring it for a specific outcome, not a headcount target.

"We accelerate your roadmap." Acceleration is a vector with two ends. We will not move a team faster toward a destination that is wrong; that compounds the cost. Shape Up's "appetite" framing is closer to the right verb: we fit work to a budget. Speed falls out of clarity, not the other way around.

The contract this implies

If we are going to keep "we ship solutions" honest, four things have to hold every time:

1. We pick the problem with you, in person, before anything else. A real conversation about a real operator pain. If the conversation cannot end with a one-sentence problem statement, we do not engage.

2. We define what "shipped" means in writing. A specific user, a specific behaviour, a specific telemetry signal, a specific date. If the operator is willing to sign a sentence beginning with "shipping looks like…" we have a project. If not, we do not.

3. We run the work in production from week one. Not a staging environment we admire — production, with real users, even if the cohort is small. The DORA performance bands assume continuous deployment for a reason.

4. We stay long enough to hand it off properly. Code, runbooks, observability, the names of the people who can answer questions about it. We do not declare done and disappear.

If any of those four cannot hold for a given project, the right answer is that we are not the team for it. That is fine. Saying no is the highest-leverage decision a boutique consultancy can make.

Where this lives, in practice

Today the four words sit in the hero. Internally they live in our project intake checklist — every new engagement is scored against the four points above before it gets a green light. About one in three conversations result in a project. The other two end with us recommending another team, another tool, or another moment in the company's life.

That ratio is the point. The sentence on the home page is not a slogan; it is a filter. The work we do take on is the work where we can answer "yes" four times in a row.

If you have a problem in that shape, the contact form is the right place to start.

Further reading

• Inspired — Marty Cagan. The discovery / delivery distinction we use daily.
• Continuous Discovery Habits — Teresa Torres. For the opportunity vs solution framing.
• Shape Up — Ryan Singer / Basecamp. On "appetite" as the right unit for project scope.
• State of DevOps Report 2023 — DORA / Google Cloud. The empirical case for "ship continuously, measure everything".
• Working Backwards — Colin Bryar & Bill Carr. On writing the press release first.

>  end of article · v0.1 · 2026