Technology
How we build.
The doctrine below is not a marketing frame. It is the set of constraints every MeerTech system is engineered against, and the reason the systems keep working where the network, the power and the data do not.
The no-fabrication rule
Most software treats a missing input as an inconvenience to be papered over: a default value, an interpolation, a silently reused stale number. In the environments we build for, that behaviour is not a shortcut, it is a defect with consequences.
An operator pricing technical losses on an estimated conductor specification is pricing fiction. A statistician publishing an indicator over an interpolated gap is publishing a number that cannot be defended two years later.
The practical effect is that a MeerTech dashboard sometimes says less than a competitor's demo. Every number it does show is one the operator can act on and defend.
In MeerTech systems, absence is a first-class value.
Where a required input is missing, the system returns the absence together with its reason: which input is missing, why the computation cannot proceed without it, and what would resolve it.
The interface renders that state explicitly, and where data is stale it renders the age of the data alongside the value.
This is enforced at the database layer, not just in the interface: a computed figure without its required physical basis is a write the database refuses.
Offline first
Connectivity at a rural site is not a fault condition, it is the operating condition.
Our field applications are built on Expo React Native with SQLCipher, so capture continues on device, encrypted, regardless of signal. Sync is a design assumption, not a recovery path: when the device reconnects, records reconcile with idempotency keys so that a retry can never double-post, and field capture carries a hash-chain audit so the record that arrives is provably the record that was captured.
A device offline for eleven days is not an edge case.
It syncs the same way a device offline for eleven seconds does: the same reconciliation, the same audit chain, the same refusal to overwrite newer truth with older data silently.
Engineered for the grid as it actually is.
Audit and ledgers
Every state change leaves an append-only trail. Nothing is edited in place; corrections are new entries that reference what they correct. Financial workflows move through double-entry ledgers, so money is never a mutable balance field, it is a history that sums. Idempotency keys on all state-changing operations mean that unreliable networks can retry safely, which in practice is what makes offline-first financially safe rather than merely convenient.
Security posture
Access is denied unless explicitly granted, and the enforcement lives at the row: deny-by-default row-level security in the database, not permission checks scattered through application code. Tenants are isolated schema per tenant, and scopes are isolated within them.
A credential that leaks does not become a dataset that leaks.
The AI envelope
We use AI where it is specific and true: solar resource and yield forecasting, crop disease classification, inference over incomplete telemetry. Every model output runs inside a deterministic envelope with a defined failure mode.
A forecast is published with its error against a persistence baseline, a classification is published with its confidence, and neither is allowed to write directly into a system of record.
What the envelope forbids matters as much as what it permits: a model may not invent a missing input, may not trigger a financial movement, and may not bypass the operator override that sits on every automated step.
Stack, and what we deliberately rejected
A modular monolith with a disciplined schema does the work, and it can be operated by the people who will actually operate it.
- Platform
- Python and FastAPI modular monolith.
- Data
- PostgreSQL 17, with TimescaleDB for telemetry and PostGIS for spatial work. Schema per tenant.
- Field applications
- Expo React Native with SQLCipher.
- Web surfaces
- Next.js and React.
- Deployment
- Docker Compose on DigitalOcean.
Rejected on purpose
Just as deliberate is what we rejected. Kafka, microservices, CRDTs and graph databases were each evaluated and declined: every one of them adds operational surface that a small team running critical infrastructure in low-resource environments would pay for daily, and none of them was required by the actual problem.
System architecture, simplified.
Three layers: what runs in the field, what runs on the platform, and what the operator already owns.
MeerTech builds no hardware.
Integration posture
We integrate with the meter headends, ECUs, Modbus devices and vendor APIs the operator already owns, and with satellite and weather sources that require nothing at the site at all.
Certified functions stay with certified systems: prepayment token generation, for example, remains with the certified headend, and our systems orchestrate around it.
