Introduction
The sloth is not lazy. It is optimised.
A three-toed sloth burns roughly ten times fewer calories per kilogram than a mammal of comparable size. Every movement is deliberate. Every calorie is accounted for. The result is an animal that has survived virtually unchanged for 64 million years — not because it is the fastest or the strongest, but because it wastes almost nothing.
When we sat down to design Slothlike, that metabolic efficiency became our north star. The question was never how fast can we ship features? It was how little do we need to consume in order to deliver exactly what is required?
Rust's tiny footprint and fast response times
We chose Rust not because it is fashionable, but because its cost model matches ours.
A compiled Rust binary carries no runtime, no garbage collector pause, and no hidden heap overhead. RDataCore's Docker images are small and its processes idle at a fraction of what a JVM-based stack would consume. Response times at the 99th percentile stay in the low single-digit milliseconds even under sustained load — not because we threw hardware at the problem, but because the language makes waste structurally impossible.
The Rust ownership model forces you to think about who owns a resource and when it is released. That discipline, uncomfortable at first, pays compound interest over a long project: no
use-after-free, no data races, no surprise allocations discovered in production.For a product that many clients self-host on modest VPS instances, that footprint matters. RDataCore runs comfortably on a machine that would struggle to boot a JVM-based alternative.
| Image | Image size | Idle RAM |
|---|---|---|
| core (API) | 160 MB | ~38 MB |
| worker | 130 MB | ~3 MB |
| maintenance | 120 MB | ~3 MB |
Lean, clean code and high test coverage
Efficiency in compute is meaningless if the code that produces it is a tangle. Slow code rots fast.
We hold ourselves to a simple standard: every non-trivial code path is covered by a test, and every test is fast enough to run on every commit. Our CI pipeline completes in under two minutes, which means developers get signal before context is lost.
Code review has one primary question: is this the simplest thing that could possibly work? If the answer is no, we ask why not. Clever code is a liability. Obvious code is an asset.
High coverage does not mean 100% coverage of every line. It means that the failure modes that matter — authentication logic, data integrity invariants, workflow boundaries — are exercised continuously. A bug that slips past that net is a gap in our understanding, and closing the gap is more valuable than reaching an arbitrary percentage.
Open source by default
We build in the open because opacity is overhead.
When a customer files a bug, a public repository means they can read the relevant code, reproduce the issue, and sometimes send a patch before we have finished triaging. That is leverage we would be foolish to give up.
Open source also enforces a useful discipline: code that will be read by strangers is written more carefully than code that lives only in a private repository. The imagined reader is a good editor.
Not all of our software carries a permissive licence, though. RDataCore is released under its own Business Licence Agreement — a source-available commercial licence. My Family Tree ships under BUSL-1.1. Many client solutions stay entirely proprietary because clients want to keep their processes and data sets private. We are honest about this: open by default where it makes sense, source-available or proprietary where the situation calls for it.
Integrating RDataCore into client stacks instead of rewriting
The hardest problem in enterprise software is not building new systems — it is coexisting with existing ones.
Slothlike's core idea is to integrate into existing systems rather than replace them. We treat RDataCore as the master-data layer: entity definitions, hierarchies, workflow pipelines, and the public API all live in RDataCore, exactly as the client has already configured them. On top of that, we build a thin presentation and orchestration layer — custom frontends, automation scripts, and integration bridges — tailored to each client's stack.
That means no painful migrations, no "lift and shift" projects that take quarters instead of weeks, and no single point of failure. If a client needs to route certain workflows through a legacy system, they can. The architecture expects heterogeneity.
The sloth survives because it works with the canopy it has, not the one it imagines. We try to do the same.
