Rust engineering
Rust removes a class of bug that gets reported as a security incident rather than as a crash. It does that without a background task pausing your program to tidy up memory. It charges for both in learning time and in hiring. The trade is worth it for a narrow, well-chosen piece of a system. It is rarely worth it for all of one.
01Capabilities
Where a crash would be written up as a breach
We treat Rust as a scalpel rather than a default. The four cases below share one property: something about the workload makes a language that tidies up after you the wrong foundation, and that something is specific enough to point at rather than describe.
- Exposure
The code that untrusted input reaches first
Readers of file formats, network protocol handlers, proxies and stream processors sitting in the path of everything. This is where a mistake in handling raw bytes stops being a crash and becomes the way in, and it is the case where the compiler's guarantees are worth the most, because no amount of review reliably catches that class of defect.
- Timing
Paths where a pause counts as a defect
Pricing, matching and risk paths in fintech platforms, where the response time is agreed in writing and an occasional pause to tidy up memory is not something you can explain away. Steady timing and safe handling of memory together is the combination older systems languages cannot offer on their own.
- Boundary
A single implementation behind a stable boundary
One version of an algorithm or a format, reached from a Python, .NET or Node application, or compiled to run inside a browser. Designing that boundary is most of the work, because a careless one lets the unsafety back out into the callers it was supposed to protect.
- Carve-out
Replacing the constraint, not the system
Carving out the one component that is genuinely the bottleneck and leaving the rest of your stack alone. This is the shape we recommend most often, because it keeps the decision reversible. We do it under an ISO 27001:2022 certified information-security management system.
02Fit
Whether the guarantee is worth what it costs to hire for
Rust is a genuine engineering advance and a genuine cost. The compiler removes a class of bug that review does not catch, and it also slows a team down at first and narrows who you can hire. We would rather name both halves than sell you the first one. Five of the six rows below end somewhere other than a Rust project with us.
| Your situation | What we recommend |
|---|---|
| A response-time ceiling in the contract, no room for pauses, and safe memory handling still required | Use RustThis is the case where nothing else gives you both properties at the same time, and it is worth paying the learning cost for. |
| An ordinary business application: forms, approvals, reporting, a database behind it | We argue againstIt buys nothing here and costs you speed of delivery. C#, Java or Django instead. |
| You need volume, you can add machines, and response time is not written into anything | Usually GoOur Go (Golang) page. Cheaper to write, far cheaper to hire for, and quick enough that the difference will not be your bottleneck. |
| A small microcontroller with a supplier kit and reference designs written in C | Often COur C page, honestly. Rust runs there, and where the supplier support is thin the budget goes on plumbing. |
| A large existing C++ codebase, and you want these guarantees across all of it | Do not rewriteTurn on the checkers and static analysis in the C++ you have, and put new self-contained parts here behind a stable boundary. |
| Nobody on your team writes it, and there is a hard first deadline | Weigh it honestlyEngineers do become productive. The gap between code that compiles and code you would put in front of customers is the part that surprises people. |
Scope
What we own when we propose this is the whole decision. That includes the part that lands on you after we leave. Who can change the component next year, and what happens if that person is not there. And whether the measured gain justified a narrower hiring pool. We run the work under an ISO 27001:2022 certified information-security management system, alongside ISO 9001:2015. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries. If we cannot make the case with measurements from your own system, we will say so and recommend something more ordinary.
Rust pays for itself where a memory bug is a security incident rather than a crash, and where the thing runs long enough for that risk to compound. What people underestimate is the hiring and review cost in the first year. We would rather see a team choose it for one component with a clear reason than adopt it across a product because the benchmarks looked good.
Oleksandr TrofimovChief Technology Officer, unicrew03Delivery
Introducing one component without betting the roadmap
This work goes wrong when it starts as an enthusiasm rather than as a measurement. The sequence below is what keeps it accountable, and what makes it possible to stop.
- Pick one bounded component and one numberA specific piece of the system, with a target that can be measured before and after: worst-case response time, a memory ceiling, throughput on one machine. Without a number the project has no way to be judged and, more importantly, no way to be stopped.
- Design the boundary before the internalsA service interface, a shared library surface or a browser module, decided up front. The boundary is what lets the rest of your stack ignore the fact that this component is written differently, which is the entire point of doing it this way.
- Prove it against real trafficRun it beside the existing component on a copy of the production workload and compare. Synthetic numbers are how these projects get funded and how they get quietly abandoned two quarters later, once somebody checks.
- Settle the maintenance question in writingWho owns this component, whether your team wants to learn the language, and what the fallback is if they do not. Where the answer is that nobody in-house will touch it, that belongs in the decision, and sometimes it should change the decision. Ongoing ownership is what our maintenance and support work covers.
04Stack
What surrounds a component like this
The decisions that usually arrive with a component like this, each with its own page if that is the one you are actually taking.
05Questions
Asked before a team commits to a second language
Answered the way we would answer them live. If yours is not here, it is a good first message.
Yes, and it is often sensible here, because the component usually sits inside a system your people already own. What we will not do is drop engineers into a project where the language was chosen before anyone measured the problem, which is the main way these engagements disappoint. The design is reviewed by an architect outside the delivery team. Capacity is managed teams; an outcome is custom software development.
Go (Golang) unless you can name the constraint that requires the alternative. Go is faster to write, much easier to hire for, and more than sufficient for most network services. This earns the choice when a response-time or memory guarantee is part of the requirement, when the code runs somewhere with nothing installed, or when it faces hostile input. The deciding factor is your requirement, not a benchmark chart.
We can, and in most cases we would advise against it and propose something narrower. A full rewrite converts a working system with known bugs into a new one with unknown bugs, and the language is rarely what was hurting. We would carve out the component that is the constraint, prove the improvement against real traffic, and leave the rest where it is. A whole replacement is a modernization conversation.
Yes, and it should be a real line item rather than waved away. A component nobody in-house can modify is a permanent dependency on whoever wrote it, whatever the code quality. That is why we keep the component bounded and the boundary stable, so the rest of the system stays in languages your team owns, and why we ask early whether your developers want to learn it.
No, and treating it that way is a real risk. What the compiler removes is one class of defect in how memory is handled. It has nothing to say about a missing permission check, a secret in a log, a badly chosen default or a dependency with a known flaw. The review is the same review as on any other component, and the honest gain is that one recurring category of finding largely disappears from it.
A scoping call with an engineer, and for this kind of work we want your measurements first: profiles, timing distributions, memory graphs, whatever exists. An hour of real data moves the recommendation more than any amount of description, and it quite often shows the problem is in the database or the network. You get back a written read on what to change. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based and quoted per project, and we only offer it after the first read, because a fixed number on a system nobody has opened is a guess. Team extension is billed monthly per engineer, and the rate depends on the seniority mix, so it is quoted rather than listed.
Untrusted input reaching code you cannot fully trust?
Send us the component and what it has to guarantee. You will get an engineer's read on whether this is the right tool, including the fairly common answer that your bottleneck is somewhere else entirely.