Most of the software people associate with Appomart is the kind you can picture right away: an app you install, a site you browse, something built for a consumer who downloads it and starts tapping around. A smaller, less visible part of the work is software built for a business to solve one specific operational problem that nobody outside that business ever sees. This is a close look at that second kind, through a project currently being built for a narrow, professional audience: testing laboratories.
It is worth saying upfront that this is early work. The sign-up flow does not fully work yet, and there is no legal paperwork behind it. So treat what follows as a look at a real problem and the direction taken on it, not an invitation to go and use anything today.
What a testing laboratory is actually accountable for
To see why this problem is worth software at all, it helps to know what a testing laboratory does and does not get to decide for itself.
- Area of accreditation
- A fixed, officially granted list of what a laboratory may measure, in which units, by which method. Anything outside that list, the lab is not allowed to measure and report on — even when it is technically capable of doing so.
- Test report
- The document a laboratory issues after a measurement, built strictly within its area of accreditation. It is not an internal note: products ship on it, and official orders get closed on it.
What gets measured this way covers drinking, waste and natural water, air, soil and waste, food products, construction materials, and workplace conditions. Food and water sit at the top by volume, because they are tested constantly and on a fixed schedule: a batch of product usually cannot ship without a report behind it.
Where the paperwork actually breaks
The same test report tends to exist in three places at once: a printed form, an internal registry kept in a spreadsheet, and an export file built for the regulator's own system. Nothing connects these three automatically, so the same values get typed in three times by hand, once per place, before a single report is considered done.
Whoever is on shift that day shapes the result. One person writes a date one way, another writes it slightly differently; one picks a method label from memory, another copies it from the previous report, which may itself have been wrong. And it is rarely the laboratory that catches a mismatch like that first — it is the regulator's intake, on the other end, well after the measurement itself is finished.
The two ways this goes wrong are not equally serious. A report bounced back for a formatting mismatch costs the lab a few hours of rework and nothing more. An expired equipment calibration buried in a file, or a method quietly used outside the lab's actual area of accreditation, is a different kind of problem — a question about the laboratory itself, not about a document. And because the usual fix is to patch the one file that got rejected rather than trace the mistake back to where it started, the same error has a habit of quietly reappearing on the very next submission.
An industry moving from scans to structured data
None of this is specific to one registry or one regulator. The same shift is under way everywhere a testing industry reports into a government system: paper forms and scanned documents are giving way to machine-readable data. A method name, a unit, a substance used to be something a lab could simply type in its own words on a printed page. Increasingly, it has to be picked, exactly, from an official reference directory that the receiving system already recognizes.
That one change is most of why dedicated software is suddenly worth building here. A field filled in by free text and a field chosen from a fixed list behave completely differently — one tolerates a typo, the other does not — and very little of the tooling laboratories have used for years was built with that distinction in mind from the start.
How uneven this industry already is
An open dataset covering one country's laboratories over a single month this year gives a sense of just how differently this plays out from one lab to the next. In that same month, under the same rules, in the same regulated industry, some laboratories filed only a handful of test reports, while others filed well over a thousand.
The usual caveats apply: this is one country, one month — May 2026 — and a lower bound, since it only counts what is visible in open data. Even so, the shape of it is unlikely to surprise anyone who knows the industry: a three-order-of-magnitude spread, inside one regulated field, at a single point in time. A tool built for the laboratory filing a handful of reports a month has very little in common with one built for the laboratory filing a thousand.
What is being built, and what it deliberately is not
A project along these lines is being built right now, aimed squarely at the paperwork problem described above: pulling a laboratory's accredited methods and past results into one place, and preparing the file a regulator's system expects, instead of rebuilding it from the internal registry by hand every single time. Where a source document is scanned or typed, it can extract the relevant fields and flag the ones worth a second look — a method label typed in six months ago by someone who has since left is exactly the kind of thing worth flagging before it quietly becomes someone else's mistake.
What it is not, on purpose: it is not a laboratory information management system, and it does not try to become one — sample intake, sample handling and the underlying calculations all stay outside it. It does not submit anything to a regulator's system by itself either: it prepares the file, and a person at the laboratory is the one who uploads it. And wherever it reads a document automatically, it only extracts and highlights data — a person still confirms every field before it goes into a report.
The current version of the project lives at lab.regora.ru. Given where it stands — described honestly above — this is worth a look if the problem sounds familiar, not a recommendation to start relying on it today.
Why this kind of work is worth talking about
None of this looks like the software most people picture when the word "app" comes up. There is no download, no feed, nothing a thousand people open this week. It is, instead, the part of corporate software that almost never gets talked about in public: narrow, specific, built for a professional who already knows exactly what they need and can tell within minutes whether a tool actually understands their work or just looks like it does. For a studio that also builds the consumer-facing kind of software, keeping this muscle — the patient, unglamorous, corporate kind — working at the same time is exactly the point.
