19 Jan 2026
At Sable, we’re a small but mighty team, building a new kind of product that helps scientists tackle one of the most complex tasks in the development of new medicines.
With a tight-knit team and ambitious goals, we know we can’t do everything, so we focus on what makes us stand apart and work hard to automate everything else.
Here's a brief overview of how we think about software at Sable.
Scientists Who Code
Toxicology is a broad and nuanced subject, which presents unique engineering and scientific challenges. We find that the best ideas come from scientists who code, and engineers who take the time to understand the problems our scientific customers face.
That means our engineering practices need to empower everybody to do their best work without steep learning curves or unnecessary technical friction. We care about best practices that help us make rapid progress without compromising our quality.
In particular we focus on testing, readability and convention. Nobody wants to spend their time on regressions, and the domain is hard enough without adding further complexity! Conventional commits means everybody can cut a new release without needing to ask.
Thoughtful Tool Choices
Whenever possible, we avoid commodity work by creating or using tools and automations, so our time is spent mostly on what truly differentiates Sable.
At Sable, a “good tool” is versatile, integrates smoothly with our existing stack, and can grow with us for at least a couple of years, minimising learning overhead and avoiding costly changes.
Some of our favourite third party tool choices include:
Django: A batteries-included framework that solved many common challenges years before we started.
Dagster: A modern data orchestration tool that makes configuring, debugging, and tracking pipelines straightforward - and avoids it becoming a full-time role!
Linear: A fine ticketing system.
One of the automations we built is our Sable CLI - a set of commands for testing, running our applications and making releases. It runs locally and on CI, so once we have a command we like, it is easy to automate.
And we like everything in one place (because there's nothing more tedious than updating versions across 5 different repositories). If needed, an engineer can create the data pipeline, frontend and infrastructure changes all in one pull request (we like generalists!)
Conversely, we steer clear of tools with sharp learning curves. Want to introduce this year’s hottest frontend framework with web workers, a new reactive state library, or incremental hydration? We're all for it if it fulfils a customer need, but we find Web Components work pretty well in most cases.
Why Engineers Join Sable
Joining Sable means working on hard problems where your choices matter. Quite often, you'll be building something that doesn't have a standard and easy solution. Our tech stack is designed to maximise your attention on questions like:
How do you design a data-driven safety report that stays up to date with the latest data, but only updates when a scientist approves relevant changes?
How do you prioritise the most useful evidence for a given biological relationship, when there are hundreds of sources to choose from?
What data model best fits the need to see high-level findings at a glance, while maintaining access to the most specific examples?
If you enjoy these sorts of questions, Sable may be the place for you. You’ll collaborate with scientists, influence tool and architecture decisions, and spend your time building what differentiates Sable: insightful, impactful features that help scientists make safer drugs.
