Technologies
We pick boring on purpose.
Novel technology carries a maintenance tax your team pays for years after we leave. We use the interesting option only where it clearly beats the boring one — and we write down why in a decision record you can read.
Reference architecture
v2.4 · reviewedIntelligence
model-agnosticOrchestration
durable executionApplication
typed end to endPlatform
reproducible from codeHow we choose
Four rules that decide what goes in the stack.
Applied to our own work as strictly as to yours. We have retired plenty of our own choices when something better cleared the bar.
We pick boring on purpose
Novel technology carries a maintenance tax your team pays for years. We use the interesting option only where it clearly beats the boring one, and we write down why.
Portable by default
No proprietary runtime, no framework you cannot leave. Every system is built so another engineering team could take it over from the documentation.
Evaluation before adoption
A new model or tool enters our stack after it beats the incumbent on a real workload, measured. Announcements are not evidence.
Instrumented from the first commit
Tracing, metrics and structured logs are part of the initial build. You cannot optimise or debug what you cannot see.
The stack
Twelve layers. Every one of them replaceable.
Your system is built so that swapping a model, a database or a cloud is a configuration change and a migration plan — not a rewrite.
Models & reasoning
Chosen per workload by evaluation, never by preference. Swapping one is configuration, not a rewrite.
- Claude
- GPT
- Gemini
- Llama
- Mistral
- Qwen
- Embedding models
- Self-hosted open weights
Agent & orchestration
Durable execution, planning loops and tool routing that survive a failure halfway through.
- LangGraph
- Temporal
- Model Context Protocol
- AWS Step Functions
- Airflow
- Custom runtimes
Languages
Typed where it matters. We pick the language that fits the problem and the people who will maintain it.
- TypeScript
- Python
- Go
- Rust
- C#
- Swift
- Kotlin
- SQL
Application frameworks
Server-rendered by default, accessible by default, fast on the hardware people actually own.
- Next.js
- React
- Astro
- NestJS
- FastAPI
- Django
- .NET
- Tailwind CSS
Mobile
Native where platform depth matters, shared core where the economics are better.
- Swift / SwiftUI
- Kotlin / Compose
- React Native
- Flutter
- Expo
- Kotlin Multiplatform
Data & storage
Schemas designed for the volume you will have, not the volume you have today.
- PostgreSQL
- pgvector
- ClickHouse
- Snowflake
- Databricks
- Kafka
- Redis
- Elasticsearch
- dbt
Cloud & platform
Everything in code. If an environment cannot be rebuilt from a repository, it is not finished.
- AWS
- Azure
- Google Cloud
- Kubernetes
- Terraform
- Pulumi
- Argo CD
- Cloudflare
- Vercel
Security
Least privilege, short-lived credentials, and controls tested by attacking our own work.
- Microsoft Sentinel
- CrowdStrike
- Wiz
- HashiCorp Vault
- Okta
- Entra ID
- Snyk
- Trivy
Observability
Alerts tied to user-facing symptoms rather than to every twitch of a CPU graph.
- OpenTelemetry
- Datadog
- Grafana
- Prometheus
- Sentry
- Loki
- PagerDuty
Enterprise systems
The systems of record we integrate with most often, API-first wherever one exists.
- SAP
- Oracle
- NetSuite
- Dynamics 365
- Salesforce
- ServiceNow
- Workday
- HubSpot
Quality engineering
Tests, budgets and audits that block a merge rather than produce a report nobody reads.
- Playwright
- Vitest
- pytest
- axe-core
- Lighthouse CI
- k6
- Chaos testing
Design & content
Design systems that live in code, and content models that survive a redesign.
- Figma
- Design tokens
- Sanity
- Contentful
- Storyblok
- Payload
- Storybook
Integrations
The systems of record we have already connected.
Connectors written once, tested, and reused — so your second integration is not a repeat of the first.
Technology questions
What CTOs ask about the stack
Still deciding?
Send the question to a senior engineer instead of a form. You will get a straight answer, and a no if that is the honest one.
Whichever wins the evaluation for your specific workload, and it is rarely the same model for every step. We route cheap classification to small fast models and reserve frontier models for genuine reasoning. More importantly, we build so that swapping a model is a configuration change — the leaderboard changes every few months and your architecture should not care.
Yes. We deploy into your cloud account or on-premises, with open-weight models served locally where data residency or regulation requires it. Expect a measurable trade-off on the hardest reasoning steps, and we will quantify it against your workload before you decide rather than after.
Where they genuinely fit, yes. But business logic locked inside a low-code canvas is hard to review, test and version, and per-task pricing gets punishing at volume. We will show you the maths on both maintainability and cost rather than defaulting to a preference.
We build within it. Your standard exists because your team can support it, and that matters more than our preferences. Where a standard would genuinely prevent the outcome you want, we will say so with the specific reason and let you decide.
A new model or tool enters our stack after it beats the incumbent on a real workload, measured on a benchmark we control. Announcements are not evidence. We also retire our own work when something better clears the bar — including work we were proud of.
Start the conversation
Bring your architecture and we will tell you what we would change.
Ninety minutes with our engineers looking at your actual stack. You get a written view on what is holding you back and what we would leave alone.
What to expect
- No pitch deck, no obligation
- Senior engineers in the room
- A written plan within five days
Prefer email?
support@cyberxsolutions.us