How we build.

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.

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.

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.

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 that has been offline for eleven days is not an edge case in this architecture. 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.

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

The platform is a Python and FastAPI modular monolith on PostgreSQL 17 with TimescaleDB for telemetry and PostGIS for spatial work, schema per tenant. Field applications are Expo React Native with SQLCipher. Web surfaces are Next.js and React. Deployment is Docker Compose on DigitalOcean.

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. A modular monolith with a disciplined schema does the work, and it can be operated by the people who will actually operate it.

Integration posture

MeerTech builds no hardware. 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.