PythonTypeScriptJavaScriptJavaCSQLPL/SQLSwift
Technology
The page your technical evaluator asked for.
What we build with, how we isolate data, what happens to a model after launch, and the security posture behind every system we ship. Written for the engineer on the buying side rather than the procurement summary.
live
Stack
Six layers, listed by what has shipped.
We are deliberately narrow. A team this size that claims twenty frameworks is claiming one thing badly, twenty times.
PyTorchTensorFlowTensorFlow Litescikit-learnMask R-CNNEfficientNetLSTM and attentionTransformersRAGOllamaOpenAI-compatible APIs
FastAPIFlaskSpring BootSQLAlchemyPydantic v2PostgreSQLOracleFirebaseRedisREST and GraphQL
React 18ViteNext.jsCanvas and WebGLDesign systemsWCAG 2.2
AzureAWSDockerGitHub ActionsMicrosoft GraphEntra IDVercelSupabase
iOSAndroidESP8266ArduinoOn-device inferenceMQTT
How isolation actually works
One diagram, because this is the question every evaluator asks.
Two customers, one platform, and a scoping rule enforced in the database rather than in application logic.
13core tables under row-level scoping
0cross-tenant reads possible by design
100%of access and change events logged
UKdefault data residency region
Security and data protection
Six practices that are not optional on any build.
These are engineering commitments, not a compliance page. Each one has a cost, and it is in the quote.
Tenant isolation
Every multi-tenant system we ship scopes data on an organisation identifier at the row level, so one customer's query cannot reach another customer's data even if application logic fails.
Why it matters
Every multi-tenant system we ship scopes data on an organisation identifier at the row level, so one customer's query cannot reach another customer's data even if application logic fails.
Role-based access control
Permissions are defined per role and enforced server-side.
Why it matters
Permissions are defined per role and enforced server-side. Client-side hiding is presentation, not security, and we do not treat it as such.
Audit logging
Who saw what, who changed what, and when.
Why it matters
Who saw what, who changed what, and when. Written on the way in, not reconstructed later from application logs.
Data protection by design
UK GDPR from the first schema: data minimisation, defined retention, lawful basis recorded, and subject access answerable without an engineer writing a one-off query.
Why it matters
UK GDPR from the first schema: data minimisation, defined retention, lawful basis recorded, and subject access answerable without an engineer writing a one-off query.
Contestability
Where a system informs a decision about a person, that person can see the basis for it and dispute it through a defined route.
Why it matters
Where a system informs a decision about a person, that person can see the basis for it and dispute it through a defined route. We build the route, not just the model.
Dependency and secret hygiene
Automated dependency scanning, secrets kept out of source control, and environment separation between development, staging and production.
Why it matters
Automated dependency scanning, secrets kept out of source control, and environment separation between development, staging and production.
After launch
A model is not finished when it ships.
Performance decays as the world moves away from the training data. Planning for that is part of the build, not an emergency later.
Drift monitoring
Scheduled re-evaluation against a held-out set, with alerting when performance moves beyond an agreed threshold.
Retraining cadence
Retraining planned and budgeted from the start, so it is a routine operation rather than a crisis project.
Incident procedure
A runbook naming who does what when the model is wrong in a way that affects someone, including how the decision gets reversed.
Send us your technical questions.
Architecture, data residency, model governance, integration constraints. An engineer will answer, not a sales team reading from a document.