Technical architecture
Open, portable and production-ready.
GeoTelligence systems are built on PostgreSQL, PostGIS and Next.js — open-source components that run anywhere. No proprietary lock-in. No browser-side database access. Deployable from Vercel to AWS to on-premise.
System architecture
Four-layer architecture
A clean separation of concerns: browser, application, database and storage. Each layer is independently replaceable.
Deployment options
Rapid delivery
Vercel + Neon
Enterprise cloud
AWS + RDS + S3
Container hosting
Docker + Postgres
On-premise
Self-hosted Postgres
Portable by design
Open components. No lock-in.
GeoTelligence systems are designed around open, portable components rather than proprietary platforms. A typical deployment uses a Next.js application layer, PostgreSQL/PostGIS spatial database, S3-compatible object storage and standard API integrations.
This can be deployed using Vercel and Neon for rapid delivery, or moved toward AWS, container hosting, RDS/PostGIS and S3 for enterprise environments — without rearchitecting the application.
The same codebase runs in both environments. Changing deployment target is a configuration change, not a rewrite.
Full-stack React framework, API routes, server-side rendering
Primary relational database for all asset, review and recommendation data
Spatial extension for location queries, geometry storage and GIS analysis
Open-source map rendering in the browser, vector tile support
Serverless Postgres (Neon) for rapid delivery; AWS RDS for enterprise
Object storage for documents, photographs and evidence files
Vercel for rapid delivery; AWS ECS/EKS or container hosting for enterprise
Container-ready deployment for enterprise and on-premise environments
Architecture principles
How the system is built
API-first design
All data access goes through a server-side API layer. No direct browser-to-database connections. Spatial queries, business logic and access control live server-side.
Cloud-portable architecture
No proprietary lock-in. PostgreSQL, PostGIS, S3 and Docker are open standards deployable across Neon, AWS, Azure, GCP or on-premise infrastructure.
No browser-side database access
Credentials and connection strings never reach the browser. API routes enforce access control, validate inputs and return only the data the authenticated user is permitted to see.
Spatial-first data model
Asset locations are stored as PostGIS geometry. Spatial queries — proximity, clustering, overlap, route — run in the database, not in the application layer.
S3-compatible evidence storage
Documents and photographs are stored in S3-compatible object storage, decoupled from the database. Presigned URLs are issued server-side. Files never pass through the application layer.
Documented for handover
All systems are delivered with schema documentation, API documentation and deployment notes sufficient for an in-house team or additional developers to continue the work.
Data model
The rail structures data model
An explicitly modelled hierarchy where every relationship is traceable. Risk decisions can always be traced back to the examination evidence and engineering review that produced them.
Asset
Physical structure — identity, location, type, route reference
Exam
Source examination evidence — date, examiner, method, raw findings
Review
Engineering judgement — reviewer, date, overall assessment
Risk / Severity
Review output — risk matrix score, severity, consequence, likelihood
Recommendation
Action item — description, category, priority, assignee, status
Evidence
Documents and photographs — linked to asset, exam or recommendation
Audit
Decision history — who changed what, when and why
Incidents
Events linked to asset — strikes, flood, damage reports, emergency inspections
Each entity has a clear role. An Asset is a physical structure with a location and identity. An Exam is source evidence from a field examination. A Review is an engineering assessment of that evidence. Risk and severity are outputs of the review, not inputs to it. Recommendations are actions arising from the review. Evidence is the documents and photographs that support all of the above. The Audit trail records every decision and change.
Get in touch
Discuss the technical approach
If you have existing data, a legacy system or a specific technical context — discuss how this architecture could be adapted to your environment.