Native modules for Python, Node.js, and the browser (WebAssembly), developer tools, and feasibility studies. We profile the workload, rewrite the bottleneck in native code, and report the result with reproducible benchmarks.
The lab takes on the technical questions a product depends on: a performance bottleneck, a computation that has to run in the browser or on an embedded device, or tooling for an engineering team.
We work in Rust and C++ and integrate with the languages your team already uses. Every result is reported with its baseline and the conditions it was measured under.
Can the nightly import finish in minutes instead of hours?
Can large drawings open in the browser without waiting for a server?
Can the asset build take seconds instead of minutes?
Can one small device process 10,000 sensor readings a second?
A desktop spreadsheet whose Rust engine recalculates a million formulas in milliseconds, and a C++23 entity-component-system (ECS) library for games and simulations, with the numbers from their benchmarks.
A desktop spreadsheet for Windows, Linux, and macOS whose Rust engine recalculates a million formulas in milliseconds.
A header-only C++23 entity-component-system library with dense storage and measured iteration.
We read the code, measure a baseline on real data, and turn the question into a testable hypothesis before writing anything.
Rust or C++ for the bottleneck, and the team's existing language everywhere else, so the module fits the codebase.
The smallest prototype that can settle the question. Everything around it stays a stub until the answer is in.
Results come from reproducible benchmarks and are reported with the hardware, the dataset, and the limitations, including when the answer is negative.
The work produces code you can run (a prototype, a benchmark, or a module), and the report is written from its results.
You talk directly to the engineers doing the work, so questions are answered by the people who know the code.
We work in your repository, review with your team, and leave tests and documentation behind.
A fixed number of weeks at €1,500 a week, agreed up front. When the answer is yes, the tool or module is built as a first release at the MVP package price.
New software is judged against the mature products people already use, so we build the first release as a complete product: every workflow in the agreed scope, together with the admin interface, access control, reports, notifications, and the infrastructure it runs on (automated deployment, backups, monitoring).
The engineers who build the release also agree its scope with you. Common parts start from components we have already tested, so most of the time goes into your workflows, built on an architecture that scales as the business grows.
Rethinking the startup MVP, by Linear6–8 weeks from agreed scope to launch
After launch, you agree to a short written interview for a case study. We agree what gets published before the project starts.
EU companies with a VAT number pay exactly this amount (reverse charge).
A question with a testable outcome: whether a computation can meet a latency target, whether a sync protocol tolerates disconnection, or whether a native module speeds up a particular workload.
Only after measuring the workload and testing an approach. We establish a baseline first and report improvements under stated conditions.
Yes, and we state it up front. In a domain that is new to us (IoT, embedded systems, or simulations, for example), we take on a defined feasibility question, agree the unknowns and the time limit, and report what we find.
Not automatically. We distinguish the experiment from the hardening, integration, and operational work needed for production, and estimate that work separately.
