Configurable lab software your super users own
Fields, tests, workflows, calculations and document templates are configuration in Uncountable, set up by your own super users in the interface. A new method with its own units and limits. A viscosity spec that differs between two grades. A certificate template for one market. The real build work is integrations.
Deployed by 175+ enterprise product development teams
Deployed by Enterprise R&D and Innovation Teams
By the time the change request comes back, the project has moved on
On most platforms, a new test method or an extra field on a form is a ticket. It gets scoped, queued behind other customers, and lands in a release; and in the meantime the lab keeps a spreadsheet so the work can carry on. Configuration that only the vendor can touch isn't flexibility; it's a queue with your name on it.
In Uncountable, the change is made by the people who know why it matters: the formulators, lab managers and quality engineers who already know why a viscosity limit differs between two grades, and which of your labs needs to see it. What's left for us is the work that genuinely needs engineering: integrations into ERP, LIMS, instruments and the systems you built yourself. That work is scoped into implementation, not into your licence fee or your renewal.
What it looks like when your own team owns it
A field takes about a minute. A handful of named admins covers a site. One lab's workflows become the template for the rest.
What you can configure without us
Each one is a setting in the interface. The four stages below show how each is set up, and who it reaches.
Configuration, from the first field to the audit trail
Four stages: adding what you measure, adapting how work moves, generating the documents you send, and governing who is allowed to change any of it.
Add the field, the test or the calculation and have it on every form the same afternoon.
Fields on any form: add what your scientists actually record, to the forms they already use.
Tests, methods and limits: a new method with its own unit and spec limit, shown only on the forms that need it.
Spec limits per product: viscosity at 210 for one grade and 100 for another, on the same method.
Calculated columns: the equation that currently lives in a spreadsheet, written onto the record and run on every row.
Request and sample entry forms: the form someone fills in to ask for work, shaped around what your lab needs to know up front.
Display units per material family: with personal overrides, so each site reads what it's used to while the stored value never changes.
Change the route without rewriting what the old records say.
Stages and transitions: add, rename and reorder stages, and restrict which workflow is allowed to follow which.
Who can advance what: set the role that moves each stage on, and who can send one back.
Review gates: require a sign-off where the risk warrants it, and drop it where it only slows a team down.
What a stage needs to close: the fields, attachments and approvals that have to be in place before work moves on.
Versioning rules: major and minor versions, numbered to match the quality system you already run.
Hide what nobody uses: a team sees the handful of workflows it runs, not the hundreds the business has.
Your label, your certificate, your report, built against your own fields.
Labels, CoAs and data sheets: built by your quality team against your own fields, not hand-created each time.
Your own layout: headers, logos, column order and page furniture set to match the document you send today.
Conditional blocks: a declaration that appears only on EU shipments, a result row that appears only for adhesives.
Customer and region variants: one template, as many versions as your markets and your largest customers need.
Printable quality forms: non-conformance reports carrying disposition, quantity affected and the rationale behind it.
Pull in the supporting record: notebook pages, SOPs and safety data sheets attach to the document that references them.
Self-service, with the controls a regulated site needs.
Super-user permissions: you decide who can change what, and nobody else can.
Versioned and attributed: every configuration change carries a version, an author and a timestamp.
Separate configurations per business unit: one instance, without one unit's forms landing on another's screens.
Scoped by site: publish a change to one lab or to all of them.
Audit-ready: the change log exports alongside the records it affected, for 21 CFR Part 11 and Annex 11 work.
A configured starting point: implementation hands your team a working setup, not an empty platform.
Your team takes the keys at go-live
Map how your labs actually work, which systems hold what, and which of your "custom" requirements are configuration.
We set up the starting configuration with you (methods, spec limits, workflows, templates) and bring your legacy data across.
Your named super users are trained on the configuration they'll own, on your own setup rather than a demo instance.
Structured scenarios drawn from real workflows, run by the people who will use them.
Cut over with embedded support, and the first few configuration changes made alongside your team.
New methods, fields and templates are yours to add. We're there for the integrations and the structural work.
What changes when your team holds the controls
The real build work is integrations: so we scope it first
Almost everything else on this page is configuration your team owns. What genuinely needs engineering is the connection to the systems around you, and that gets scoped before you sign. It can add to implementation; it doesn't land on your core licence pricing or come back as renewable ARR. Features we build with you go into the core product and are maintained there.
Here are some real asks from customers. Most of what sounds like a build is configuration your own team owns, and what isn't lands in one place.
One of them you change yourself. The other we build with you.
A platform that can be configured only by its vendor isn't configurable; it's a queue. The line between what your super users own and what genuinely needs building is the most useful thing a vendor can tell you, and you should know where it sits before you commit.
FAQs
Your team. Fields on data entry forms, test methods, spec limits, calculated columns, workflow stages, and report, label and certificate templates are configured by your named super users in the interface. There is no ticket to us and no release cycle between deciding and doing.
Integrations, mostly: ERP and LIMS connections, parsers for proprietary instrument formats, and connectors to homegrown systems. A smaller number of feature requests also become builds, and those go onto the core roadmap rather than into a private version of the product. We scope this work before you sign: it can add to implementation, but it doesn't change your core licence pricing or return as renewable ARR.
Nobody starts from an empty platform. Implementation delivers a working configuration built around how your labs already run, and scientists see the forms for their own work rather than the options behind them. Configuration controls are limited to the super users you name.
Your named admins. Implementation hands over a working configuration and the training to change it, and from then on new methods, fields, workflows and templates are added by your team. We stay involved for integrations, structural changes, and anything that genuinely needs engineering.
Configuration is a setting in the product: your team changes it, and it carries forward through every upgrade. Customisation is code written for one customer, which somebody then has to maintain, and which can strand you on a version only you are running. Almost everything on this page is configuration. The work that genuinely needs building goes into the core product rather than a private version of it.
No. Work we do with you goes into the core product and is maintained there. You stay on the same release as every other customer, and your configuration carries forward through upgrades.
Could your team add a new test method tomorrow?
