A system, taken from the idea to the thing that runs.
Red Sentra builds software to a requirement rather than assembling it from a template. The same engineers scope the work, write it and stay with it once it is live.
Responsibility
What we take on.
- The architecture, and the reasons it is shaped that way
- Implementation, by the people who scoped it
- The infrastructure the system runs on
- Release, and what happens the first time it fails
- Ongoing operation, where the engagement continues past launch
Engineering
What arrives, and what leaves
A client arrives with an idea, a product that has outgrown its first design, or one subsystem that has become the thing everybody is afraid to touch. Red Sentra can take any of the three, and does not require the whole product in order to be useful.
What leaves is a running system with an architecture somebody can explain, deployed on infrastructure that was designed rather than accumulated, and a team that has not disappeared.
The first conversation is with an engineer
There is no sales layer to get past and no handover from the team that sold the work to the team that does it. The first conversation is about what the system is up against: the load, the protocol, the data that arrives malformed, the thing that already broke once.
A specification written before that conversation usually encodes a solution rather than the problem. That is also why the number of concurrent engagements is small.
Failure boundaries before features
The first architectural question is what is allowed to fail without taking something else with it. In Vestry that produced a protocol-facing layer holding session state alone, so a hostile stateful protocol cannot become a product outage.
A state change written to a database and an event published separately is a system that can tell a story its own data does not support. Lexora commits both in one transaction through an outbox, and publication becomes a retryable step that can fail without producing a lie.
What the work can include
Discovery and technical scoping, product and system architecture, backend and service implementation, APIs and integrations, web and mobile clients, the AI layer where a product genuinely needs one, infrastructure and deployment, and production operation once it is live.
It can also be exactly one of those inside a product somebody else is building. Red Sentra takes responsibility for an engineering outcome, not for a seat on another company’s team.
An engagement can be a question rather than a build
Some of this work is not a system. It is an architecture read before a rebuild is committed to, a second opinion on a design somebody has already argued about internally, or one hard technical question answered by the engineer who would have to live with the answer.
Those engagements have a defined end and produce something specific — a written architecture, a decision with its reasons, a scope somebody can fund. They are a shape of work, not a change of business: Red Sentra performs consulting, and is not a consultancy.
Evidence
Systems this rests on.
Each entry names the contribution Red Sentra declared on that system. Nothing here is cited for work the content model does not carry.
Lexora
A commissioned product with an event-driven core: a state change and its events committed together through a transactional outbox, with slow work moved to background workers outside the request.
Vestry
Four Rust backend services over gRPC, with Protocol Buffers as the contract and the protocol-facing layer isolated from the product services behind it.
NutriSense
A Go backend behind a Flutter client, with an assistant that resolves a meal written in plain language into individual foods before anything is written down.
Limits
What this page does not claim.
- No client is named, and no partner is identified. Commercial terms stay private.
- No project count, contract size, delivery-time or cost-saving figure is stated, because none has been published.