Skip to content

How we work

Four stages, no surprises at the end

The goal of each stage is to make the next one decidable with information, not with faith.

0
platforms in production all under betrivasystems.com
0
countries operating Chile and Mexico
0%
own infrastructure no middlemen on the data
0
lock-in code and database belong to the client

How we work

Four stages, no surprises at the end

The goal of each stage is to make the next one decidable with information, not with faith.

  1. 01

    Diagnosis

    We follow the operation as it actually is today: who does what, where time is lost, what gets written on paper. We come out with the process written down and the problem bounded.

  2. 02

    Design and prototype

    Data model, states and navigable screens. You touch it before we build it: if something does not match reality, it gets fixed while it is still cheap.

  3. 03

    Build

    Short deliveries with the client’s real data, not fake data. Every delivery lands in the environment where it will be used, with its backup and its test.

  4. 04

    Production and operations

    Assisted go-live, training for the people who use it, and ongoing maintenance. The system ships documented and the infrastructure stays in the client’s name.

And that fix arrives when the system is already live

Rebuilding with the operation running is not the same job as doing it right the first time: you are no longer building, you are building and operating at once. This is what gets quoted in each case.

Line item Designed from the start Fixed in year two
Development
Designed from the start Part of the original project
Fixed in year two The entire project, all over again
Data migration line item that did not exist before
Designed from the start Not applicable: the data is born right
Fixed in year two Years of records stored on wrong assumptions, moved without losing a single row
Parallel operation line item that did not exist before
Designed from the start Not applicable
Fixed in year two Two live systems kept in sync for as long as the change takes
Cutover window line item that did not exist before
Designed from the start Not applicable
Fixed in year two A weekend with no service. In healthcare or public procurement, that weekend does not exist
New features
Designed from the start Moving forward throughout the project
Fixed in year two Frozen for the duration of the rewrite
Risk
Designed from the start Contained: the system has no people inside it yet
Fixed in year two Played out against a live operation and real data

The trap is not the price. It is that at signing time this decision is invisible: nobody quotes "without isolation and without auditing". They simply leave it out, and the proposal reads cheaper.

What we do

Full engineering, from idea to server

We do not deliver mockups or slide decks. We deliver a running system, with its database, its backup, its certificate, and the people operating it knowing how it works.

01

Product and architecture

We start from the real process, not from the form somebody imagined. We model the states the work goes through, and only then write code.

  • Operational process mapping
  • Data model and state machine
  • Navigable prototype in days
02

AI grounded in evidence

Document reading, cited answers and assistance for the human assessor. Never a claim without the source behind it: if the system cannot show where it got something, it does not say it.

  • RAG with mandatory citations
  • OCR of documents, images and annexes
  • Local models when data cannot leave
03

Mathematical optimisation

Schedules, shifts, routes and assignments solved with solvers that prove the optimum (CP-SAT, QUBO), not with improvised judgement. The difference is measured in machine hours and work delivered.

  • Resource scheduling under constraints
  • Assignment and capacitated routing
  • Sensitivity analysis: where the bottleneck is
04

Data and traceability

PostgreSQL, parameterised queries and tenant isolation at the database level. Every transition is recorded: who, when and why.

  • Multi-tenant with Row Level Security
  • Audit trail per transition
  • Verified backups, not assumed ones
05

Infrastructure and operations

We set it up, deploy it and keep it running. AWS, nginx, SSL, monitoring and surgical deployments that never take down what is already working.

  • AWS (Lightsail, Route53, S3, CloudFront)
  • Deployment with prior verification
  • Per-application isolation on the server
06

Integrations

WhatsApp, email, payment gateways, invoicing and legacy systems. The new platform coexists with what already exists instead of demanding a clean sweep.

  • Confirmable multichannel messaging
  • Documented APIs (OpenAPI)
  • Migration from spreadsheets and legacy systems

Scheduling engine

A day of radiotherapy, rescheduled in microseconds

This is EIR’s rule solving a full day: 65 sessions across four linacs. Break it — add an emergency, take a machine down — and watch it rebuild. Beside it, the same day solved in arrival order, which is how it goes when there is no engine.

