We build things that work. The credibility follows.
Some of the most useful open source tools started as a collaboration between a practitioner with a real problem and a company with the right technology to solve it. Not as marketing exercises — as genuine engineering work that happened to benefit both parties.
ShippingBytes does this kind of work deliberately, under the name Build & Validate.
In 2017, we built Orbiter — an open source autoscaler for Docker Swarm, written in Go, that used the InfluxData TICK stack to trigger scaling decisions based on real metrics. It solved a gap that Docker Swarm didn’t address natively. InfluxData supported the work because their tooling was genuinely the right fit for the problem. The result was a working tool that people ran in production, a conference talk at Docker HQ in San Francisco, and a webinar. The community engagement was real because the software was real.
That’s the model. A real problem, the right technology, working code — and a natural case for why the technology fits.
Two contexts where this makes sense
The work looks similar in both cases — we think through the problem, we build something that actually runs, we document it properly. What differs is the goal and the audience.
Community & OSS
Build something the community finds genuinely useful.
We identify a real problem in the cloud-native or infrastructure space, design a solution that uses your technology where it’s the right fit, and build it — properly, with working code, documentation, and a public repository. It can become a talk, a blog post, a library others build on. The community value comes from the software being worth using, not from how it’s packaged.
Pre-sales & go-to-market
Prove fit with a working integration, not a slide deck.
You have a specific customer, vertical, or use case you need to demonstrate. We build a real integration — one that runs in their stack, handles edge cases, and could realistically be taken further by their team. Something a technical buyer can evaluate seriously, not just a demo that works under controlled conditions.
Why this works
The value isn’t that we make your technology look good. The value is that we find the problems where your technology genuinely is the right answer, then build the solution properly enough that it stands on its own.
That requires someone who has spent enough time in the ecosystem to know where the real gaps are, and enough engineering depth to close them credibly.
Docker Captain since 2016. Recognized by Docker for technical contribution and community work — part of a small group that has shaped how the container ecosystem thinks about tooling and practice.
Former CNCF Ambassador and Kubernetes Release Engineer. Contributed at the project level — shipping Kubernetes releases, advocating across the cloud-native ecosystem in Europe and beyond. Not just a user of these tools.
Conference speaker across Europe and the US. KubeCon, InfluxDays, InfoShare, DevOpsCon, Docker events. Technical sessions for practitioners — the same audience your engineering-focused customers belong to.
Open source contributor and maintainer. Kubernetes, InfluxDB, Docker, TestContainers, Tinkerbell. We’ve shipped patches, maintained projects, and operated software in production. That informs how we build.
What an engagement looks like
Problem definition. We start by finding the right problem — one that’s real, that your technology addresses well, and that’s worth solving for its own sake. If the use case has to be invented, the result won’t hold up.
Build. Working code. Reproducible. Documented well enough that someone else can take it further — because sometimes they do.
Publish or deliver. For community work: a public repository, a writeup, and optionally a talk or webinar. For pre-sales work: a deliverable your team can put in front of a technical buyer with confidence.
Scope and timeline are agreed before any work starts. We don’t begin building until we agree on what done looks like.
Let’s find the right problem.
The best engagements start with a genuine technical gap, not a marketing brief. Tell us what you’re building, what problem you think it solves, and who you’re trying to convince.
info@shippingbytes.com · subject: "Build & Validate — [your tool / your goal]"
We respond personally. No forms, no account managers.