One of Ted Lasso’s first actions as coach of AFC Richmond was to put a sign above the locker room door with a single word: BELIEVE. While it took a few seasons for the word to acquire its meaning with the team, it was there all along as a literal signpost and touchpoint.
At Datum, we don’t have locker rooms or the chance to put 11 players on the pitch. What we’re working on is more abstract: a first-class connected infrastructure platform for developers, agents, and clouds.
Our company mission and values are the foundation, but honestly, they’re pretty broad. As engineers and designers building a complex, horizontal platform, we need more direction. That’s why we pulled together five product values that are closer to the ground level:
- AX, then DX, then UX
- Build for 1M backbones, 1B tunnels
- Make it fast, sturdy, and ergonomic (function over fancy)
- Be humble, curious, and helpful (we’re operators at heart)
- No weird sales gates, lock-in, or marketing crap
If we had a locker room, we’d tack these up. Instead, I’ll explain what they mean.
AX, then DX, then UX
We put agentic experience at the top because that’s where infrastructure’s future will live or die. If our platform can’t be automated at scale through fast-evolving tools like MCP, skills, and machine accounts, we’re missing what’s next—like ignoring Terraform and Docker in 2015.
Developer experience comes next. Our APIs, SDKs, and CLI tools need to be intuitive for engineers integrating Datum. This is the experience we know best, so it’s tempting to center all our attention here. We’re working to balance it out and stretch our comfort zone.
User experience matters, but only after we’ve nailed the programmatic layers. This doesn’t mean we neglect our UI—it’s hugely important—but we prioritize the machine-to-machine infrastructure future we’re all building.
Build for millions of backbones and billions of secure tunnels
This value keeps us honest about scale before we have it, and inspires us to think differently.
The interesting part isn’t just scaling—it’s helping users take advantage of private connectivity and internet backbones in ways they’ve never imagined. Instead of thinking about “the backbone” as a carefully guarded static component, we want it to be flexible and dynamic.
Make it fast, sturdy, and ergonomic (function over fancy)
Speed, reliability, and usability aren’t negotiable for infrastructure, especially networking.
Speed is a feature. Sturdy means when we say something is durable, it’s actually durable, with failure modes documented and handled. Ergonomic means the common path is obvious and the advanced path is possible.
We’d rather ship something performant and easy to use than a niche feature that looks cool. That’s why we spend time on retry logic, circuit breakers, and graceful degradation rather than adding another chart to the dashboard.
Function over fancy doesn’t mean ugly—it means we earn the right to show off only after the fundamentals are rock solid. Infrastructure should fade into the background, working so reliably that developers and agents are surprised when it doesn’t.
Be humble, curious, and helpful (we’re operators at heart)
We build products we’d want to use ourselves because we’ve all lived the pain of operating infrastructure.
Humble means we don’t assume we know better than our users. We listen, test our assumptions, and admit when we’re wrong. Curious means we dig into why something failed, even when it’s not our fault, because that’s what operators do. Helpful means our documentation is written for someone debugging at 2 AM—error messages point toward solutions, and support doesn’t hide behind sales engineers.
No weird sales gates, lock-in, or marketing crap
This one is simple: we don’t play games. No hidden pricing tiers that force you to “contact sales” for RBAC. No soft lock-in that makes it hard to migrate away.
If you want to try Datum, you can sign up and start using it without talking to a human. If you want to leave, we’ll help you export your data cleanly. We build in the open, communicate our roadmap transparently, and make our documentation accurate.
Values as velocity
Our hope is that these product values help us move faster as a distributed, open source team.
When an engineer is choosing between two approaches, these values provide a framework for deciding without three meetings and a working group. When we’re prioritizing the roadmap, “build for billions” clarifies which architectural debt we tackle now versus later. When someone questions performance testing, “make it fast and sturdy” settles the debate.
Values empower individual engineers to make bold decisions that align with what we’re building, even when leadership isn’t in the room. A shared language that helps us know we’re all pulling in the same direction.