emergency urgent routine
Radiotherapy board simulation with sample data
Linac-1
Linac-2
Linac-3
Linac-4
—
patients in the day
—
machine utilisation
— —
outside clinical window · in arrival order

Same rule that runs in EIR in production: treatment continuity wins, and the oncologist signs the clinical category.

Agents

Agents that answer, book, and cite their source

Not lab demos: they are handling real conversations today. Here you see the conversation on one side and, next to it, what the agent does inside — what it queries, what it decides, and what it writes back into the system.

Answers the clinic’s phone and WhatsApp, books into the same calendar reception uses, and confirms. Formal address throughout, no emojis, one question per turn. In production: takes voice calls and books against the clinic’s real calendar.

AU
Aura
Fisios · clinic in Mexico City
in progress
Agent trace

Script reconstructed from a real conversation, with sample data. Every call in the trace maps to a mechanism that exists in the system.

How we build

The tools we build with, we also build ourselves

This is not usually told on a sales page, but it explains how a small team delivers what it delivers in the time it takes. We are not users of AI tools: we build and maintain the engineering platform we work on every day.

None of this is billed or sold separately. It is the reason what we build can still be maintained three years later.

PostgreSQL + pgvector

Memory of the project, not of the chat

Every project has its code graph, its decision history and its accumulated knowledge in our own database with vector search. What was solved eight months ago is still available today.

llama.cpp · 35B local

Models running on our own hardware

A 35-billion-parameter model on our own machine for the heavy reading and analysis work. No dependency on an external API, and no client document ever leaving the building.

CP-SAT / QUBO

The solver as a daily tool

Combinatorial decisions — what to prioritise, how to allocate, in what order — are not argued about: they are solved with the same solver we later hand to the client.

In-house telemetry

We measure how we work

We instrument our own development process to know where time is lost and what keeps repeating. We apply inwards exactly what we propose outwards.

PostgreSQL 19 · 18

PostgreSQL, from the beta

We run PostgreSQL 19 and 18 in production. Every new release is adopted from its beta: our work is tested against it before it ships, not a year later. We do not just use a database; we follow it.

How we think

Four rules we do not negotiate

Production, not pilots

A pilot that never reaches production is an expense. We design from day one for the server that will serve real people.

Measured numbers, not marketing

If we claim an improvement, we show where it comes from. What cannot be demonstrated in the system is not promised in the proposal.

The data belongs to the client

Database, code and infrastructure stay in the name of whoever pays for them. Nothing is tied to an account of ours.

The decision that matters is signed by a person

The software orders logistics, computes risk and proposes. The decision with consequences is taken and signed by whoever carries the responsibility — never by the system.

What it is built with

Technology chosen by cost of maintenance

Nothing exotic for its own sake: every piece is there because it lowers the cost of keeping the system alive three more years, not because it trended this semester.

Application

  • Bun
  • Hono
  • TypeScript
  • Astro
  • React

Data

  • PostgreSQL 19 · 18
  • Row Level Security
  • pgvector
  • Verified backups

Intelligence

  • Cited RAG
  • Document OCR
  • Local models
  • CP-SAT / QUBO

Infrastructure

  • AWS us-east-1
  • nginx
  • Certbot / SSL
  • Per-app isolation

Questions

What people ask before starting

Do you do custom software or sell licences?

Both. EIR, Doctores, CertiCore and Licitaciones Inteligentes are our own platforms, implemented and adapted per client; we also build custom systems when the process does not fit any of them.

Where is the data hosted?

On AWS infrastructure in the client’s name when that is agreed, or on ours while the implementation runs. Either way, backups and access are documented and handed over.

How long until a useful first version?

It depends on the process, but the rule is something navigable in weeks, not quarters. The first delivery is always installed where it will be used.

Do you work outside Chile and Mexico?

Yes. We operate in both countries today and the work is remote by design; on-site visits are scheduled for the stages where they add value.

Contact

Got a process falling apart on you?

Tell us which operation you want to put in order. If we can help, we say so with a plan and a timeline; if it is not our thing, we say that too.

Send an email See the products

Write to us at contacto@betrivasystems.com · We reply within one business day.