Technology
Technology Selected for Operational Fit.
INX applies technology against defined operational requirements. Framework and runtime selection follows the problem - not the calendar year, not the hiring market, not what was used in the previous engagement.
Selection Basis
Operational fit
Complexity Threshold
Justified by the problem
Ownership Model
Client-transferable at handover
push to main - 47 files changed
webpack 5 · node 20 · compiled in 42s
847 tests · 0 failures · 94% coverage
0 critical · 0 high · 2 low (acknowledged)
verification env · smoke tests passing
blue-green ready · awaiting gate
Technology Stack
Six Domains. Documented by Operational Role.
Each technology listed here is applied in production across INX engagements. Inclusion indicates operational use - not aspirational capability.
Frontend Engineering
Rendering framework and state management decisions are made against performance and maintainability requirements. No framework is introduced without a defined justification over the alternatives.
Next.js
Application framework providing SSR, SSG, and edge rendering. Selected for deployment flexibility and the absence of proprietary infrastructure lock-in.
React
Component model for complex UI state management. Applied where rendering complexity justifies the abstraction - not by default.
TypeScript
Enforced in strict mode across all frontend codebases. Type coverage at module boundaries eliminates a class of production runtime failures.
Tailwind CSS
Utility-first styling for component surfaces that scale. Eliminates stylesheet management overhead without sacrificing design precision.
Framer Motion
Scoped to interaction-layer transitions with explicit constraints against performance-impacting visual effects.
Backend Engineering
Service boundaries, runtime selection, and data model design are determined by the operational profile of each workload - not by convention or prior-engagement familiarity.
Node.js
Preferred runtime for I/O-bound, high-concurrency service layers. Not applied to CPU-intensive computation paths.
Python
Primary language for document processing, AI inference pipelines, and data transformation workloads.
PostgreSQL
Relational database selected for transactional integrity, row-level security enforcement, and predictable behaviour under production load.
Redis
Applied to session state, cache layers, and lightweight queue management. Not operated as a primary data store.
Cloud Infrastructure
Infrastructure decisions are made against workload requirements and compliance constraints, not vendor preference. Multi-cloud capability is maintained to avoid operational dependency on any single provider.
AWS
Primary provider for enterprise deployments requiring compliance-ready infrastructure, regional data isolation, and managed service depth.
Vercel
Selected for Next.js application hosting where edge delivery and deployment simplicity align with the workload profile.
Docker
Containerisation standard for all application services. Guarantees environment parity between development, staging, and production.
Terraform
Infrastructure as code for reproducible, auditable provisioning. All production infrastructure is version-controlled and peer-reviewed before deployment.
AI Systems
AI components are integrated as bounded, auditable services with defined input schemas, output validation, and confidence thresholds - not embedded as opaque logic within application code.
OpenAI API
Applied to structured extraction, document classification, and reasoning tasks with validated JSON output schemas enforced at the inference layer.
Structured Output
Schema-enforced model responses eliminate parsing ambiguity and enable downstream field validation against a defined registry.
LLM Orchestration
Multi-step reasoning pipelines designed with deterministic fallback paths and confidence-threshold routing to human review queues.
Audit Infrastructure
Every automated AI decision logged with model input, output, and confidence score. Required for regulatory compliance in auditability-constrained environments.
Mobile Engineering
Mobile applications are built to operate reliably under variable connectivity, with local state management that synchronises without user intervention or data loss on reconnection.
React Native
Cross-platform framework for enterprise mobile applications requiring native platform APIs and offline-tolerant state management.
Expo
Managed build tooling and deployment lifecycle management. Applied where delivery timeline and platform coverage requirements are aligned.
Offline-First State
Local persistence with conflict-resolution sync patterns. Applications remain fully operational under degraded or absent connectivity.
WebSocket
Real-time data synchronisation for operational applications where sub-5-second update latency is a defined acceptance criterion.
DevOps & Deployment
Delivery infrastructure is an engineering concern addressed at project initiation - not a post-launch addition. CI/CD, monitoring, and deployment discipline are operational before the first production deployment.
GitHub Actions
CI/CD automation for build verification, automated test execution, and deployment pipeline orchestration across environments.
Docker Compose
Local environment standardisation. Eliminates the class of defects caused by development-to-production environment configuration drift.
Structured Logging
Queryable log format with distributed request tracing across service boundaries. Debugging production incidents without structured logs is archaeology.
Monitoring & Alerting
Performance baselines and alert thresholds defined before go-live. Production visibility is a delivery requirement, not a retrofit applied after the first incident.
Engineering Standards
Five Standards Applied Across Every Codebase.
These are not aspirational principles. They are engineering constraints enforced at the architecture review, code review, and delivery acceptance stages of every INX engagement.
Scalability as a Design Constraint
Scalability requirements are defined during discovery and imposed as architectural constraints from the first design decision. Systems are not built for current load and scaled reactively - they are designed for anticipated growth with horizontal scaling paths that do not require architectural surgery to activate.
Maintainability as a Delivery Requirement
Code is written to be read by engineers who were not present during its creation. Abstraction layers are introduced where they reduce genuine complexity - not where they create the appearance of architectural sophistication. Documentation of non-obvious decisions is treated as a delivery output, not an afterthought.
Deployment Discipline
Every production deployment follows a defined promotion path: development, staging, production - with automated verification at each stage. Hotfixes that bypass staging are treated as an engineering failure. Rollback capability is a requirement established at architecture stage, not a contingency considered after an incident.
Performance Measurement
Performance targets are defined as acceptance criteria before engineering begins and measured against a defined load profile before delivery is accepted. P50, P95, and P99 latency are tracked in production. A performance regression is treated with the same severity as a functional defect - because it frequently is one.
Technical Ownership Transfer
The codebase is owned by the client at handover - not by INX. Architecture decisions are made to be legible to engineers who will maintain the system without reference to us. Proprietary complexity that creates dependency on INX's continued involvement is not a business model we operate.
Architecture Thinking
Technology decisions are engineering decisions. Not procurement decisions.
Choose the tool that satisfies the operational constraint.
INX does not select technologies because they are popular, because they were used in a previous engagement, or because they are well-regarded in the broader engineering community. Selection is made against a defined requirement: throughput, latency, isolation, auditability, or long-term maintainability. If that requirement cannot be stated clearly, the selection decision is premature.
Every additional dependency is a liability that must earn its place.
Each technology added to a system increases the surface area for failure, the cognitive overhead for new engineers, and the operational burden for the team that maintains the system in production. INX adds complexity when the alternative creates more problems than the complexity it introduces solves. The default position is subtraction, not addition.
Design for the engineer who inherits the system.
The best-written system is one that requires the least explanation. This is applied as an architecture constraint at design review: if a decision requires extended documentation to justify its existence, the architecture is a candidate for simplification. Clever systems have short lifespans. Legible systems outlast their authors.
Delivery Infrastructure
The Infrastructure Around the Code.
CI/CD, version control discipline, deployment strategy, testing philosophy, and production observability - defined before engineering begins on every engagement.
01
CI/CD Pipelines
Every INX-delivered codebase ships with a configured CI/CD pipeline as a standard delivery output. Build verification, automated test execution, and deployment orchestration are operational from the first production deployment - not added once the system is in production.
02
Version Control Standards
Branch protection rules, required peer review, and semantic commit conventions are configured during project setup. Production is always a tagged, reviewed, and verified state - not the result of a direct commit or an unreviewed merge.
03
Deployment Workflows
Promotion from development to staging to production follows a documented workflow with automated verification at each stage. Blue-green or canary deployment strategies are applied where zero-downtime deployment is a stated requirement.
04
QA Philosophy
Testing is applied proportionate to the risk profile of each component. Unit tests for deterministic functions. Integration tests at service and database boundaries. End-to-end tests for critical user journeys. Test coverage is not a metric optimised in isolation - test confidence is.
05
Monitoring & Observability
Structured logging, latency percentile tracking, and error alerting are production requirements, not optional additions. Systems are delivered with dashboards configured and alert thresholds defined. Incident visibility is established before the first production traffic, not after the first production incident.
Technology Philosophy
An engineering organisation's technology choices reveal its values.
On Technology Selection
We are not technology-agnostic.
INX has considered opinions on technology, and we apply them. Where a client has established infrastructure that is operationally sound, we work within it. Where it is not, we document our assessment in writing before proposing any change. An engineering organisation without technical positions is a labour supplier, not a partner.
On Client Dependency
We do not build systems that require INX to operate.
Every decision made during an engagement is evaluated against a single question: can the client's own engineering team - or any competent successor team - maintain this system without reference to INX? If the answer is no, a delivery requirement has not been met. Technical dependency is not a revenue model we accept.
On Operational Outcomes
Technology is a means. Outcomes are the measure.
The engineering community tends to evaluate technology choices as ends in themselves - as signals of technical sophistication or organisational modernity. INX evaluates them against the operational results they produce in production: latency reduced, throughput increased, onboarding time halved, audit findings eliminated. A system that works is preferable to a system that is architecturally interesting.
Technical Partnership
If the Technical Problem Is Defined, the Conversation Can Begin.
INX engages with organisations that have a clear technical problem and require an engineering partner that applies technology with operational discipline. The first step is a structured discovery conversation - not a proposal, not a demonstration, not a sales process.
Discovery is a separate billable engagement that produces a written technical specification. Development does not begin without one.
Technology selected for operational fit
Architecture documented before development
Performance baselines defined as acceptance criteria
Full ownership transferred at handover