Cross-platform spreadsheet
A desktop spreadsheet for Windows, Linux, and macOS whose Rust engine recalculates a million formulas in milliseconds.
Research and development is the work before a product is certain: proving that a technique works, measuring whether a target can be met, or building the module and tooling that make it possible.
A cross-platform spreadsheet whose Rust engine recalculates a million formulas in milliseconds, and a C++23 entity-component library for games and simulations.
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 and measure a baseline on real data before we write anything, and turn the question into something testable.
Rust where it helps, 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 benchmarks, reported under stated conditions with the limitations. A clear no is a valid outcome.
Something you can run from the first week, so decisions are made on a working prototype.
You talk to the engineers doing the work, and you get a written status update every week.
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.
6–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 calculation can meet a latency target, a local workflow can survive disconnection, or a native module helps 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 say so. For IoT, embedded, simulations, or other unfamiliar domains 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.