# Axio Intelligence > Axio Intelligence is a veteran-founded US engineering firm in San Antonio, Texas. Established companies bring us in to build what they are launching next: go-to-market platforms for new product lines and divisions, data and AI platforms, cloud infrastructure as code on AWS, Google Cloud and Azure, and connected hardware — firmware, cellular and satellite connectivity, device-to-cloud platforms and edge AI. We also cut cloud costs, modernize legacy systems, run DevOps/SRE, and provide fractional CTO leadership. Website: https://axiointelligence.com/ · Contact: contact@axiointelligence.com · Book a scoping call: https://axiointelligence.com/book Headquarters: San Antonio, TX, United States. Founder: Brice Ayres, U.S. Army veteran. While serving in the U.S. Army, Brice built a telecom company that gave away more than one million minutes of talk time to troops deployed in Iraq and Afghanistan. Short map of the site: https://axiointelligence.com/llms.txt ## Company FAQs **What does Axio Intelligence do?** Axio Intelligence is a US engineering firm in San Antonio, Texas. We build go-to-market platforms for new product lines, data and AI platforms, and cloud infrastructure as code on AWS, Google Cloud and Azure; we build connected hardware end to end — firmware, cellular and satellite connectivity, device-to-cloud and edge AI; and we cut cloud costs, modernize legacy systems — including moving COBOL and RPG workloads off IBM mainframes and IBM i, and Oracle and SQL Server databases to PostgreSQL or MySQL — run DevOps/SRE and provide fractional CTO leadership. **Can Axio build the platform for a new product line or division?** Yes — it is one of the most common reasons established companies hire us. We build the product site, customer and dealer portals, commerce and billing, CRM and ERP integrations, and the cloud infrastructure for a new line, so it can launch without pulling the core engineering team off the roadmap. **Which clouds do you work with?** AWS, Google Cloud (GCP) and Microsoft Azure. We build and support infrastructure as code with Terraform, OpenTofu, Pulumi, AWS CDK or Bicep, including landing zones, Kubernetes (EKS, GKE, AKS), CI/CD and ongoing IaC support. **Do you work with IBM mainframes or IBM i (AS/400)?** Yes. For US manufacturers, distributors, wholesalers and mid-size retailers still running on IBM Z (z/OS and COBOL) or IBM i (AS/400 and RPG), we move COBOL and RPG workloads to AWS, Azure or Google Cloud in a modern language, starting with the batch and extract jobs that cost the most — inventory, replenishment, pricing feeds, reports. It starts with a diagnostic of the bill and the job list, and there is no upfront fee: we are paid a percentage of the net savings in licensing and compute spend. **Who hires Axio Intelligence?** Mostly established companies launching something new — a product line, a division, an AI or data capability, or a connected product — plus IoT connectivity providers who need an implementation partner, energy and DER device makers, defense and dual-use hardware teams, and industrial operators. We also built the AI data platform behind MLtwist. **Can you build firmware and cloud software for our IoT device?** Yes. We build the embedded firmware, the connectivity path, the device-to-cloud pipeline, command-and-control APIs, secure OTA updates and the fleet console, and we can design and manufacture the hardware too. One team is accountable from the board to the dashboard. **How do engagements work and how are they priced?** Most work starts with a short scoping sprint, followed by a fixed-scope, fixed-fee build with a written plan and dates. After launch, systems can move to a monthly support retainer. Fractional CTO work is a monthly retainer for a set number of days. Mainframe and IBM i migration is the exception: no upfront fee, priced as a percentage of the net savings we deliver. Database migrations can be either a fixed fee or a share of the license savings, depending on the job. **Do you work with our existing connectivity provider?** Yes. We build on the provider you already use, which is why connectivity providers refer their customers to us as an implementation partner. **Where is Axio Intelligence located?** Axio Intelligence is headquartered in San Antonio, Texas, and works with clients across the United States. Our engineering team is US-based. # Services ## New product line platforms URL: https://axiointelligence.com/services/product-platforms Axio Intelligence builds the complete software platform behind a new product line or division — product site, customer and dealer portals, quoting, ordering and subscription billing, CRM and ERP integrations, analytics, and the cloud infrastructure underneath — so an established company can launch a new business without pulling its core engineering team off the roadmap or hiring a department first. ### Signs you need this - A new division has a launch date and no engineering team of its own yet. - Your core engineers can’t be pulled off the main product to build it. - The new line needs its own portal, pricing, billing and support workflows — wired into the systems you already run. - Leadership wants a real product in market this year, not after a year of hiring. ### What we deliver - Product site & launch: Positioning-ready marketing site, product pages, lead capture and analytics, built to rank and to convert. - Customer, partner & dealer portals: Accounts, roles and SSO; ordering, service requests, documentation and device or subscription management. - Commerce & billing: Quoting, checkout, subscriptions and usage-based billing, with tax, invoicing and revenue reporting. - Systems integration: CRM, ERP, support desk and data warehouse integrations so the new line runs on your existing back office. - Cloud foundation: Isolated environments as code on AWS, Google Cloud or Azure, with CI/CD, monitoring and security baselines. - Handoff or run: Documentation, runbooks and hiring support for the team that takes it over — or ongoing support from us. Stack: Next.js, Elixir / Phoenix, Kafka, React, React Native, Node.js, Go, Postgres, ClickHouse, Keycloak (SSO / SAML / OIDC), OpenTelemetry, CRM / ERP / billing integrations, AWS · GCP · Azure Engagement: Discovery sprint, then a phased build to launch Timeline: First release typically 8–16 weeks ### FAQs **Can Axio build the platform for a new product line or division?** Yes. Established companies bring us in to build everything a new line needs to go to market — product site, portals, commerce and billing, integrations with the CRM and ERP you already run, and the cloud infrastructure — as a fixed-scope, phased build. **What happens after launch?** Either we hand off to the team you hire, with documentation, runbooks and help interviewing, or we keep running the platform on a monthly support retainer. You own the code either way. **Will this pull time from our existing engineering team?** Minimal. We need access, a few decisions from product owners and integration points into your systems. The build itself runs on our team. ## Data & AI platforms URL: https://axiointelligence.com/services/data-ai-platforms Axio Intelligence builds data and AI platforms — ingestion and transformation pipelines, human-in-the-loop labeling workflows, workforce and project management, automated quality control, and Kubernetes-orchestrated containerized workloads — that turn raw multimodal data (video, audio, images, text and 3D) into model-ready datasets. We engineered the platform MLtwist uses to deliver AI data work, including its U.S. TSA contract. ### Signs you need this - Data preparation, not modeling, is what’s slowing your AI program down. - Labeling runs on spreadsheets, email threads and one-off scripts. - Every new customer or dataset needs a custom pipeline built from scratch. - A government or enterprise buyer wants proof of data lineage, quality and security. ### What we deliver - Pipeline orchestration: Custom pipelines triggered per project, running as containerized jobs on Kubernetes that scale with the workload. - Labeling workflows: Task setup, assignment, review loops and connectors to third-party annotation tools. - Project & workforce management: Customers, projects, labelers and reviewers managed in one system, with throughput and quality visibility. - Automated quality control: Validation rules and QC on human-in-the-loop revisions before anything ships. - Versioning & lineage: Tracked, versioned data in a secure environment, with an audit trail from raw input to delivered dataset. - Delivery in any format: Transformation and packaging to the customer’s schema — JSON, standard formats such as DICOS, or custom. Stack: ClickHouse, Kafka / Redpanda, Apache Flink, Elasticsearch / OpenSearch, Apache Iceberg, Parquet, DuckDB, PostGIS / H3, Kubernetes, Python, Postgres, Object storage (S3 / GCS), Human-in-the-loop labeling, Multimodal data, DICOS Engagement: Pipeline sprint or full platform build Timeline: Pipeline sprint: 2–4 weeks · Platform: 3–6 months ### FAQs **Can Axio build a data labeling or AI data platform?** Yes. We built the platform MLtwist runs on: project and workforce management, labeling projects, automated QC, and custom pipelines triggered on Kubernetes as containerized workloads. It is the foundation MLtwist delivered its $590K U.S. TSA multimodal labeling contract on. **Did Axio work directly for the TSA?** No. MLtwist holds the TSA contract. Axio engineered the MLtwist platform that the work is delivered on. **What data types can these pipelines handle?** Video, audio, images, text and 3D data, including security-imaging formats such as DICOS — preprocessed, labeled, quality-checked and packaged in the format the model team needs. ## Performance & legacy modernization URL: https://axiointelligence.com/services/legacy-modernization Axio Intelligence makes slow or aging systems fast and maintainable again — profiling and fixing performance bottlenecks, tuning databases and APIs, migrating platforms, and rewriting legacy components incrementally behind stable interfaces so the business never has to stop shipping. ### Signs you need this - Pages, APIs or reports got slow as data grew, and nobody owns performance. - A legacy system blocks new features and only one person understands it. - You need to migrate clouds or off a platform without a customer-facing outage. ### What we deliver - Performance profiling: Measure first: tracing, query analysis and load tests against realistic data. - Targeted fixes: Indexing, caching, query rewrites, async processing and right-sized infrastructure. - Incremental rewrites: Strangler-pattern replacement, one bounded component at a time, with parity tests. - Migrations: Cloud-to-cloud and platform exits run as small, reversible steps. Stack: Rust, Go, Elixir / Phoenix, Postgres, Ruby on Rails, Node.js, Python, Kafka, ClickHouse, OpenTelemetry Engagement: Performance audit, then fixed-scope phases Timeline: Audit: 1–2 weeks · Phases: 4–12 weeks each ### FAQs **Do we have to freeze features during a rewrite?** No. We replace components incrementally behind stable interfaces, with parity tests, so product work continues while the old system is retired piece by piece. **Do you modernize COBOL or RPG on IBM mainframes and IBM i?** Yes, one job at a time. We move COBOL and RPG workloads off z/OS and IBM i to AWS, Azure or Google Cloud in a modern language, starting with the batch and extract jobs that cost the most, and dual-run them until the outputs match. See mainframe & IBM i migration. **Do you migrate Oracle or SQL Server to PostgreSQL?** Yes. We convert schemas and stored procedures, keep data in sync with change data capture, and cut over with a rollback path. See database migration. ## Database migration URL: https://axiointelligence.com/services/database-migration Axio Intelligence migrates legacy Oracle and Microsoft SQL Server databases to PostgreSQL or MySQL — self-managed, or on Amazon RDS and Aurora, Google Cloud SQL and AlloyDB, or Azure Database. We convert schemas, PL/SQL and T-SQL stored procedures and application queries, keep old and new in sync during the move, and cut over with a rollback path, so you stop paying per-core license fees without a risky big-bang weekend. ### Signs you need this - Oracle or SQL Server licensing is one of the biggest lines in the IT budget, and a renewal or audit is coming. - Business logic lives in thousands of lines of PL/SQL or T-SQL that nobody wants to touch. - You’re moving to the cloud and don’t want to carry the old license with you. - Your team already runs Postgres or MySQL elsewhere and wants one database to support. ### What we deliver - Assessment: Schema, code and query inventory: what converts cleanly, what needs rewriting, and license and hosting cost before and after. - Schema & code conversion: Tables, types, indexes, stored procedures, triggers and packages converted to PostgreSQL or MySQL, with tests for every converted routine. - Data migration & sync: Bulk load plus change data capture, so old and new stay in sync until cutover. - Cutover & rollback: Application changes, tuning against production-sized data, and a tested rollback plan. Stack: PostgreSQL, MySQL, Oracle (PL/SQL), SQL Server (T-SQL), Amazon RDS / Aurora, Cloud SQL / AlloyDB, Azure Database for PostgreSQL / MySQL, AWS DMS & Schema Conversion, Debezium (CDC), ora2pg, pgloader, Terraform / OpenTofu Engagement: Assessment, then a phased migration per database Timeline: Sized after the assessment Pricing: Fixed fee or a percentage of the license savings, depending on the job ### FAQs **Can you migrate Oracle to PostgreSQL?** Yes. We convert the schema and the PL/SQL packages, procedures and triggers to PostgreSQL, move the data with a bulk load and change data capture, and cut over once the application has run against Postgres with production-sized data. **Can you migrate SQL Server to PostgreSQL or MySQL?** Yes. T-SQL procedures, functions and triggers are converted and tested routine by routine, application queries are updated, and data stays in sync until cutover. **Do we need downtime to switch databases?** Usually only a short cutover window. Change data capture keeps the new database current while the application is tested against it, and the old database stays available as a rollback until you are confident. **PostgreSQL or MySQL — which should we choose?** PostgreSQL is usually the closer fit for Oracle and SQL Server workloads with heavy procedural code, rich types and complex queries. MySQL makes sense when your team already runs it or the workload is simpler. The assessment recommends one based on your code. **How is database migration priced?** Either a fixed fee or a percentage of the license savings, depending on the job. When the goal is getting off Oracle or SQL Server licensing, a share of the savings usually fits; when the migration is part of a wider build, a fixed fee usually does. We recommend one after the assessment. **Can you migrate Db2 too?** Yes. Db2 for z/OS and Db2 for i data moves to PostgreSQL as part of our mainframe and IBM i work, alongside the jobs that read it. ## Fractional CTO & engineering URL: https://axiointelligence.com/services/fractional-cto Axio Intelligence provides fractional CTO and fractional engineering leadership for hardware, IoT and defense-technology companies — owning architecture decisions, the technical roadmap, hiring, vendor and connectivity selection, and investor or customer technical diligence — part-time, until a full-time leader is justified. We work as a remote fractional CTO for teams anywhere in the US from San Antonio, and come on site for the moments that need it. ### Signs you need this - You’re a hardware or domain founder without a senior software leader. - An SBIR or pilot is turning into a program and the engineering has to grow up fast. - You need someone to evaluate vendors, contractors or candidates you can’t judge yourself. ### What we deliver - Architecture ownership: Decisions written down, reviewed and defensible to customers and investors. - Roadmap & delivery: A plan the team can execute, with cadence, metrics and risk tracking. - Hiring & vendors: Role design, interviews, contractor and connectivity vendor selection. - Diligence support: Technical answers for investors, primes, utilities and security reviews. Stack: Architecture decision records, Roadmapping, Hiring loops, Vendor evaluation, Security questionnaires Engagement: Monthly retainer, a set number of days per month Timeline: Typically 3–12 months ### FAQs **What does a fractional CTO do for a hardware startup?** Owns the technical decisions a full-time CTO would — architecture, connectivity and cloud choices, security, hiring and vendor selection — for a set number of days per month, and can bring an engineering team to execute the plan. **Can a fractional CTO work remotely?** Yes, and most of our engagements are remote. We join your standups, design reviews and hiring loops over video, keep decisions in writing, and travel on site for kickoffs, customer or investor meetings and field testing when being in the room matters. **How is this different from hiring an agency?** An agency delivers a project. A fractional CTO is accountable for your technical direction across projects and vendors, including the ones we don’t build. ## IoT product engineering URL: https://axiointelligence.com/services/iot-product-development Axio Intelligence builds the software layer that turns a connected device into a product you can sell: embedded firmware, device-to-cloud ingestion, command-and-control APIs, secure over-the-air updates, and the fleet console your operations team and customers use every day. We take a device from working prototype to a managed fleet in the field. ### Signs you need this - The hardware works on the bench, but there’s no reliable way to reach, update or command units in the field. - Your connectivity vendor shipped SIMs and modules, and the project stalled on firmware and cloud. - Customers or a utility want an API, a dashboard and uptime numbers before they buy. - You need OTA updates you can trust before the next thousand units ship. ### What we deliver - Embedded firmware: Device application, power budgeting, watchdogs, store-and-forward, and command handling on Zephyr, FreeRTOS or embedded Linux. - Device-to-cloud pipeline: Ingestion over MQTT, LwM2M, CoAP or HTTPS into a time-series store, with device identity and TLS end to end. - Command & control API: Acknowledged commands, desired-vs-reported state, scheduling and audit trail, so every command is traceable. - Secure OTA: Signed, staged, resumable firmware updates with rollback and fleet cohorts. - Fleet console: Operator and customer dashboards: health, alerts, configuration, maps and exports. - Integrations: ERP, CRM, utility and C2 systems via REST, webhooks and message queues. Stack: Rust, C / C++, Zephyr RTOS, FreeRTOS, Embedded Linux / Yocto, Buildroot, nRF91, Quectel, MQTT / Sparkplug B, LwM2M, CoAP, OPC UA, NATS JetStream, AWS IoT Core, Blues Notecard, Particle, Memfault, Mender / SWUpdate / RAUC, TUF / Uptane, TimescaleDB, ClickHouse Engagement: Scoping sprint, then a fixed-scope build to a fielded pilot Timeline: Typical pilot-to-production build: 8–16 weeks ### FAQs **Can you pick up an IoT project that has stalled?** Yes — that is the most common way we start. We audit what exists (hardware, firmware, cloud, connectivity contract), keep what works, and ship the missing layer, usually firmware command handling, the cloud pipeline and a fleet console. You keep the code and the IP. **Do you work with our existing connectivity provider?** Yes. We build on the connectivity you already have — cellular, satellite or private LTE — and hand connectivity decisions back to you and your provider. **Which cloud do you build on?** Usually AWS, and also GCP, Azure or your own infrastructure. We default to boring, well-supported managed services so your team can run the system after hand-off. **How do you handle over-the-air updates safely?** Signed images, staged rollouts by cohort, resumable downloads over constrained links, health checks after update, and automatic rollback. We design OTA before the first fleet ships, not after. ## Cellular & satellite connectivity URL: https://axiointelligence.com/services/cellular-satellite-connectivity Axio Intelligence designs and integrates the connectivity path for devices in the field — LTE-M, NB-IoT and Cat-1bis cellular, eSIM, satellite (NTN and L-band), and private LTE — including failover between links, power and data budgets, and carrier certification support. We build on the provider you already use. ### Signs you need this - Devices depend on customer Wi-Fi and drop off when a router changes. - Assets operate beyond cellular coverage and need a satellite fallback. - Data costs or battery life are higher than the business model allows. - You need a PACE-style primary/alternate path for DDIL environments. ### What we deliver - Link selection: Radio, module, SIM/eSIM and plan trade study against coverage, power, data volume and unit cost. - Cellular integration: Modem bring-up, PSM/eDRX power tuning, network registration logic and reconnection strategy. - Satellite paths: NTN NB-IoT, Iridium SBD/Certus or Globalstar messaging for off-grid and backup links. - Failover logic: Link health scoring, automatic fallback, message prioritisation and store-and-forward. - eSIM & provisioning: SGP.32 remote SIM provisioning, profile management and factory provisioning flows. - Certification support: Preparing devices and documentation for carrier and module certification. Stack: LTE-M, NB-IoT, Cat-1bis, eSIM SGP.32, 3GPP NTN, Skylo, Iridium SBD / Certus, Globalstar, Private LTE / CBRS, 900 MHz LTE, PSM / eDRX Engagement: Connectivity assessment, then integration inside a product build Timeline: Assessment: 1–2 weeks · Integration: 4–10 weeks ### FAQs **LTE-M or NB-IoT — which should our device use?** LTE-M suits devices that move, need lower latency or send more data, and it supports voice-grade handover. NB-IoT suits stationary, deep-indoor, very low-data devices. Many products ship modules that support both and choose per region; we test against real coverage before committing. **Can we add satellite as a backup to cellular?** Yes. We design a failover path — typically 3GPP NTN or Iridium — with message prioritisation, so critical commands and alarms still get through when cellular is unavailable, without paying satellite rates for routine telemetry. **Do we have to switch connectivity providers?** No. We work with the provider you choose and build on the network you already use, which is why connectivity providers refer their customers to us. ## Edge AI & computer vision URL: https://axiointelligence.com/services/edge-ai-computer-vision Axio Intelligence deploys machine learning where the data is created: computer vision detection and tracking on edge hardware such as NVIDIA Jetson, anomaly detection on sensor and fleet telemetry, and the data pipelines, labeling workflows and model monitoring needed to keep models accurate in the field. ### Signs you need this - Streaming raw video or telemetry to the cloud is too slow, too expensive or not possible. - You have months of sensor data and no early warning when equipment starts to fail. - A model works in a notebook but not on the device, at the power budget you have. - Field data isn’t making it back into training in a usable form. ### What we deliver - On-device inference: Model optimisation and deployment on Jetson, ARM and x86 edge compute with TensorRT or ONNX Runtime. - Computer vision: Detection, classification and tracking pipelines for cameras and EO/IR sensors. - Anomaly detection: Baselines and alerting on telemetry to catch drift, faults and tampering early. - Data & labeling pipelines: Getting field data into models: capture, quality checks, labeling workflows and dataset versioning. - Model operations: Versioned model delivery over OTA, shadow deployment and on-device performance monitoring. - Field validation: Accuracy, latency and power measured on the target hardware in real conditions, with a written report before rollout. Stack: NVIDIA Jetson, DeepStream, TensorRT, Holoscan, OpenVINO, ONNX Runtime, GStreamer, MISB KLV / STANAG 4609, ROS 2, DDS (RTI Connext / Cyclone), OpenCV, PyTorch, C++, Rust, Python Engagement: Feasibility spike on your data, then a production build Timeline: Feasibility: 2–4 weeks · Production: 6–12 weeks ### FAQs **Can you run computer vision on a drone or a pole-mounted camera?** Yes. We size the model to the compute and power available — typically NVIDIA Jetson-class hardware — and send detections and events upstream instead of raw video. **What does anomaly detection need to get started?** A few weeks of representative telemetry and a list of the failures you care about. We start with simple statistical baselines that are explainable to operators, then add learned models where they earn their keep. ## Hardware design & manufacturing URL: https://axiointelligence.com/services/hardware-manufacturing Axio Intelligence designs and manufactures connected hardware alongside the software that runs on it — electronics, enclosures, design for manufacturing, factory test and provisioning, and production builds — so one team is accountable from the circuit board to the cloud console. ### Signs you need this - You have a proven prototype and need a build that survives weather, vibration and installers. - Your hardware and software vendors blame each other when units fail in the field. - Factory provisioning — certificates, SIM profiles, serial numbers — is manual and error-prone. ### What we deliver - Electronics & enclosure: Schematic, PCB layout, antenna placement and ruggedised enclosures for the operating environment. - Design for manufacturing: BOM optimisation, second-source components and documented country of origin when your program requires it. - Factory test & provisioning: Test fixtures, burn-in, and automated provisioning of device identity, certificates and SIM profiles. - Production builds: Pilot runs through production quantities with traceability from serial number to firmware version. Stack: PCB design, RF & antenna integration, IP-rated enclosures, DFM / DFT, Factory provisioning, Device PKI Engagement: Design review, then prototype and pilot-run builds Timeline: Varies by design maturity — scoped after review ### FAQs **Can you build hardware and write the firmware and cloud software?** Yes. That is the point: one accountable team from the board to the console, so provisioning, OTA and field diagnostics are designed into the hardware from the start. **Can you work from our existing design?** Yes. Most engagements start from an existing prototype or production design; we review it for manufacturability, connectivity and field reliability before building. ## Cloud infrastructure & IaC URL: https://axiointelligence.com/services/cloud-infrastructure-iac Axio Intelligence designs, builds and supports cloud infrastructure on AWS, Google Cloud (GCP) and Azure, written as code in Terraform, OpenTofu, Pulumi or native tooling — landing zones and account structure, networking, identity and security baselines, Kubernetes platforms (EKS, GKE, AKS), CI/CD and GitOps — and provides ongoing Infrastructure as Code support for teams whose infrastructure has drifted from its code. ### Signs you need this - Infrastructure was clicked together in the console and nobody can reproduce it. - Terraform exists, but plans are scary and the state has drifted. - A new product line needs its own isolated environments — quickly and safely. - You run on more than one cloud, or a customer requires one you don’t use yet. ### What we deliver - Landing zones & accounts: AWS Organizations / Control Tower, GCP organizations and folders, Azure management groups — with guardrails. - Terraform / OpenTofu: Reusable modules, remote state, environments and a review workflow your team trusts. - Network, identity & security: VPC/VNet design, private connectivity, IAM and SSO, secrets, logging and baseline policies. - Kubernetes platforms: EKS, GKE or AKS clusters with ingress, autoscaling, observability and upgrade paths. - CI/CD & GitOps: Plan/apply pipelines, policy checks, drift detection and Argo CD or Flux for workloads. - Google Cloud as code: GCP projects, folders, VPCs, IAM and GKE in Terraform or OpenTofu with the Google provider, run from your CI or from Google Cloud Infrastructure Manager, which runs Terraform as a managed service. - IaC support: Monthly support for reviews, provider upgrades, drift cleanup and new environments. Stack: AWS · GCP · Azure, Terraform, Kubernetes, OpenTofu, Pulumi, AWS CDK, CloudFormation, Bicep, EKS · GKE · AKS, K3s · RKE2, Zarf (air-gapped), Helm, Argo CD, HashiCorp Vault, GitHub Actions, AWS GovCloud Engagement: Foundation build, then optional monthly IaC support Timeline: Foundation: 3–6 weeks · Support: month to month ### FAQs **Which clouds does Axio support?** AWS, Google Cloud (GCP) and Microsoft Azure, including multi-cloud setups. We write the infrastructure as code — usually Terraform or OpenTofu, or Pulumi, AWS CDK or Bicep where a team already uses them. **How do you do infrastructure as code on Google Cloud?** Usually Terraform or OpenTofu with the Google provider: an organization and folder structure, shared VPCs, IAM bound to groups, and GKE, all in reviewed modules with remote state in Cloud Storage. Plans and applies run from GitHub Actions or Cloud Build, or from Google Cloud Infrastructure Manager if you want Google to run Terraform for you. Our guide to infrastructure as code that survives the team covers how we keep it maintainable. **Can you take over an existing Terraform codebase?** Yes. We start by reconciling state with what is actually deployed, then refactor into modules, add a plan/apply pipeline and document it — without a big-bang rewrite. **Do you offer ongoing Infrastructure as Code support?** Yes. A monthly IaC support retainer covers change reviews, provider and Kubernetes upgrades, drift cleanup, new environments and on-call escalation. ## Cloud cost reduction URL: https://axiointelligence.com/services/cloud-cost-reduction Axio Intelligence reduces cloud spend on AWS, GCP and Azure. A read-only diagnostic inventories every resource, maps spend to workloads and quantifies what is recoverable; a senior engineer validates the findings and presents a prioritised, fixed-fee plan. Published optimisation benchmarks commonly put recoverable spend at 20–50% for teams that have never done this work. ### Signs you need this - The bill grew faster than revenue and nobody can say exactly why. - IoT telemetry and video storage costs are climbing with every device you ship. - Finance is asking engineering questions engineering can’t answer quickly. ### What we deliver - Read-only diagnostic: Audit-scoped access, full resource inventory, dependency map and spend attribution. - Findings deck: Quantified opportunities ranked by dollars saved per week of work — yours to keep. - Fixed-fee execution: Rightsizing, commitment strategy, storage tiering, data-transfer fixes and architecture changes. - Guardrails: Budgets, tagging policy and alerts so spend doesn’t drift back. Stack: AWS, GCP, Azure, Kubernetes, Terraform / OpenTofu, Savings Plans, S3 / object storage tiering Engagement: Diagnostic, then optional fixed-fee execution Timeline: Diagnostic: ~10 days · Execution: 4–8 weeks ### FAQs **Is the diagnostic safe to run against production?** Yes. It uses read-only, audit-scoped credentials you can revoke at any time. Nothing is changed until you approve a plan. **How much can we expect to save?** It depends on the workload. Published benchmarks from the cloud providers and the FinOps Foundation commonly show 20–50% recoverable for teams that haven’t optimised before; the diagnostic gives you your actual number. ## Get the jobs that trap you off the IBM box. URL: https://axiointelligence.com/services/mainframe-migration Axio Intelligence helps US manufacturers, distributors, wholesalers and mid-size retailers cut IBM, Broadcom and BMC mainframe licensing and compute cost by moving COBOL workloads to AWS, Azure or Google Cloud in a modern language — starting with the peak batch and extract jobs that cost the most: inventory, replenishment, pricing feeds and nightly reports. This is mainframe offload done in waves: offloading workloads off the mainframe one job at a time, rather than a big-bang rewrite. Go as far as a full migration, or stop when the savings stop. There is no upfront fee: we are paid a share of the net savings. ### Signs you need this - Mainframe licensing and compute cost keeps climbing, and nobody can say which workloads drive it. - Inventory, replenishment and pricing jobs run at the busiest time of the month, and nobody wants to touch them. - On IBM i, the one person who understands the RPG that runs the business is close to retiring. - Leadership wants off the box, but not through a multi-year, all-at-once rewrite. ### What we deliver - Ranked job inventory: Every scheduled batch and extract job, with its inputs, outputs and owner, and what it costs you or risks for the business. - Migration plan & savings baseline: Which jobs move, in what order, and today’s licensing and compute spend — the baseline the savings are measured against. - Workloads rebuilt in the cloud: On AWS, Azure or Google Cloud in a modern language, with Postgres or your existing database — scheduled, monitored and documented. - Parity evidence: Dual-run reports showing old and new outputs match before anything on the IBM side is switched off. ### How it works 1. Read the bill and the job list: Contracts, invoices and usage reports, plus the job scheduler and programs. You send exports — we don’t need write access to anything. 2. Pick one job: One file-in, file-out job or extract that is expensive or risky. Start small, prove it, then widen. 3. Dual-run until outputs match: The new job runs in the cloud next to the old one, every cycle, and the outputs are compared until they match. 4. Turn the old job off: Only after the outputs match and the people downstream sign off. Then the next job, wave by wave. Stack: COBOL, z/OS · JCL, IBM i · RPG IV / ILE, CL, Db2 for z/OS · Db2 for i, VSAM, Control-M · CA-7 · IBM Z Workload Scheduler, SCRT · SMF, Postgres, Change data capture, AWS · Azure · GCP, Terraform / OpenTofu Engagement: Diagnostic, then migration in waves, one job at a time Timeline: Sized to your job list after the diagnostic Pricing: No upfront fee — a percentage of the net savings Not a fit: Bank deposit and money-movement cores, card authorization, insurance claims adjudication and government benefit systems. ### FAQs **How is mainframe migration priced?** There is no upfront fee. We are paid a percentage of the net savings: the drop in your annual IBM and third-party licensing and mainframe compute spend once workloads move, after the cost of running them in the cloud, measured against a baseline we agree with you before work starts. **Our contract isn’t based on the rolling 4-hour peak. Does this still apply?** Yes. Mainframe software is licensed many ways — rolling 4-hour peak, full capacity, consumption-based or enterprise agreements — and the details vary by vendor and contract. Whatever the model, the bill follows the work on the mainframe. Moving that work to the cloud is what lets you license and run less of it. **What is a rolling 4-hour peak?** It is a common way IBM and other vendors price z/OS software: the bill is based on the highest four-hour average of CPU use in the month, as reported by IBM’s Sub-Capacity Reporting Tool (SCRT). One busy window can set the bill for the whole month. It is one pricing model among several. **Is IBM i the same as a mainframe?** No. IBM i (formerly AS/400 and iSeries) is the operating system on IBM Power servers, licensed differently from IBM Z mainframes running z/OS. What the two share is decades of RPG or COBOL code that few people can still maintain, so we run them as separate diagnostics with separate goals. **Do we have to move everything at once?** No. We start with the batch and extract jobs that cost the most or carry the most risk, and move in waves. You can go all the way to a full migration, or stop when the remaining savings aren’t worth it. **What is mainframe offload?** Mainframe offload means moving individual workloads, usually batch jobs, extracts and reporting, off the mainframe to cheaper platforms while the core systems keep running there. Offloading workloads off the mainframe lowers the CPU and software use that drives the bill, and it is often the first step toward a full migration. **Can BMC AMI replace IBM Omegamon or Broadcom’s monitoring tools?** Often, but it depends on what you monitor. IBM OMEGAMON, BMC AMI Ops (formerly BMC MainView) and Broadcom’s SYSVIEW all overlap as z/OS performance monitors, and each vendor sells separate monitors for z/OS, CICS, Db2, IMS and MQ. A swap works when the new tool covers every subsystem, alert, automation rule and report your operators rely on. We would inventory those, run the new monitor alongside the old one for a few business cycles, and compare the licensing cost before anything is turned off. Moving workloads off the mainframe also shrinks how much monitoring you need to license. **Will you need a copy of all our data?** Not up front. Each job only needs the files or tables it reads. We replicate those inputs to the cloud — as a scheduled extract or a change data capture feed — and widen the scope as more workloads move. ## Infrastructure evaluation URL: https://axiointelligence.com/services/infrastructure-assessment Axio Intelligence evaluates software and cloud infrastructure independently — architecture, security posture, reliability, scalability, cost and team practices — and delivers a ranked findings report with a practical roadmap. Leaders use it before a scale-up, a fundraise, an acquisition or a major customer’s security review. ### Signs you need this - An investor, acquirer or large customer is about to look under the hood. - You’re about to 10× device count or users and aren’t sure what breaks first. - A new engineering leader needs an honest baseline in weeks, not quarters. ### What we deliver - Architecture review: Current-state diagrams, data flows and single points of failure. - Security posture: Identity, secrets, network exposure, device security and supply-chain hygiene (SBOM). - Reliability & scale: Load characteristics, bottlenecks and failure modes at the next order of magnitude. - Ranked roadmap: Findings ordered by risk and effort, with fixed-fee options for each. Stack: AWS / GCP / Azure, Kubernetes, Terraform, NIST SP 800-171 alignment, DISA STIG-aligned baselines, SBOM (SPDX / CycloneDX), SLSA, SPIFFE / SPIRE, Threat modeling Engagement: Fixed-fee assessment Timeline: Typically 2–3 weeks ### FAQs **What do we get at the end of an infrastructure evaluation?** A written report and a live walkthrough: current-state architecture, ranked findings with risk and effort, and a roadmap. It is useful on its own — you are not obligated to hire us for the fixes. ## DevOps, SRE & ongoing support URL: https://axiointelligence.com/services/devops-sre Axio Intelligence runs DevOps and site reliability engineering for teams that ship connected products — CI/CD for cloud services and firmware, infrastructure as code, observability, SLOs and alerting, incident response, and ongoing support on a monthly retainer after launch. ### Signs you need this - Deploys are manual, risky, or depend on one person being online. - You find out about outages from customers. - The system launched and now nobody has time to run it. ### What we deliver - CI/CD: Automated build, test and deploy for services and firmware, with signed artifacts and SBOMs. - Infrastructure as code: Terraform/OpenTofu environments on AWS, Google Cloud or Azure that are reproducible and reviewable. - Observability & SLOs: Metrics, logs, traces and device-fleet health with alerts tied to user-facing objectives. - Ongoing support: On-call, patching, capacity planning and a monthly reliability review. Stack: Kubernetes, Terraform / OpenTofu, OpenTelemetry, Prometheus, Grafana, Loki, Argo CD, GitHub Actions, Sigstore / cosign, Iron Bank hardened images, FIPS 140-3 validated crypto, HashiCorp Vault, Sentry, AWS GovCloud-ready patterns Engagement: Setup project, then a monthly support retainer Timeline: Setup: 3–8 weeks · Support: month to month ### FAQs **Do you offer ongoing support after a project ships?** Yes. Most builds move to a monthly support retainer covering monitoring, on-call, patching, OTA releases and a monthly reliability review. It is optional — we also document and hand off to your team. # Industries ## Connectivity providers & IoT platforms URL: https://axiointelligence.com/industries/iot-connectivity-providers Axio Intelligence is an IoT systems integrator and implementation partner for connectivity providers — cellular MVNOs, eSIM platforms, module makers, satellite IoT networks and private LTE operators. When a customer buys SIMs or modules and then stalls on firmware, cloud, command-and-control or dashboards, we build that layer on your stack, and the customer stays yours. ### Problems we solve - Accounts that stall after the SIM order: The OEM signs, orders SIMs, then waits months on firmware and cloud. Activations — and your revenue — wait with them. - Custom work your team shouldn’t staff: Solutions engineers get pulled into application builds that don’t scale across your customer base. - Churn risk when projects fail: A failed pilot looks like a connectivity problem even when it was a software problem. ### What we build - Device application & firmware: On your modules and SIMs, tuned for your network’s power and data profile. - Device-to-cloud & command path: Ingestion, acknowledged commands and OTA, integrated with your platform APIs. - Fleet console: The dashboard the OEM’s operations team and end customers actually use. - Vertical integrations: Utility, industrial, logistics and C2 integrations your customers ask for. ### Protocols and standards - Cellular & eSIM: LTE-M, NB-IoT, Cat-1bis, SGP.32 eSIM, Multi-IMSI - Satellite & private networks: 3GPP NTN, Iridium SBD / Certus, Globalstar, CBRS private LTE, 900 MHz LTE - Device-to-cloud: MQTT, LwM2M, CoAP, HTTPS / webhooks, AWS IoT Core - Platforms we build on: Blues Notecard / Notehub, Particle, Digi Remote Manager, Telit deviceWISE, MultiTech Conduit Rules of engagement: We build on your network and don’t move referred customers to another one. Connectivity decisions stay with you. We report status back to your partner team on every referred account. ### FAQs **How does a connectivity provider refer an account to Axio?** Send an introduction. We run a joint scoping call within two business days, quote a fixed-scope project to the customer, and keep your partner manager updated through delivery. The customer contracts with us for engineering and with you for connectivity. **Will Axio recommend a different carrier to our customer?** No. We build on the connectivity the customer already chose. If there is a real technical constraint, we raise it with you first. **Can Axio act as overflow for our solutions engineering team?** Yes. Many providers use us as a white-label or co-branded engineering bench for application work that falls outside their core platform. ## Energy & DER devices URL: https://axiointelligence.com/industries/energy-der Axio Intelligence builds the software that lets utilities, aggregators and virtual power plants dispatch your devices — a reliable cellular command path, IEEE 2030.5, OpenADR 2.0b/3.0, SunSpec Modbus and OCPP interfaces, aggregator and DERMS integrations, fleet telemetry for measurement and verification, and secure OTA — for makers of home and commercial battery storage, solar inverters and backup power systems, EV chargers and load-control equipment. ### Problems we solve - Wi-Fi-only devices can’t be relied on: Utilities now buy firm capacity and fast response. Home Wi-Fi drops, routers change, and dispatch success suffers. - A new protocol for every program: Each utility, aggregator or state rule means another adapter and another certification cycle. - Program approval blocks sales: If your device isn’t on the program’s approved list, the utility can’t buy it — no matter how good the hardware is. - Cybersecurity is becoming a gate: Signed firmware, device identity and SBOMs are showing up in utility and standards requirements. ### What we build - Cellular command path: LTE-M/Cat-1bis connectivity with acknowledged commands and store-and-forward, independent of customer Wi-Fi. - Utility & aggregator adapters: IEEE 2030.5 client, OpenADR VEN, SunSpec Modbus and aggregator API integrations. - Fleet console & M&V data: Availability, dispatch acknowledgements, load shed and baselines your program partners can audit. - Secure OTA & device identity: Signed, staged updates and per-device certificates across the installed base. ### Protocols and standards - Device & grid interfaces: IEEE 2030.5 / CSIP, OpenADR 2.0b, OpenADR 3.0, SunSpec Modbus, OCPP 1.6 / 2.0.1, BMS over CAN / Modbus - Programs & integrations: Utility DR programs, VPP aggregators, DERMS, ERCOT ADER, CA SGIP - Security & standards: UL 2941, IEEE 1547.3, NISTIR 7628, Signed OTA, SBOM - Device-to-cloud: LTE-M / Cat-1, Wi-Fi & BLE commissioning, MQTT over TLS, AWS IoT Core, Cloud-to-cloud APIs ### FAQs **How do I make my energy device dispatchable by a utility?** You need a reliable command path to every unit (usually cellular, not customer Wi-Fi), a supported interface — IEEE 2030.5, OpenADR or an aggregator API — acknowledgements and telemetry that prove the device responded, and a fleet console for your program partners. Axio builds all four. **Should we implement OpenADR 2.0b or 3.0?** Most existing utility programs still specify OpenADR 2.0b; OpenADR 3.0 is simpler to build against and gaining adoption. We usually recommend a VEN architecture that can speak both, so one integration covers current and upcoming programs. **Can you add cellular to a home battery or solar inverter?** Yes — as a gateway alongside the inverter or battery management system, or integrated into your controller — with a cloud command path your utility and VPP partners can dispatch against. ## Defense & dual-use URL: https://axiointelligence.com/industries/defense-dual-use Axio Intelligence builds the software around defense and dual-use hardware — drones, counter-UAS sensors, radios and SATCOM terminals: integrations with TAK/Cursor on Target and other C2 systems, ground control and operator consoles, fleet health, remote configuration and secure OTA, cellular/SATCOM failover for DDIL conditions, edge AI, and the data pipelines from field to model. Engagements start unclassified. ### Problems we solve - “Integrate once, show up everywhere”: Every sensor and effector has to appear in the operator’s common operating picture, through more than one C2 system. - Fleets outgrow the startup dashboard: After first fielding, health monitoring, configuration and OTA across units becomes the bottleneck. - Degraded comms are the default: Links drop. Systems need primary/alternate paths and graceful store-and-forward. - Prototype to program: A contract award turns a demo into a delivery schedule, faster than the software team can grow. ### What we build - C2 & COP integration: TAK plugins and CoT bridges, and connectors to C2 platforms through their published SDKs and APIs. - Operator & fleet software: Ground control, mission and operator consoles; fleet health, configuration and after-action data. - Secure OTA & device lifecycle: Signed updates for embedded Linux and Jetson-class devices, provisioning and depot tooling. - Resilient comms: Cellular, SATCOM and mesh path selection with failover and message prioritisation. - Edge AI & data pipelines: Detection and anomaly models on the edge, and the pipeline that gets field data into models. ### Protocols and standards - C2 & interoperability: TAK / ATAK plugins, Cursor on Target (CoT), DDS (RTI Connext / Cyclone), gRPC / Protobuf, Cesium / MapLibre mapping, MOSA-aligned interfaces - Vehicles & autonomy: MAVLink, PX4 / ArduPilot, ROS 2, NVIDIA Jetson / DeepStream, MISB KLV / STANAG 4609 video - Comms: LTE / private LTE, SATCOM (LEO / GEO), Iridium, PACE / DDIL design, NATS store-and-forward - Delivery: Rust / C++ on Yocto Linux, Air-gapped K8s: RKE2 + Zarf, Iron Bank hardened images, FIPS 140-3 validated crypto, Signed builds, SBOM & SLSA, NIST SP 800-171-aligned practices How we engage: Unclassified, fixed-scope integration sprints; subcontracting on SBIR/STTR and prototype awards; and teaming with primes and small businesses. We do not hold a facility clearance, and we say so up front. ### FAQs **Can Axio build a TAK plugin or Cursor on Target integration for our system?** Yes. We build TAK plugins and CoT bridges that publish your device’s tracks, status and alerts into the operator’s TAK environment, alongside REST/gRPC connectors for other C2 platforms. **Does Axio hold a security clearance?** No. Axio Intelligence does not hold a facility clearance. Our engagements are unclassified — fleet software, commercial connectivity, test telemetry, integrations and data pipelines — and we are transparent about that in scoping. **Can Axio subcontract on an SBIR or prototype award?** Yes. We work as a software and hardware subcontractor to small businesses on SBIR/STTR and prototype awards, and as a teaming partner for integration work primes don’t want to staff. ## Industrial & remote assets URL: https://axiointelligence.com/industries/industrial-remote-assets Axio Intelligence builds monitoring and control for assets far from the network — wellheads, pump stations, tanks, cold storage, water systems and municipal infrastructure: telemetry over cellular and satellite, Modbus and SCADA integration, anomaly detection that warns before failure, and dashboards and alerts for operations teams. We also modernize the monitoring platforms that already run these fleets. ### Problems we solve - Truck rolls to check on equipment: Someone drives out to read a gauge that could have reported itself. - Legacy monitoring platforms: A system built a decade ago is slow, expensive to run and hard to extend. - Alarms without context: Operators get noise, not early warning. ### What we build - Telemetry & control: Sensor and PLC integration over Modbus, with cellular or satellite backhaul. - Anomaly detection: Baselines per asset that flag drift and failure before it becomes downtime. - Operations dashboards: Maps, trends, alerts and reports your field teams trust. - Platform modernization: Performance, cost and reliability work on existing monitoring platforms. ### Protocols and standards - Field: Modbus RTU / TCP, OPC UA, SCADA integration, MQTT Sparkplug B, 4–20 mA / digital I/O - Links: LTE-M / Cat-1, Satellite IoT, LoRaWAN, Private LTE - Platform: ClickHouse / TimescaleDB, Kafka / Flink streaming, Anomaly detection, Alerting & escalation, PostGIS / H3 geospatial - Operations: Remote config & OTA, Store-and-forward buffering, Solar & battery power budgets, Work-order & ERP integration Remote intelligent gateways: Most remote sites start with a gateway: a rugged edge box that polls PLCs, RTUs and sensors over Modbus, OPC UA or I/O, buffers readings when the link drops, and sends them over cellular or satellite once it is back. We pick or build the hardware, write the edge software, and size the power and data plan so a site can run unattended for months. ### FAQs **What is a remote intelligent gateway?** An edge device installed at a remote site that collects data from PLCs, RTUs and sensors, processes and stores it locally, and forwards it over cellular or satellite. Because it buffers data offline and can run local logic, a site keeps recording and alarming through outages instead of losing readings. **Can you connect existing field equipment without replacing it?** Usually, yes. We add a gateway that reads existing controllers and sensors over Modbus or digital I/O and backhauls over cellular or satellite, so the installed equipment stays in place. ## Manufacturing & distribution URL: https://axiointelligence.com/industries/manufacturing-distribution Axio Intelligence works with US manufacturers, distributors, wholesalers and mid-size retailers that still run the business on IBM mainframes (z/OS and COBOL), IBM i (AS/400 and RPG), or legacy Oracle and SQL Server databases. We move those workloads — starting with inventory, replenishment, pricing feeds, nightly reports and partner file exchanges — to AWS, Azure or Google Cloud and PostgreSQL or MySQL, cutting licensing and compute cost and the dependence on the last person who understands the code. ### Problems we solve - Licensing that grows every year: IBM, Broadcom, BMC, Oracle or Microsoft — whatever the contract model, the bill rises with the work on the old platform. - Batch nobody wants to touch: Inventory, replenishment and pricing jobs feed the warehouse, the stores and EDI partners. If one is late, someone screams. - The last person who knows the code: The RPG, COBOL and stored procedures that run the business depend on a shrinking group of people. ### What we build - Mainframe batch migration: COBOL batch and extract jobs on z/OS moved to the cloud in a modern language, starting with the ones that cost the most. Offloading those workloads off the mainframe lowers the usage your software bill is based on. - IBM i batch & extract offload: RPG and COBOL batch and file extracts rebuilt in the cloud, documented and owned by more than one person. - Database migration: Db2, Oracle and SQL Server moved to PostgreSQL or MySQL, with data kept in sync until cutover. - Inventory, pricing & replenishment feeds: Extracts landed in Postgres or your warehouse, so planning, pricing and e-commerce read from the cloud instead of the box. ### Protocols and standards - IBM Z: z/OS, COBOL, JCL, Db2 for z/OS, VSAM - IBM i: IBM i (AS/400, iSeries), RPG IV / ILE RPG, CL, Db2 for i, Physical & logical files - Databases: Oracle → PostgreSQL, SQL Server → PostgreSQL / MySQL, Db2 → PostgreSQL, Change data capture, EDI (X12) & SFTP feeds - Where it lands: AWS · Azure · Google Cloud, PostgreSQL · MySQL, Amazon RDS / Aurora, Snowflake / BigQuery, Terraform / OpenTofu How it’s priced: Mainframe and IBM i migration has no upfront fee: we are paid a percentage of the net savings in licensing and compute spend, measured against a baseline we agree before work starts. ### FAQs **Can you move inventory and pricing feeds off the mainframe?** Yes. They are typical first candidates: they read IBM data and write a file, feed or report, so they can be rebuilt in the cloud and run side by side with the old job until the outputs match. **Can you migrate our Oracle or SQL Server databases too?** Yes. We migrate Oracle, SQL Server and Db2 to PostgreSQL or MySQL, converting schemas and stored procedures and keeping data in sync until cutover. **Who is this not for?** Bank deposit and money-movement cores, card authorization, insurance claims adjudication and government benefit systems. Our focus is manufacturers, distributors, wholesalers and mid-size retailers. # Case studies ## The AI data platform behind MLtwist URL: https://axiointelligence.com/work/mltwist-ai-data-platform Client: MLtwist · Sector: AI data platforms · Status: In production We designed and built the platform MLtwist runs its AI data business on — projects, people, labeling and Kubernetes pipelines. Our role: Axio designed and built the MLtwist platform. Challenge: MLtwist turns raw, messy data into model-ready datasets for government, research and enterprise customers. Every customer brings different data types, labeling tools and delivery formats, so the business needed one platform to run projects, people and pipelines — without custom engineering for every engagement. ### Approach - We designed the platform around the unit MLtwist actually sells: a customer project. Each project carries its data sources, labeling instructions, workforce assignments, quality rules and delivery format, so onboarding a new customer is configuration rather than a new codebase. - Processing runs as containerized workloads on Kubernetes. When a project needs data pulled, transformed, labeled or packaged, the platform triggers the right custom pipeline as jobs that scale up for large batches and back down when idle. - Around that core we built workforce management for labelers and reviewers, labeling project setup and assignment, automated quality control, and versioned, tracked data in a secure environment. ### Scope - Project and customer management - Workforce management for labelers and reviewers - Labeling project setup, assignment and QC - Custom pipelines triggered per project on Kubernetes - Containerized processing workloads that scale per job - Versioned, tracked data in a secure environment Stack: Kubernetes, Containers, Data pipelines, Human-in-the-loop labeling, Postgres, Object storage Outcome: The platform is the operating system for MLtwist’s delivery — the foundation for its public and private sector data work. ## Multimodal AI data for the U.S. TSA URL: https://axiointelligence.com/work/tsa-multimodal-ai-data Client: MLtwist · for the U.S. Transportation Security Administration · Sector: Government · aviation security · Status: Contract awarded Feb 2026 Video, audio, text, images and 3D DICOS scans — processed and labeled for threat-detection models, on the platform we built. Our role: MLtwist holds the TSA contract. Axio engineered the MLtwist platform the work runs on. Challenge: The TSA needed multimodal data — video, audio, text, images and 3D scans in the DICOS security-imaging standard — preprocessed, labeled and packaged to develop threat-detection models for aviation screening. ### Approach - The MLtwist platform we built already treated every customer as a configurable project, so the TSA work was set up as project configuration: DICOS and multimodal inputs, labeling instructions, reviewers and delivery formats. - Kubernetes-triggered pipelines handled preprocessing and transformation for each data type, feeding human-in-the-loop labeling with automated quality control, and packaged results as JSON or DICOS. - Every dataset stayed versioned and tracked in a secure environment, from raw input to delivered package. ### Scope - Multimodal ingest: video, audio, text, image and 3D DICOS - Preprocessing and transformation pipelines - Human-in-the-loop labeling with automated QC - Versioned, tracked data in a secure environment - Per-project setup of inputs, instructions, reviewers and formats - Delivery as JSON or DICOS packages Stack: Kubernetes, Multimodal pipelines, DICOS, Human-in-the-loop labeling Outcome: MLtwist reports that its pilot cut processing time from eight weeks to three. In February 2026 the TSA awarded MLtwist a $590K contract for multimodal AI data labeling and processing. Sources: - MLtwist: TSA awards $590K contract (Feb 2026): https://mltwist.com/blog/mltwist-awarded-590k-tsa-contract-for-multi-modal-labeling/ ## PRIMED: fast materials-data search for U.S. Department of Energy researchers URL: https://axiointelligence.com/work/doe-materials-data-search Client: MLtwist · for the U.S. Department of Energy (SBIR) · Sector: Government · materials science · Status: Delivered PRIMED, a search and indexing platform that lets scientists share materials data and find materials by recorded and projected properties — in seconds. Our role: Axio led an augmented engineering team that built PRIMED for MLtwist. Challenge: Materials scientists generate measurements across labs and instruments, while computational models project properties for materials nobody has measured yet. Finding a candidate material meant digging through papers, spreadsheets and siloed datasets — with no way to search what has been measured and what has been predicted together. ### Approach - We built PRIMED (Preparation & Requisition of Integrated Microscopy + Energy Data): a shared platform where scientists publish their materials data, findings and measurements, with an indexing and search layer fast enough to explore interactively. - Every material is indexed on both recorded measurements and projected, model-predicted properties, so a single query spans both. A scientist looking for a material that refracts specific wavelengths of light and also withstands a given temperature can ask for exactly that. - Multi-property, range-based queries across optical, thermal and other properties return ranked candidates in seconds. Axio led an augmented engineering team working alongside MLtwist to design and ship it. ### Scope - Shared repository for materials data, findings and measurements - High-speed indexing of recorded and projected properties - Multi-property, range-based search (e.g. optical + thermal) - Ranked candidate results for interactive exploration - Publishing workflow so scientists can share new datasets - Augmented engineering team working with MLtwist Stack: Search & indexing, Scientific data models, Data pipelines, Web application Outcome: Researchers can find candidate materials by the properties they need — measured or projected — instead of by the paper they happened to read. PRIMED was funded through MLtwist’s $198,834 U.S. Department of Energy SBIR award. Sources: - MLtwist: DOE SBIR award for PRIMED (Jan 2022): https://mltwist.com/blog/mltwist-wins-doe-deal/ ## Vehicle dealership telematics and lot management, rebuilt URL: https://axiointelligence.com/work/dealer-telematics-platform Client: Automotive telematics provider · confidential · Sector: Automotive · dealer telematics · Status: In production A new vehicle dealership telematics platform — built from zero, on lower-cost hardware, field tested and in production. Our role: Axio built the platform end to end — software, hardware sourcing, field testing and production rollout. Challenge: A telematics provider serving car dealerships needed to replace its existing telematics and lot-management platform. Dealers depend on it to know where every vehicle on the lot is, whether one is moving when it shouldn’t be, and whether devices are healthy — and the incumbent hardware was expensive. ### Approach - We built the entire platform from scratch: device firmware and cloud ingestion, the event and alerting engine, and the dealer-facing lot-management application. - We sourced hardware manufacturing and devices below the client’s existing unit cost, then field tested on real dealer lots before rolling out to production. - Devices send health checks and movement events over a global cellular IoT connectivity platform. The platform turns those events into geofence-breach and speeding alerts, and keeps a live view of every vehicle on the lot. ### Scope - Platform built from scratch: firmware, cloud and dealer app - Hardware sourcing and manufacturing below prior unit cost - Field testing on dealer lots, then production rollout - Device health checks and movement events over cellular IoT - Geofence-breach and speeding alerts - Lot management: live vehicle location and inventory Stack: Cellular IoT, Embedded firmware, Device-to-cloud, Event & alerting engine, Geofencing, Web application Outcome: The new platform is in production, replacing the client’s previous telematics and lot-management system on lower-cost hardware. ## An AI-first platform rebuild behind a company’s pivot URL: https://axiointelligence.com/work/ai-first-platform-pivot Client: Connected-device software company · confidential · Sector: Connected-device software · Status: In production · cloud and on-prem One platform for a new embedded Linux product, running on a laptop, in AWS and air-gapped on-prem. Built so the client’s own team could finish the overhaul with AI in under two weeks. Our role: Axio led the client’s software team through the pivot: we scaffolded the infrastructure and platform, then handed the team a codebase built for AI-assisted development. Challenge: After several years building a device-management platform, a connected-device software company decided on a major pivot: a new embedded Linux operating system for device makers. The platform behind it had to change too, and the team needed a clear path from the old platform to the new one. It also had to run in three places: on each developer’s laptop, in AWS, and inside customers’ own air-gapped facilities with no connection to the cloud. ### Approach - We designed one platform that runs the same way everywhere. Developers get a local copy that matches the AWS cloud environment, so what works on a laptop works in production. On-prem customers get an edition that runs on Kubernetes (K8s or K3s) inside air-gapped networks, managed without reaching the internet. - We scaffolded the initial infrastructure and platform as code, with reproducible environments and a one-command local setup, so every environment is built from the same definitions. - Then we put the guardrails in place that make AI-assisted development safe: agent instruction files that encode the project’s conventions, architecture docs and task specs that the team and its AI agents work from, and test suites and CI gates that block any change that doesn’t pass. - Finally, we walked the team through the new project and how to work in it AI-first, so they had a running start rather than a blank repository. ### Scope - Infrastructure and platform scaffolding as code - Local developer environment matching AWS - Air-gapped on-prem edition on K8s and K3s - Agent instruction files and project conventions - Test suites and CI gates as guardrails - Architecture docs, task specs and team onboarding Stack: AWS, Kubernetes, K3s, Infrastructure as code, CI/CD, AI coding agents Outcome: With the guardrails in place, the client’s own team finished the platform overhaul in under two weeks. The new platform runs in production on AWS and air-gapped on customer premises, and every developer runs the same stack locally. # Blog ## pgvector vs Pinecone for Enterprise RAG: When Postgres Is Enough URL: https://axiointelligence.com/blog/pgvector_vs_pinecone_rag Published: 2026-10-20 · Author: Brice Ayres · Tags: pgvector, vector database, rag, postgresql, ai infrastructure Short answer: For most enterprise RAG systems, pgvector on the PostgreSQL you already run is the right vector database: it supports HNSW and IVFFlat indexes, filters with plain SQL, and runs on RDS, Aurora, Cloud SQL, AlloyDB and Azure. Add pgvectorscale or VectorChord when the index outgrows memory, and pick a dedicated vector database like Pinecone only when vector search is a separate, very large, high-traffic workload. When a team starts building retrieval-augmented generation (RAG), one of the first questions is where the embeddings should live. Vendor marketing makes it sound like you need a dedicated vector database from day one. In our experience, most enterprise teams don't. If you already run PostgreSQL, pgvector is the default choice, and it's usually enough for years. That's not because pgvector is the fastest vector index in every benchmark. It's because RAG is mostly a data problem: keeping chunks, metadata, permissions and embeddings in sync, and filtering by who is allowed to see what. Postgres already does that well. This guide covers what pgvector does, how to tune HNSW, what AlloyDB and Aurora add, where pgvectorscale and VectorChord fit, and when Pinecone or OpenSearch is worth the extra system. ### Is pgvector the best vector database for RAG on Postgres? Yes, for most teams it's the standard starting point. [pgvector](https://github.com/pgvector/pgvector) is an open-source PostgreSQL extension for vector similarity search. Every major managed Postgres service supports it, including Amazon RDS and Aurora, Google Cloud SQL and AlloyDB, and Azure Database for PostgreSQL. Other Postgres vector extensions, such as pgvectorscale and VectorChord, build on its data types rather than replacing them. What you get: - **Vector types.** `vector` (indexable up to 2,000 dimensions), `halfvec` (half precision, up to 4,000), `bit` (binary, up to 64,000) and `sparsevec`. - **Two index types.** HNSW and IVFFlat, with L2, inner product, cosine and other distance functions. - **SQL filtering and joins.** Your access rules, tenant IDs, document dates and source systems are ordinary columns. A RAG query is one `SELECT` with a `WHERE` clause and an `ORDER BY embedding <=> $1 LIMIT 10`. - **Transactions.** When a document is updated or deleted, its chunks and embeddings change in the same transaction. No sync job between two systems, and no stale vectors pointing at deleted content. - **Your existing operations.** Backups, replicas, point-in-time recovery, encryption, auditing and IAM already work. That last point matters more than any benchmark. Every extra datastore is another thing to secure, monitor, back up and pay for. ### pgvector vs Pinecone: what's the real difference? Pinecone is a fully managed, purpose-built vector database. pgvector is a feature of the database you already run. The trade-off is less about raw speed and more about where the complexity lives. | | pgvector on Postgres | Pinecone (dedicated vector database) | |---|---|---| | Where data lives | Same database as your app data and metadata | Separate service; you sync data into it | | Filtering and permissions | Full SQL, joins, row-level security | Metadata filters on stored fields | | Consistency | Transactional with your source data | Eventually in sync via your pipeline | | Scaling | Scale up the instance, add read replicas, partition | Managed by the vendor | | Operations | Your existing Postgres skills and tooling | No database to run, but a new vendor to secure and govern | | Cost model | Part of your database bill | Separate usage-based bill | For a typical internal RAG system, such as a policy assistant, a support knowledge base or an engineering document search, the corpus is in the thousands to low millions of chunks. That's well within what a properly sized Postgres instance with an HNSW index handles. **Building RAG on data you already have in Postgres?** Axio Intelligence designs and builds [data and AI platforms](https://axiointelligence.com/services/data-ai-platforms), from chunking and embeddings to retrieval, evaluation and access control. We'll tell you honestly whether you need another database. [Book a scoping call](https://axiointelligence.com/book). ### How do you tune pgvector HNSW for RAG? HNSW is the index to use for most RAG workloads. The pgvector docs describe it as having a better speed-recall trade-off than IVFFlat, at the cost of slower builds and more memory. It also doesn't need training data, so you can create it on an empty table. The settings that matter: - **`m` and `ef_construction`** control graph quality at build time. The defaults (16 and 64) are a sensible start; raise them only if your recall tests say so. - **`hnsw.ef_search`** controls how much of the graph each query explores. The default is 40. Raise it per query or per transaction (`SET LOCAL hnsw.ef_search = 100`) to trade speed for recall. - **`maintenance_work_mem`** decides build speed. pgvector builds much faster when the graph fits in it, and it warns you when it doesn't. Don't set it so high that the server runs out of memory. - **Iterative index scans.** Approximate indexes filter *after* scanning, so a selective `WHERE` clause can return fewer rows than you asked for. The docs give the example that a condition matching 10% of rows returns only about 4 rows on average at the default `ef_search` of 40. Since pgvector 0.8.0, `SET hnsw.iterative_scan = strict_order` (or `relaxed_order`) keeps scanning until enough rows match. Turn it on for any permission-filtered RAG query. - **`halfvec`.** Half-precision values take 2 bytes instead of 4, so storing or indexing embeddings as `halfvec` roughly halves their size. Check the recall impact against your own queries. Measure recall against exact search on a sample of real questions before and after each change. RAG answer quality depends on retrieval quality, and the only honest way to know is to test it. #### Keep pgvector patched On October 5, 2026, the pgvector project [released 0.8.7](https://www.postgresql.org/about/news/pgvector-087-released-3392/), which fixes a buffer overflow in IVFFlat index builds (CVE-2026-103484) that can lead to arbitrary code execution. Users are encouraged to upgrade. On managed services the pgvector version is tied to the engine's minor version, so check what your provider ships (`SELECT extversion FROM pg_extension WHERE extname = 'vector';`) and plan the minor upgrade. ### What does AlloyDB vector search add? AlloyDB is Google Cloud's PostgreSQL-compatible database, and it runs pgvector. In a [July 21, 2026 post](https://cloud.google.com/blog/products/databases/supercharge-pgvector-4x-faster-hnsw-with-alloydb), Google reported that caching pgvector HNSW indexes in AlloyDB's columnar engine gives up to 4x higher queries per second than standard PostgreSQL HNSW, with no application changes. On the GloVe-100 benchmark (over 1 million vectors, measured on a 16 vCPU C4A machine), Google saw about 4.2x to 4.9x more QPS at 0.95 recall. Google notes that its baseline already had the index fully in PostgreSQL's shared buffers, so the gain comes from the memory layout, not from avoiding disk. Per [Google's documentation](https://docs.cloud.google.com/alloydb/docs/ai/accelerate-with-ce), columnar engine acceleration for HNSW is generally available and requires PostgreSQL 17 or later. AlloyDB also offers Google's ScaNN index, which Google positions for very large datasets that exceed memory. If you're already on Google Cloud and vector query throughput is your bottleneck, AlloyDB is a way to get more out of pgvector without leaving Postgres. ### Aurora pgvector vs OpenSearch: which should you use on AWS? On AWS, the usual choice is between pgvector on Aurora or RDS PostgreSQL and the vector engine in Amazon OpenSearch Service. **Choose Aurora or RDS with pgvector when** your source data and metadata already live in Postgres, you need SQL joins and row-level permissions in retrieval, and the corpus fits a single well-sized cluster. AWS documents [running pgvector in production on Aurora](https://aws.amazon.com/blogs/database/running-pgvector-in-production-on-amazon-aurora-postgresql/), and Aurora's recent 17 and 18 releases ship pgvector 0.8.x. **Choose OpenSearch when** you already run it for search or logs, keyword relevance tuning is central to your product, or you need to scale search horizontally across many nodes separately from your transactional database. Hybrid search (keywords plus vectors) doesn't force the decision. Postgres has built-in full-text search, and the pgvector docs show combining it with vector search, for example with reciprocal rank fusion. ### Where do pgvectorscale and VectorChord fit? They're for the point where plain pgvector starts to strain, usually because the HNSW index no longer fits comfortably in memory. Both keep you inside Postgres and work with pgvector's data types. - **[pgvectorscale](https://github.com/timescale/pgvectorscale)** adds a StreamingDiskANN index (inspired by Microsoft's DiskANN research), Statistical Binary Quantization, and label-based filtered search. It's written in Rust. - **[VectorChord](https://github.com/tensorchord/VectorChord)** uses RaBitQ quantization with reranking, focuses on large indexes and fast builds, and is compatible with pgvector types and syntax. - **On Azure,** Azure Database for PostgreSQL offers a [`pg_diskann` extension](https://learn.microsoft.com/en-us/azure/postgresql/extensions/how-to-use-pgdiskann) that builds on pgvector. Two caveats. First, availability: these extensions aren't on every managed service, so self-hosting or a specific provider may be required. Second, the projects publish their own benchmarks, and vendor benchmarks are run on the vendor's chosen workload. Test with your data and your queries. ### When is a dedicated vector database worth it? A dedicated vector database such as Pinecone earns its place when vector search is its own large workload, not a feature of an application database. Signs you're there: - **Very large corpora.** Hundreds of millions to billions of vectors, where a single Postgres instance becomes expensive or awkward even with quantization. - **Search traffic that would hurt your OLTP database.** High query volume that you'd rather isolate from transactions. - **Many tenants or indexes** with very different sizes and traffic. - **No Postgres team.** If nobody on staff runs Postgres and you want a fully managed service with no tuning, a managed vector database can be simpler. - **Your data doesn't live in Postgres anyway.** If the source is a data lake or document store, the "same database" advantage disappears. If none of those apply, start with pgvector. Moving embeddings later is straightforward: they're just arrays of numbers you can regenerate or export. Moving permissions logic and sync pipelines out of a second system is the hard part, which is another reason to avoid one until you need it. ### What actually decides whether RAG works? Rarely the vector database. In the RAG projects we see stall, the causes are usually: - **Chunking** that splits tables, procedures or contracts in the wrong place. - **No evaluation set**, so nobody can tell if a change made answers better or worse. - **Permissions bolted on late**, so the assistant can retrieve documents a user shouldn't see. - **Stale content**, because nothing re-embeds documents when they change. These are data and engineering problems, not database choices. If you're deciding where the model itself should run, see our guide on [on-prem LLMs vs frontier APIs](https://axiointelligence.com/blog/on_prem_llm_vs_frontier_api). And if your documents still live in Oracle, [moving to PostgreSQL](https://axiointelligence.com/blog/oracle_to_postgres_migration_cost) can put your data and your vectors in one place; our [database migration services](https://axiointelligence.com/services/database-migration) cover that work. ### FAQ #### Is Postgres a good vector database? Yes, for most RAG and semantic search workloads. With pgvector, PostgreSQL stores embeddings next to your data, indexes them with HNSW or IVFFlat, and filters results with SQL. It runs on all the major managed Postgres services. #### Is pgvector better than Pinecone? It depends on the workload. pgvector is usually the better fit when your data is already in Postgres and you need SQL filtering, joins and transactions. Pinecone is a better fit for very large, high-traffic vector workloads run as a separate service, or for teams that don't want to run a database. #### Should I use HNSW or IVFFlat in pgvector? Use HNSW for most RAG workloads. It gives better query performance for the same recall. IVFFlat builds faster and uses less memory, but needs data in the table before you build it. If you use IVFFlat, upgrade to pgvector 0.8.7 for the CVE-2026-103484 fix. #### How many vectors can pgvector handle? There's no single limit; it depends on dimensions, memory and recall targets. Millions of vectors on one well-sized instance are common. Beyond that, `halfvec`, binary quantization, partitioning, pgvectorscale or VectorChord extend the range before a separate database is needed. #### Does AlloyDB support pgvector? Yes. AlloyDB runs pgvector, and its columnar engine can cache HNSW indexes for up to 4x higher query throughput than standard PostgreSQL, according to Google. HNSW acceleration is generally available on PostgreSQL 17 and later. ### Talk it through If you're choosing a vector store for a RAG project, or your pgvector setup has started to slow down, we're happy to look at it with you. [Book a call](https://axiointelligence.com/book) and bring your corpus size, query volume and where your data lives today. *PostgreSQL elephant logo © The PostgreSQL Global Development Group. Pinecone logo is a trademark of Pinecone Systems, Inc. Logos are used for identification only.* ## Oracle to Postgres Migration: Real Cost and When to Hire URL: https://axiointelligence.com/blog/oracle_to_postgres_migration_cost Published: 2026-10-19 · Author: Brice Ayres · Tags: oracle to postgres, database migration, postgresql, ora2pg, oracle licensing Short answer: An Oracle to Postgres migration costs less in licenses but more in engineering than most plans assume. ora2pg and AWS DMS automate schema and data moves, but PL/SQL packages, NULL vs. empty-string behavior, DATE and NUMBER mapping, and cutover testing take the real time. Hire a migration firm when code volume, downtime limits or a support renewal date leave no room for learning on the job. IT and data leaders usually come to us with the same trigger: the Oracle support renewal is on the calendar again, and someone has asked why the company is still paying it. Moving to PostgreSQL is a well-worn path, and the tooling is good. But the license savings are the easy part of the math. The cost that decides whether the project succeeds is the engineering work to convert code, prove the data is right, and cut over without breaking the applications that depend on it. This guide covers what drives the cost, the phases and what sets their length, what ora2pg automates and what it doesn't, how to cut over, where to run PostgreSQL, and when an outside team pays for itself. ### What does Oracle cost you today? Start with the bill you already pay. Oracle's [Technology Global Price List](https://www.oracle.com/a/ocom/docs/corporate/pricing/technology-price-list-070617.pdf), dated September 15, 2026, lists Oracle Database Enterprise Edition at $47,500 per processor license, with Software Update License & Support at $10,450 per processor per year, which is 22% of the license price. Options such as Partitioning, Advanced Security or Real Application Clusters are priced on top, per processor, with their own support. Three things make the real number differ from the list: - **Processor counting.** Oracle defines a processor by its own rules for physical cores and virtualized hosts, so the count can be higher than you expect, especially on VMware or cloud instances. - **Negotiated discounts.** Most enterprises don't pay list. Support is usually calculated on what you actually paid, and it tends to rise over time. - **Audit exposure.** Options turned on but not licensed, or databases on hosts nobody counted, are a common finding. An honest inventory is part of any migration assessment, and it often changes the business case. PostgreSQL itself has no license fee. You still pay for hosting, support if you want a vendor behind you, and the people who run it, but the per-processor bill goes away. ### What drives the cost of an Oracle to Postgres migration? The engineering cost depends far more on how much logic lives inside the database than on how much data it holds. In rough order of impact: 1. **PL/SQL volume and style.** Packages, triggers, stored procedures and functions all need conversion and testing. A database used as a plain data store moves quickly. One with business logic in packages is a software project. 2. **Oracle-specific features.** Advanced Queuing, Oracle Text, Spatial, database links, materialized view refresh groups, `DBMS_*` packages and scheduler jobs each need a PostgreSQL equivalent or a redesign. 3. **Application SQL.** Embedded SQL in Java, .NET or reporting tools often uses Oracle syntax and has to change with the database. 4. **Downtime tolerance.** A weekend outage allows a simple dump-and-load. Near-zero downtime needs change data capture, dual-running and more testing. 5. **Data volume and shape.** Large LOBs, very large tables and odd character sets slow the data move and the validation. 6. **Testing depth.** Regulated or revenue-critical systems need row-level validation and performance testing, and that usually takes longer than the conversion. ### How long does it take to migrate an Oracle database to PostgreSQL? The timeline follows the same six phases on every project. Their length depends on the cost drivers above, which is why we don't quote a duration before an assessment. 1. **Assessment.** Inventory schemas, objects, PL/SQL lines, features in use, application dependencies and licenses. ora2pg's assessment report estimates migration effort per object type and is a good first pass. 2. **Schema conversion.** Tables, indexes, constraints, sequences, views and partitions, translated and reviewed by a person. 3. **Code conversion.** PL/SQL into PL/pgSQL, plus application SQL. This is usually the longest phase. 4. **Data migration.** Bulk load, then ongoing replication if the cutover needs it. 5. **Testing.** Functional tests, row counts and checksums, query results compared side by side, and performance under real load. 6. **Cutover.** Freeze, final sync, switch connections, watch closely, and keep a rollback path until you trust the new system. ### What does ora2pg automate, and what doesn't it? [ora2pg](https://ora2pg.darold.net/docs) is the standard open-source Oracle to Postgres migration tool. It connects to Oracle, exports the schema as PostgreSQL DDL, converts a good share of PL/SQL to PL/pgSQL, and loads data. Its assessment mode is useful for scoping before anyone commits to a budget. AWS's Schema Conversion Tool does similar work for AWS targets. What the tools get you is a strong first draft. These are the places where people still have to read and fix the code: - **PL/SQL packages.** PostgreSQL has no packages. ora2pg maps a package to a schema of functions, but package-level variables, initialization blocks and private state need a redesign. - **NULL vs. empty string.** Oracle treats an empty string as NULL. PostgreSQL doesn't. Any `WHERE col IS NULL`, concatenation or `NVL` that relied on Oracle's behavior can return different results with no error, which is why this one causes so many bugs. - **Sequences and identity.** Sequences convert cleanly, but `seq.NEXTVAL` calls, trigger-based keys and the final sequence values at cutover all need checking. Newer schemas can use PostgreSQL identity columns instead. - **Data types.** Oracle `NUMBER` without precision maps to `numeric`, which is slower than `integer` or `bigint` where those fit. Oracle `DATE` includes a time of day, so it maps to `timestamp`, not PostgreSQL `date`. Choosing types column by column affects both correctness and speed. - **Outer join syntax.** Oracle's old `(+)` join notation has to become ANSI `LEFT JOIN` / `RIGHT JOIN`. ora2pg rewrites many cases, but complex ones need review. - **Autonomous transactions.** PostgreSQL has no `PRAGMA AUTONOMOUS_TRANSACTION`. Audit logging that depends on it needs a workaround, such as a separate connection through an extension, or a design change. - **Optimizer hints.** Oracle hints are ignored by PostgreSQL. Queries that were tuned with hints need to be re-tuned with indexes, statistics and query rewrites. The PostgreSQL docs have a chapter on [porting from Oracle PL/SQL](https://www.postgresql.org/docs/current/plpgsql-porting.html) that is worth handing to every developer on the project. **Planning an Oracle to Postgres migration?** Axio Intelligence provides [Oracle database migration services](https://axiointelligence.com/services/database-migration), from assessment to cutover. We size the work with ora2pg, convert the PL/SQL your tools can't, and run the testing and cutover. [Book a scoping call](https://axiointelligence.com/book). ### How do you cut over without a long outage? There are two common approaches: - **Dump and load.** Stop writes, export, load, validate, switch. Simple and low-risk if the business can accept the downtime window. - **Change data capture and dual-run.** Do a bulk load, then stream ongoing changes from Oracle to PostgreSQL until you switch. [AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.Oracle.html) supports Oracle as a CDC source, and Google's [Database Migration Service](https://docs.cloud.google.com/database-migration/docs/oracle-to-postgresql/scenario-overview) offers Oracle to PostgreSQL migration. Open-source options such as Debezium do the same on your own infrastructure. With CDC, the switch becomes a short freeze and a final sync instead of a long outage. Whichever you choose, rehearse it on a copy of production, fix the sequence values, compare row counts and checksums, and agree in advance on what would trigger a rollback. ### Where should PostgreSQL run after the migration? Pick the target early, because it changes the tooling and some of the code: - **Amazon Aurora PostgreSQL or RDS for PostgreSQL**, if you're on AWS and want managed backups, failover and patching. - **Azure Database for PostgreSQL**, if your applications and identity already live in Azure. - **Google Cloud SQL for PostgreSQL or AlloyDB**, if you're on Google Cloud. AlloyDB targets heavier analytical and transactional mixes. - **Self-managed PostgreSQL** on your own servers or VMs, for air-gapped sites, data that can't leave your facilities, or when you want full control of extensions and versions. Managed services limit which extensions you can install, so check that anything your converted code depends on is supported before you commit. ### When should you hire an Oracle to PostgreSQL migration consultant? Doing it in-house makes sense when the database is mostly tables and simple queries, your team has PostgreSQL experience, and there's no hard deadline. Many teams handle that well with ora2pg and the PostgreSQL docs. Outside PostgreSQL consulting services pay off when: - **There's a lot of PL/SQL.** Packages and triggers with business logic are where projects stall, and experience with the common conversion problems saves the most time. - **Downtime is tight.** CDC, dual-running and rollback plans take practice to get right the first time. - **A renewal or audit date is fixed.** Missing the date can mean paying another year of support. - **Your team has to keep running production.** The people who know the Oracle system best are usually the busiest, and they can't also do the migration. - **You need an independent assessment.** A clear inventory and effort estimate makes the business case credible to finance. A good firm should leave your team able to run PostgreSQL afterward, with the conversion patterns, tests and runbooks documented. ### FAQ #### Is ora2pg enough for an Oracle to Postgres migration? It's enough for schema export, data loading and much of the PL/SQL conversion, and its assessment report is the best place to start. It won't redesign packages, fix NULL vs. empty-string logic or re-tune hinted queries. People still have to do that. #### What are the best Oracle to Postgres migration tools? ora2pg is the standard open-source choice. AWS Schema Conversion Tool and AWS DMS cover schema and data for AWS targets, and Google's Database Migration Service covers Oracle to PostgreSQL on Google Cloud. Debezium handles change data capture on your own infrastructure. #### Does PostgreSQL support PL/SQL? Not directly. PostgreSQL uses PL/pgSQL, which is similar but not the same. Code has to be converted, and packages, autonomous transactions and some built-in Oracle packages have no direct equivalent. #### How much does Oracle Database Enterprise Edition support cost? Oracle's September 15, 2026 price list shows $10,450 per processor per year for Software Update License & Support on Enterprise Edition, 22% of the $47,500 processor license. What you pay depends on your contract and discounts. #### Can we migrate with near-zero downtime? Yes, usually. A bulk load followed by change data capture with AWS DMS, Google's Database Migration Service or Debezium keeps PostgreSQL in sync until a short final switch. It needs rehearsal and a tested rollback plan. ### Talk it through If you're weighing a move off Oracle and want an honest read on the effort before you commit a budget, we're happy to look at it with you. [Book a scoping call](https://axiointelligence.com/book) and bring your object counts or an ora2pg report if you have one. ## AI Visual Inspection: Cloud Vision API or Edge Camera? URL: https://axiointelligence.com/blog/ai_visual_inspection_cloud_vs_edge Published: 2026-10-18 · Author: Brice Ayres · Tags: computer vision, quality control, manufacturing, edge AI, AI defect detection Short answer: Cloud image-decision APIs such as OpenAI's Decisions API are cheap and fine for prototypes, low-rate and non-critical visual checks. Line-rate inspection, air-gapped or poorly connected plants, and checks that must fire a PLC reject signal still need edge inference on a smart camera or industrial PC. Prove either one with a shadow-mode pilot measured on escape rate and false-reject rate. Plant and quality leaders keep asking us the same question: now that cloud models can look at a photo and tell you whether a part is damaged, do we still need cameras and compute on the line? Our short answer is that it depends on how fast the line moves, how good the network is, and what happens when the model says no. For a lot of checks, a cloud API is the cheaper and simpler choice, and we'd tell you to start there. For line-rate inspection that has to kick a bad part off the conveyor, the model still belongs at the edge. This guide gives you a decision rule, a pilot plan, the integration work, and the cost drivers to put in front of finance. ### What changed with cloud image APIs? General-purpose models can now answer narrow questions about an image quickly and cheaply. OpenAI's [Decisions API](https://developers.openai.com/api/docs/guides/decisions), in public beta as of October 2026, takes text and images and returns a typed answer: the probability that a condition is true (for example, visible damage such as a crack, tear or dent), a choice from a fixed set, or a score against a rubric. OpenAI says it is about 10 times faster than its Responses API and lists input at $0.10 per million tokens, with no output-token charge. A few details matter for inspection work: - **Images go inline.** The endpoint takes base64 images in the request, not hosted URLs, so every image leaves your network on every call. - **You set the threshold.** The API returns a probability, and OpenAI's guidance is to choose thresholds from your own labeled examples based on the cost of false positives and false negatives. That's the same discipline any AI defect detection project needs. - **Data controls exist, with conditions.** Zero Data Retention and HIPAA use are available for eligible customers, with US and EU data residency. Check eligibility before you assume it covers you. That makes computer vision for quality control in manufacturing much cheaper to try than it was. It doesn't remove the physics of a moving line. ### When is a cloud vision API good enough? A cloud API is a good fit when a few seconds of delay doesn't matter and a missed call isn't a safety or recall problem: - **Prototyping.** Testing whether a defect is even visible in a photo before buying cameras and lighting. - **Low-rate checks.** Incoming inspection at receiving, a sampled part every few minutes, end-of-shift audits, or photos a technician takes on a phone. - **Non-critical triage.** Flagging images for a human to review, sorting rework into categories, or scoring cosmetic severity. - **Documentation checks.** Confirming a label, a packaging state or a kit is complete before shipping, where a person still signs off. In these cases the per-image cost is small, there's no hardware to maintain, and model upgrades arrive without a project. That matches what we see with AI more broadly: frontier APIs are usually cheaper and good enough, and you should prove otherwise before building infrastructure. ### When does visual inspection automation need edge inference? Put the model on a smart camera or an industrial PC next to the line when any of these is true: 1. **The line runs at rate.** If parts pass the camera faster than a round trip to the cloud and back, or the reject gate is a short distance downstream, network latency and its variance decide whether the right part gets kicked. Edge inference keeps the timing local and predictable. 2. **The plant is air-gapped or poorly connected.** Many plants keep OT networks segmented from the internet on purpose, following guidance like [NIST SP 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) for OT security. A line that stops inspecting when the WAN drops isn't an inspection system. 3. **The result drives a PLC reject signal.** A pass/fail bit that fires an actuator needs deterministic timing and a defined fail-safe state. That belongs on local hardware wired into the control system. 4. **The images are sensitive.** Proprietary part geometry, customer-controlled designs or export-controlled work may not be allowed to leave the site, whatever the vendor's retention policy says. 5. **The volume is high and constant.** Every part, every shift, every camera adds up. At high, steady volume, owned edge hardware can cost less per inspection than calls to an API. Edge models are usually smaller and trained on your own defect images, running on hardware such as NVIDIA Jetson modules or an industrial PC with a GPU. They're narrower than a frontier model, but they only need to be good at one part on one line. **Need help piloting AI inspection on your line?** Axio Intelligence provides computer vision development services for manufacturing. We scope the pilot, collect and label the images, and build the model and integration on edge hardware or a cloud API, whichever fits. See our [edge AI and computer vision work](https://axiointelligence.com/services/edge-ai-computer-vision) or [book a scoping call](https://axiointelligence.com/book). ### What's the decision rule? Use this as a starting point: | Question | If yes | If no | | --- | --- | --- | | Does the result have to trigger a reject or stop within the line's cycle time? | Edge | Keep going | | Is the plant air-gapped, or does inspection have to keep working when the network is down? | Edge | Keep going | | Are the images not allowed to leave the site? | Edge (or a model in your own cloud account, if policy allows) | Keep going | | Is volume high and constant across many cameras? | Price both; edge often wins | Cloud API | Many plants end up with both: edge models on the lines that run at rate, and a cloud API for receiving, audits and the long tail of low-volume checks. The cloud model is also a useful second opinion when you're labeling new defect types. ### How should you pilot AI defect detection? Run a pilot before you commit to either path. Here's the plan we use: 1. **Pick one defect on one line.** Choose a defect that's costly when it escapes and visible to a trained inspector. 2. **Fix the imaging first.** Lighting, lens, mounting and part presentation matter more than the model. If a person can't see the defect reliably in the image, no model will. 3. **Collect sample images.** Capture good parts and every defect type you can find, across shifts, lots and material suppliers. Defects are rare, so plan time to gather enough of them. 4. **Label consistently.** Have your quality engineers agree on what counts as a defect and label against written criteria. Disagreements here become model errors later. 5. **Define success up front.** Measure **escape rate** (defective parts the system passes) and **false-reject rate** (good parts it rejects). Set targets with quality and production together, since one costs customers and the other costs scrap and line time. 6. **Run in shadow mode.** The system inspects and logs decisions but doesn't reject anything. Compare its calls with your current inspection for weeks, not days. 7. **Turn on rejects gradually.** Start with the highest-confidence calls, keep a human reviewing borderline parts, and widen as the numbers hold. The same pilot works whether the model runs in the cloud or on a camera, which is why we often prototype on an API and move to the edge only if the decision rule says so. ### What does integration with the PLC and MES involve? The model is usually the smallest part of the work. A production inspection system also needs: - **Triggering.** A part-present sensor or encoder signal so each image matches one part. - **PLC handoff.** A pass/fail result over the plant's protocol (for example EtherNet/IP, PROFINET or Modbus TCP), with timing tested against the reject gate and a defined behavior if the vision system faults. - **Reject actuators.** An air blast, pusher or diverter positioned so the flagged part is the one removed. - **MES and traceability.** Results tied to serial numbers or lots, with images retained for disputes and retraining. Many plants publish this through OPC UA or MQTT. - **Monitoring and retraining.** Tracking drift as materials, lighting or suppliers change, and a process for labeling new defects and redeploying models safely. This is where machine vision system integrators and computer vision development services earn their fee: getting the model, the controls and the plant data systems to agree on what happened to every part. ### What drives the cost? We won't quote numbers without seeing your line, but these are the drivers: - **Imaging hardware.** Cameras, lenses, lighting and mounts per inspection point. Lighting is often the deciding factor. - **Compute.** Per-call API fees for cloud, or smart cameras and industrial PCs for edge, plus spares. - **Data collection and labeling.** Usually the largest early cost, because good defect examples are rare. - **Integration.** PLC logic, reject mechanics, MES connections and line downtime for installation. - **Validation.** Shadow-mode time, and any customer or regulatory sign-off your industry requires. - **Ongoing support.** Retraining, monitoring and updates. Edge systems also need patching and hardware lifecycle planning. Compare all of that with your current cost of escapes, manual inspection labor and scrap. That gives you a business case built on your numbers. ### FAQ #### Can a cloud vision API replace machine vision on a production line? For low-rate, non-critical checks, often yes. For line-rate inspection that drives a reject signal, usually not, because network latency and outages make timing unpredictable. Edge inference handles those. #### What accuracy should AI visual inspection hit? Set targets for escape rate and false-reject rate with quality and production together, based on what an escape costs you versus a false reject. Measure both in shadow mode against your current inspection before turning on rejects. #### How many images do we need to train a defect detection model? It depends on how varied the parts and defects are. Collect good parts and every defect type across shifts and lots. A pilot quickly shows whether you have enough, and rare defects usually take the longest to gather. #### Is computer vision for quality control secure if images go to the cloud? Images sent to an API leave your network on every call. Some providers offer zero data retention and regional processing for eligible customers. If images can't leave the site or the plant is air-gapped, run the model at the edge. #### Should we hire a machine vision integrator or a computer vision development firm? If the job is a standard check that an off-the-shelf smart camera handles, a traditional integrator may be enough. If you need custom AI defect detection, a mix of edge and cloud, or integration with MES and data platforms, a team with software, data and controls experience fits better. ### When should you hire computer vision development services? Hire outside computer vision development services when the check needs a custom model, edge hardware wired into your controls, or a mix of edge and cloud that your team hasn't built before. We'll tell you if a cloud API is enough for your check, and often it is. When the line needs edge inference, we build the whole system: imaging, labeled data, the model on a camera or industrial PC, PLC and MES integration, and monitoring that keeps it accurate. If you're weighing visual inspection automation for a line, [book a call](https://axiointelligence.com/book) and we'll walk through it. ## On-Prem LLM vs Frontier API: When Self-Hosting Pays Off URL: https://axiointelligence.com/blog/on_prem_llm_vs_frontier_api Published: 2026-10-18 · Author: Brice Ayres · Tags: LLM, AI, on-premise, fine-tuning, private AI Short answer: For writing, coding and research, frontier models on enterprise seat plans or an API are usually cheaper and better than an on-premise LLM. Self-hosting a small fine-tuned open model pays off when data can't leave your network, for high-volume narrow tasks, at the edge or offline, or when a validated workflow needs a frozen model version. Check Amazon Bedrock, Azure OpenAI or Vertex AI in your own cloud account first. Every few weeks someone asks us whether they should run their own on premise LLM because the API bill keeps growing. Usually the honest answer is no. For general knowledge work like drafting, coding help, research and summarizing, frontier models are better than anything you can host yourself, and per-seat enterprise plans or plain API access cost less than a GPU cluster plus the people to run it. There is a real set of cases where a private LLM is the right call, though, and in those cases it can beat a frontier API on cost, latency and control. This guide covers both sides: when not to self-host, the four situations where it pays off, the costs people leave out of the spreadsheet, and what building one actually involves. ### Should most companies run an on premise LLM? No. If the goal is to give employees a capable assistant, buy seats or use an API. Here's why: - **Quality.** The frontier models are ahead of the open models you can fit on a single server, especially on long, open-ended work. - **Utilization.** Chat traffic is bursty. People use it during work hours and barely at all overnight. A GPU you own costs the same whether it's busy or idle, while an API charges only for what you use. - **Upgrades are free.** When a frontier lab ships a better model, you switch a model ID. When you self-host, every upgrade is a project. - **Privacy is often already handled.** Enterprise plans and cloud-hosted versions of frontier models come with contractual commitments not to train on your data. More on that below. So if the reason for self-hosting is "chat is getting expensive," look first at seat plans, usage caps, routing simple requests to a cheaper model and caching. Those usually fix the bill without buying hardware. ### Is there a middle option between a public API and on-prem? Yes, and it's the one we recommend checking first. All three big clouds sell frontier and open models that run inside your own cloud account, under the same contracts, logging and network controls as the rest of your infrastructure. - **Amazon Bedrock.** AWS says your inputs and outputs [are not shared with model providers](https://aws.amazon.com/bedrock/faqs/) and are not used to train base models. Models run in AWS-operated deployment accounts that the [model providers can't access](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html), and you can reach Bedrock over AWS PrivateLink without crossing the public internet. AWS lists Bedrock as HIPAA eligible and in scope for FedRAMP Moderate, and it's also available in [AWS GovCloud (US)](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-bedrock.html), where AWS publishes FedRAMP and DoD IL4/IL5 status model by model. - **Azure OpenAI and other models sold by Azure.** Microsoft says your prompts, completions and training data [are not available to OpenAI](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy) or other model providers and are not used to train foundation models without your permission. Standard deployments process data within the geography you choose (Global and DataZone deployments can process it more widely). Microsoft also offers these models in [Azure Government](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-gov). - **Google Cloud Vertex AI** (Google's docs now call it Gemini Enterprise Agent Platform). Google says it [won't use your data to train or fine-tune models](https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/zero-data-retention) without your permission, and documents how to reach zero data retention. For a lot of PII and HIPAA workloads, and for some government work, one of these clears the compliance review without anyone racking a GPU. Check the specific model and region against your requirements, because coverage varies by model. ### When does self-hosting an LLM actually make sense? In our experience it comes down to four situations. If none of them describes you, stay on an API. #### 1. The data can't leave your network Some data can't go to a cloud API, even one in your own tenancy: - **Air-gapped networks.** Classified enclaves, some OT networks and isolated labs have no route to a cloud at all. An air gapped LLM is the only kind that works there. - **CUI and ITAR work.** Defense primes and suppliers handling Controlled Unclassified Information have to meet [NIST SP 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final), and export-controlled technical data comes with its own rules. A government cloud region may satisfy those rules for some programs and not for others. When it doesn't, the model has to run on hardware you control. - **Some PII and health data.** When a contract, a regulator or your own risk team says the data stays in your data center, that settles it. #### 2. High-volume, narrow tasks inside a product or pipeline This is where self-hosting can win on cost and on speed. The task is the same thing millions of times: classify this transaction, extract these fields from this document, route this claim, label this ticket. A huge general-purpose model is overkill for that. A small open model fine-tuned on your own data can match or beat it, at lower latency, on hardware you can keep busy around the clock. Coinbase recently published a detailed example. In [Part 3 of its Owning Intelligence series](https://www.coinbase.com/blog/part-three-owning-intelligence-series) (Oct 8, 2026), its team post-trained Qwen3.5-9B, an open-weight model with nine billion parameters, on its proprietary fraud data for one narrow task: classifying transaction risk for Coinbase Onramp. They used reinforcement learning with rewards scored against known fraud outcomes and LoRA adapters, and trained on a single NVIDIA RTX PRO 6000 96GB GPU for a total cost of under $100. On Coinbase's own benchmark, the post-trained model beat Claude Opus 4.5 on all four detection metrics: 7.5 higher precision, 12.0 higher recall and 9.6 higher F1 (the post's chart labels these as percentage-point differences), plus 35.4 higher dollar-weighted recall. Served with vLLM and Ray Serve LLM on L40S GPUs, scaling between 2 and 8 replicas, its median end-to-end latency in production was 0.683 seconds against Opus 4.5's 1.515 seconds, and P99 was 1.036 seconds against 3.312. Three things in that write-up are worth noticing. The unadapted Qwen model performed poorly, so the gain came from training on Coinbase's data, not from the open model itself. Coinbase built a domain benchmark first. And Coinbase says owning the model means owning its lifecycle: fraud patterns change, so the model needs ongoing evaluation and retraining. The $100 figure covers the training run. It doesn't include the people, the dataset, the benchmark or the serving cluster. Even so, it shows how cheap fine-tuning has become for a well-defined task. #### 3. Edge and offline use Drones, vehicles, factory lines, pump stations and remote sites often have weak or no connectivity, tight latency budgets, or both. A model that has to call a cloud API can't run there. Small models running on edge hardware like NVIDIA Jetson can handle tasks like summarizing a maintenance log, reading a work order or interpreting sensor alarms on site. This is the same work we do in [edge AI and computer vision](https://axiointelligence.com/services/edge-ai-computer-vision): sizing the model to the compute and power you actually have. #### 4. A model that won't change under you Hosted models get retired on a schedule. Microsoft's Foundry [lifecycle policy](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirements) describes a standard 18-month lifecycle for generally available models, with models closed to new customers at 12 months. AWS says most Bedrock models get a [6-month Legacy period](https://docs.aws.amazon.com/bedrock/latest/userguide/model-lifecycle.html) before end of life, and some get 45 days. Google [lists retirement dates](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/model-versions) for its models, too. That's reasonable for most software. But if a model sits inside a validated workflow, such as a regulated process, a certified system or a pipeline with an audit trail, every forced upgrade means revalidating. With open weights you hosted yourself, the version you validated keeps running until you decide to change it. **Need help setting up a local LLM?** Axio Intelligence can help. We scope it, build it and run it, from the eval set and fine-tune to serving and monitoring. See our [data and AI platform work](https://axiointelligence.com/services/data-ai-platforms) or [book a scoping call](https://axiointelligence.com/book). ### What does self-hosting cost that people forget? The GPU invoice is the visible part. These are the costs that usually decide whether a private LLM is worth it: - **Idle capacity.** You pay for a GPU 24 hours a day. If it's busy for eight of them, your real cost per request is three times what the benchmark suggested. Pipelines that run all day fit this model well. Chat usually doesn't. - **Evals.** You need a test set that reflects your actual task and gets rerun on every model, prompt and data change. Without one, you can't tell whether the self-hosted model is good enough, or whether it got worse. - **Monitoring.** Track quality, latency, throughput and drift in production, with alerts and a tested rollback. - **Upgrades.** New open models come out constantly. Deciding whether to move, retraining adapters and revalidating all take engineering time. - **Security patching.** The serving stack, drivers, container images and model files all need patching and access controls like any other production system. - **People on call.** Someone has to answer when the inference server falls over at 2 a.m. If no one on your team owns that, you don't have a production system yet. #### A worked example (assumptions, not quotes) Here's how we frame the cost question with a client. The numbers below are made up to show the math. Plug in your own. - Assume a self-hosted setup costs **$20,000 a month** all-in: hardware amortized over three years, power, hosting, and a share of an engineer's time for operations. - Assume the API you'd use instead costs **$5 per million tokens**, blended across input and output. - Break-even is $20,000 ÷ $5 = **4,000 million tokens, or 4 billion tokens a month**. A 200-person team where each person uses 100,000 tokens per working day, over 22 working days, comes to 440 million tokens a month, about a ninth of break-even. That's why we tell most companies to stay on the API for chat. A document pipeline handling a million documents a month at 5,000 tokens each comes to 5 billion tokens, and now the self-hosted option deserves a closer look, especially if a smaller fine-tuned model needs fewer tokens per document than a frontier one. The real decision usually turns on quality, latency and data control, not cost alone. But if the volume isn't anywhere near break-even, cost won't be the reason to self-host. ### How do you decide? A quick checklist | Question | If yes | If no | | --- | --- | --- | | Is this general knowledge work (writing, coding, research, chat)? | Use seats or an API | Keep going | | Must the data stay off any cloud, including your own tenancy? | Self-host | Try Bedrock, Azure OpenAI or Vertex AI first | | Is it one narrow task run at high volume, all day? | A fine-tuned small model is worth testing | An API is probably cheaper | | Does it run where connectivity is unreliable or latency is tight? | Edge or on-prem model | API is fine | | Does a model change force revalidation of a regulated workflow? | Pin a self-hosted version | Hosted lifecycle is fine | | Do you have someone to own evals, monitoring and on-call? | You're ready | Plan for that before you build | If you answered yes to the first row and no to the rest, you don't need an on-prem model. ### What does building a private LLM involve? If you do need one, this is the order we work in. It's the same order whether you build it yourself, hire LLM developers, or bring in a team for custom AI model development. 1. **Build the eval set first.** Collect a few hundred to a few thousand real examples with correct answers, and score the frontier API against them. That score is the bar to beat, and it's what tells you whether the project is worth doing. 2. **Prepare the data.** Clean, label and version the training examples, and keep test examples out of training. Most of the work in any effort to fine-tune an LLM on your own data is here. 3. **Pick a base model and fine-tune.** Start with the smallest open model that might do the job, then use LoRA or a similar method to train it on your data. Read the model card from the publisher for license terms and intended use. 4. **Serve it.** Use an inference server such as vLLM on hardware sized to your traffic, with autoscaling if the load varies. For edge, that means quantizing and optimizing the model for the target device. 5. **Govern it.** Version the weights, prompts and decision logic together, log what the model does, and set a review process for changes. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a useful structure for this. 6. **Operate it.** Monitor quality and latency, retrain when the data shifts, and keep a rollback ready. Good LLM fine-tuning services spend most of their time on steps 1, 2 and 6. If a proposal is mostly about GPUs and model selection, ask where the eval set is. ### FAQ #### Is an on-premise LLM cheaper than using an API? For general chat and knowledge work, usually not, because owned GPUs sit idle much of the day and the frontier models are better. For a narrow task running at high volume, a small fine-tuned model on hardware you keep busy can cost less per request than an API. Do the math with your own volume. #### What's the difference between a private LLM and an air-gapped LLM? A private LLM runs where you control the data, which can be your own cloud account or your own data center. An air-gapped LLM runs on a network with no internet connection at all. Every air-gapped LLM is private, but most private deployments aren't air-gapped. #### Can Amazon Bedrock or Azure OpenAI meet HIPAA or government requirements? Often, yes. AWS lists Bedrock as HIPAA eligible and in scope for FedRAMP Moderate, and offers it in GovCloud with IL4/IL5 status published per model. Microsoft offers its models in Azure Government. Coverage varies by model and region, so check the exact model you plan to use. #### How much data do we need to fine-tune an LLM on our own data? It depends on the task. For a narrow classification or extraction task, a few thousand good examples is often a reasonable place to start, and the eval set tells you whether you need more. Quality and correct labels matter more than volume. #### Will a small open model be as good as a frontier model? On broad, open-ended work, generally not. On one narrow task with good training data, it can be. Coinbase's post-trained 9B model beat Claude Opus 4.5 on its fraud benchmark, while the same model without training performed poorly. #### Should we hire LLM developers or bring in an outside team? If you'll run several models for years, build an internal team. If you need one model built, validated and handed over, an outside team can get you there faster, as long as it leaves you with the eval set, the training pipeline and the documentation to run it. ### Where do we fit? We'll tell you honestly whether you need your own model. Often the answer is a cloud-hosted frontier model with the right contract and controls. When you do need one, we build it: the eval set, the [data pipeline](https://axiointelligence.com/services/data-ai-platforms), fine-tuning, serving on-prem or at the [edge](https://axiointelligence.com/services/edge-ai-computer-vision), and the monitoring to keep it accurate. If you're weighing an on-prem LLM, [book a call](https://axiointelligence.com/book) and we'll walk through your use case. ## AWS Mainframe Modernization Is Closed to New Customers. Here's What a Mainframe Exit Looks Like Now URL: https://axiointelligence.com/blog/aws_mainframe_modernization_closed_alternatives Published: 2026-10-16 · Author: Brice Ayres · Tags: mainframe, COBOL, AWS, modernization, legacy systems Short answer: As of July 30, 2026, the AWS Mainframe Modernization service is no longer open to new customers. Existing customers keep using it, with security updates but no new features. AWS points new projects to AWS Transform for mainframe and to vendor-direct offerings. The realistic paths are refactoring with AWS Transform and coding agents, replatforming with a rehosting vendor directly, a staged offload, or staying and cutting MIPS. In every path, a human team still owns business-rule sign-off, data cutover, parallel runs and proof of equivalence. If your mainframe plan was built on the AWS Mainframe Modernization service and you hadn't signed up yet, that door is closed. AWS stopped accepting new customers for the service on July 30, 2026. Existing customers can keep using it. For new projects, AWS points people to AWS Transform for mainframe and to offerings bought directly from the vendors that used to be packaged inside the service. The mainframe exit itself is still very doable. What changed is how you put it together. Instead of one AWS console bundling the replatform, data replication and runtime tools, you now assemble the pieces yourself: an AI-assisted refactoring toolchain, a rehosting vendor contracted directly, or a staged offload that keeps the mainframe running while work moves off it piece by piece. This guide is for CIOs and mainframe program leads at banks, insurers, airlines and state agencies who need to re-plan. ### What exactly did AWS change? On June 30, 2026, AWS published a list of services [moving to maintenance](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-service-availability/). AWS Mainframe Modernization – Self-Managed Experience was on it. AWS said services moving to maintenance would no longer be open to new customers starting July 30, 2026, and that customers already using them could continue. The service's [availability change page](https://docs.aws.amazon.com/m2/latest/userguide/mainframe-modernization-availability-change.html) covers both versions of the service: - **Self-managed experience.** No longer open to new customers. AWS lists the affected capabilities as Replatform with Rocket, Data Replication with Precisely, Replatform with NTT DATA, Assembler Conversion with mLogica, and SPARC Virtualization with Stromasys. AWS says it will not add new features but will keep providing security updates and service availability. For similar capabilities, it points to vendor-direct offerings and AWS Transform. - **Managed Runtime Environment experience.** Also closed to new customers. This was the managed version of the Rocket replatforming runtime. AWS says existing customers keep full support and that AWS ProServe can help them move to self-managed options. In short, what's gone is the ability for a new customer to start on the service. What isn't gone: the service itself for existing customers, the underlying vendors, and AWS Transform for mainframe. ### What does this mean if we were planning on it? It depends on where you were. - **Already running on the service.** You can keep going. AWS says it will keep the service available and patched so ongoing projects can finish. But no new features are coming, so plan for where the workload lives long term. We'd treat it as a place to finish the current project, not something to build the next ten years on. - **Mid-evaluation, not yet onboarded.** Your business case probably assumed AWS's bundled tooling and one bill. Redo it with the vendors contracted directly, or with the refactoring path, and recheck the timeline. - **Still deciding whether to leave the mainframe.** Not much changes. The decision was never about one AWS service. It comes down to cost, risk, skills and how tangled the applications are. ### What are the realistic paths now? #### Can we refactor with AWS Transform and coding agents? This is where AWS is putting its effort. On October 12, 2026, AWS [described a workflow](https://aws.amazon.com/blogs/migration-and-modernization/reimagine-mainframe-workloads-with-a-highly-automated-workflow-using-aws-transform-and-devin/) in which AWS Transform for mainframe reverse-engineers COBOL, PL/I and JCL into a catalog of business functions and extracted business rules. Each rule traces back to the source lines it came from, and the output is written as technology-agnostic requirements. A coding agent (Devin, in that post) then turns approved requirements into service specifications, a backlog, code, tests and migration scripts, with each change arriving as a pull request for the team to review. Two details in that post matter for planning. First, AWS says a business owner confirms the extracted requirements are the intended behavior before anything is built on them. Second, merges still need human review. So the tools can speed up the reading and the typing, but your people still have to make the decisions. AWS Transform can be driven from a web console, from an IDE, from a CLI or through MCP, and all of them [share the same workspace](https://aws.amazon.com/blogs/migration-and-modernization/when-to-use-what-a-guide-to-aws-transform-interfaces/). In practice, architects and approvers can work in the console while engineers stay in their editors. This path fits applications you want to redesign as cloud-native services, not just move. It's also where "cobol to java conversion using ai" ends up. We've written more on [what AI does and doesn't do in COBOL modernization](https://axiointelligence.com/blog/cobol_modernization_with_ai). #### Can we still replatform with the rehosting vendors? Yes. The vendors that used to sit inside the service, including Rocket, Precisely, NTT DATA, mLogica and Stromasys, still exist, and AWS's own guidance points to buying from them directly. Replatforming keeps most of the COBOL as is and runs it on an emulated mainframe environment in the cloud. It's usually the fastest way to get off the hardware or out of a data center contract, and it leaves the application logic for a later phase. The trade-off is that you now negotiate licensing, support and runtime operations with the vendor yourself, instead of through one AWS service. Get clear answers on who runs the runtime, who patches it, and how licensing scales. #### What about a staged offload? Many organizations don't need, or can't risk, a single cutover. A staged offload (the strangler pattern) moves pieces off one at a time: reporting and analytics first, then read-heavy inquiry functions, then batch jobs, then the transactional core. Data replication keeps the mainframe and the new platform in sync while both are live. This approach takes longer and means paying for two platforms for a while. In return, each step is small enough to test, reverse and explain to auditors. For a bank or a state agency with strict uptime and audit needs, that's often worth it. #### Should we just stay and optimize? Sometimes, yes. If the mainframe is stable and the main problem is cost, start by cutting the usage that drives your software bill: tuning peak workloads, moving batch jobs off peak, and offloading eligible work to specialty engines. IBM's [Tailored Fit Pricing](https://www.ibm.com/products/z/pricing) changes how that usage is metered. We cover the mechanics in [why your z/OS software bill follows the peak](https://axiointelligence.com/blog/zos_peak_software_cost). Staying put for three years while you build skills and clean up the code is a legitimate plan, as long as it's a decision and not a default. ### What still needs a human team, whatever tools we pick? No toolchain removes these, and they're usually where schedules slip: - **Business-rule sign-off.** Extracted rules tell you what the code does today. Someone in the business has to say whether that's what it should keep doing, including the odd rules nobody can explain. - **Data cutover.** EBCDIC to ASCII, packed decimal, VSAM and IMS structures, sort orders and date formats. Moving data correctly, and on schedule, is its own project. - **Parallel runs.** Running old and new side by side on real volumes, and comparing outputs line by line, is how you earn the right to turn the old one off. - **Proving equivalence.** Regulators, auditors and your own risk team will want evidence that interest calculations, claims rules or benefit determinations didn't change. Plan the test strategy before you write the code. - **Operations and batch.** JCL schedules, restart and recovery, month-end and year-end jobs. These rarely appear in demos and always appear in production. > The tool reads the code. A person still has to approve what the code is supposed to do. ### How should we scope and buy the engagement? #### Start with an assessment Before committing to a path, pay for a bounded assessment, typically a few weeks. It should produce an inventory of programs, copybooks, JCL, data stores and interfaces; a map of dependencies; a classification of each application by path (retire, keep, replatform, refactor); and a sequencing plan with the first wave defined. If someone proposes a fixed price for the whole migration before seeing the code, ask how they priced it. #### Questions to ask any firm - Which of these paths have you delivered, and what did you do when extracted rules were wrong? - How will you prove functional equivalence, and who signs off? - What's your data migration and reconciliation approach? - How long do you plan to run in parallel, and what are the exit criteria? - Who owns the code, tests and documentation at the end? - What does our team need to learn to run the new system without you? #### Red flags - A promise of automated conversion with little or no testing budget. - No business-side owner named for rule approval. - A cutover plan without a rollback plan. - Pricing that only covers code conversion and leaves out data, testing and operations. - A plan that depends on one tool or service with no fallback. As this change shows, that dependency can shift under you. ### FAQ #### Is AWS Mainframe Modernization being shut down? AWS hasn't announced a shutdown. It says the service is closed to new customers and will keep running, with security updates, for existing customers. No new features are planned. #### When did AWS Mainframe Modernization stop accepting new customers? AWS announced the change on June 30, 2026, and said new customers lost access starting July 30, 2026. #### What does AWS recommend instead? For self-managed capabilities, AWS points to vendor-direct offerings and AWS Transform. For the managed runtime, AWS points existing customers to the self-managed version and offers ProServe help with the move. #### Is AWS Blu Age still an option? AWS's own guidance for refactoring now centers on AWS Transform for mainframe, which AWS describes as the refactor capability. Ask AWS directly about the specific tooling and licensing your project would use. #### Can AI convert COBOL to Java on its own? AI can speed up reading legacy code, extracting rules and writing new code and tests. AWS's own workflow still has people approving requirements and reviewing every merge. Plan for that time. #### How long does a mainframe exit take? It depends on code size, data complexity, how tangled the applications are, and how much parallel running your risk team requires. An assessment is the honest way to get a number. ### Where do we fit? We help teams scope and run [mainframe migration](https://axiointelligence.com/services/mainframe-migration) work: the assessment, the path decision for each application, and the engineering that the tools don't cover, from data cutover to parallel runs. If AWS's change has left your plan with a gap, [book a call](https://axiointelligence.com/book) and we'll walk through where you are. ## Hiring an Industrial Automation Consultant: What a SCADA/PLC Integration Project Actually Involves URL: https://axiointelligence.com/blog/hiring_industrial_automation_consultant Published: 2026-10-15 · Author: Brice Ayres · Tags: automation, SCADA, PLC, industrial IoT, OT security Short answer: An industrial automation consultant helps you decide what to build before anyone writes ladder logic. A typical SCADA/PLC integration project runs through assessment, architecture, controls and SCADA work, OT/IT integration, cybersecurity, commissioning and support. Cost and schedule are driven by scope, site count, legacy equipment, downtime windows and security requirements. Ask for references, a written test plan and clear ownership of code and documentation. Most plants don't go looking for an industrial automation consultant because things are going well. A key controls engineer retired. The SCADA system runs on an operating system nobody can patch. Leadership wants line data in the cloud, and the security team wants to know what is actually talking to what. Or a new line, lift station or compressor site is coming and the in-house team is already full. Whatever the trigger, the next step is the same: figure out who to hire and what the project will really involve. We have been on the engineering side of these projects, and this guide is what we would want a plant manager or operations leader to know before signing a statement of work. ### Consultant, integrator or in-house team? These three overlap, and plenty of firms do more than one. The useful distinction is what you are buying. - **An industrial automation consultant** helps you decide what to build. They assess the current state, define the architecture, write the requirements, and often stay on as the owner's engineer to review the work. This is the right starting point when the problem is fuzzy, spans multiple sites, or touches IT, the cloud and security at the same time. - **A SCADA systems integrator or industrial automation integrator** builds and installs. They do PLC programming, panel work, HMI and SCADA screens, and commissioning, usually against a defined scope. If you already know exactly what you want, an integrator may be all you need. - **Your in-house team** owns the plant day to day. They know the process better than any outsider will. The best projects keep them in the loop from the start so they can run and maintain the result. Many engagements combine these. A consultant scopes the work and writes the specification, an integrator (or the same firm) builds it, and plant staff take it over. What matters is that someone is clearly accountable for the architecture, not just the code. ### What a SCADA/PLC integration project involves Every site is different, but most projects move through the same phases. Knowing them helps you judge whether a proposal is complete. #### 1. Assessment The first weeks are discovery. A good team walks the floor, inventories controllers, I/O, networks, HMIs, historians and servers, and reviews existing drawings and code backups. Expect gaps: undocumented changes, PLC programs that don't match what is running, and network diagrams that are years out of date. The output should be a written current-state report, a risk list (including unsupported hardware and software), and a prioritized set of recommendations. If a vendor wants to skip this step and go straight to a quote, be careful. #### 2. Architecture and requirements Next comes the target design: which controllers stay and which get replaced, how SCADA is structured (centralized, per site, or redundant), where historians and data live, how remote access works, and how the network is segmented. This is also where control narratives, alarm philosophy and tag naming standards get written down. Good scada systems integration starts with these documents. They are what let a second engineer, or a different firm five years from now, understand the system. #### 3. PLC and SCADA work This is the part most people picture: PLC programming services, HMI screens, SCADA configuration, alarm setup and historian tagging. On brownfield sites, much of the work is migration, converting old logic to a current platform while keeping the process behaving exactly as operators expect. Ask how code will be structured, versioned and backed up. Standardized, modular code is cheaper to maintain than one-off programs written differently at each site. #### 4. OT/IT integration Most projects today need plant data to leave the plant: for ERP and maintenance systems, dashboards, analytics or AI. OT/IT integration is where many projects go wrong, because it crosses team boundaries. Common patterns use [OPC UA](https://opcfoundation.org/about/opc-technologies/opc-ua/) to read structured data from controllers and MQTT to publish it outbound to a broker or cloud service, often through an edge gateway. We cover the tradeoffs in [OPC UA vs MQTT: plant data to the cloud without replacing PLCs](https://axiointelligence.com/blog/opc_ua_vs_mqtt). The key design principle is that data flows out through controlled paths, and nothing on the internet can reach into the control network directly. #### 5. Cybersecurity Security can't be bolted on at the end. The [ISA/IEC 62443](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards) series is the main framework for industrial automation and control system security, built around zones, conduits and security levels. [NIST SP 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) is the U.S. government guide to operational technology security, and [CISA's ICS resources](https://www.cisa.gov/topics/industrial-control-systems) publish advisories and recommended practices. In practice, this means network segmentation, secure remote access, account management, patching plans, backups and logging. Water systems, utilities and pipelines may also face sector-specific requirements, so make sure your consultant knows which apply to you. #### 6. Testing and commissioning Expect a factory acceptance test (FAT) before equipment ships and a site acceptance test (SAT) after installation, both against a written test plan. Cutover planning matters most on running plants: what runs in parallel, what the rollback plan is, and which downtime windows are available. #### 7. Handover and support The project isn't done until your team can run it. That means as-built drawings, commented code, backups, operator and maintenance training, and a clear support agreement. Agree up front who owns the source code and configuration files. The answer should be you. ### Timelines and cost drivers We won't give you a single number, because honest ones don't exist without an assessment. What we can tell you is what moves cost and schedule. - **Scope and site count.** One line at one plant is a different project from twenty remote sites. Repeatable standards lower the cost per site after the first few. - **Legacy equipment.** Obsolete PLCs, proprietary protocols and missing documentation add discovery and migration time. - **Downtime windows.** If the plant can only cut over during a two-week annual shutdown, the schedule bends around that. - **Hardware and licensing.** SCADA licensing models vary widely (by tag count, client count or server), and controller and network hardware lead times can stretch schedules. - **Security and compliance requirements.** Segmentation, remote access redesign and documentation for regulators add real work, and they are worth doing. - **Integration depth.** Connecting to ERP, maintenance systems or cloud analytics adds design and testing on both the OT and IT sides. If you are budgeting scada system cost, ask for a phased estimate: a fixed-price assessment first, then a firmer price for the build once the unknowns are known. As a rough shape, assessments are usually measured in weeks and builds in months, but your drivers decide where you land. ### How to choose an automation consulting services partner Questions worth asking any firm you are considering: 1. Have you worked on our controller platforms and our SCADA software? Can we talk to a reference with a similar process? 2. Who exactly will do the work, and will those people stay on the project? 3. How do you handle cybersecurity, and how does your design map to IEC 62443? 4. What does your test plan look like for FAT, SAT and cutover? 5. Who owns the code, configuration and documentation at the end? 6. Can you handle the OT/IT side, including edge, cloud and data, or will we need a second firm? 7. What does support look like after go-live? Red flags: - A firm quote with no site visit or assessment. - Proprietary code or locked programs you can't access. - No written test plan or rollback plan. - Security described only as "we'll put it behind a firewall." - A team that can't explain its design to your operators in plain language. If you are weighing whether to bring in outside help at all, we wrote about that decision in [staff augmentation vs. consulting](https://axiointelligence.com/blog/outside_engineering_team_iot_edge_ai_cloud). ### FAQ **What does an industrial automation consultant do?** They assess your current control systems, design the target architecture, write requirements, and oversee or perform the implementation, covering PLCs, SCADA, networks, data integration and security. **Is a manufacturing automation consultant different from a SCADA systems integrator?** Often the same firm does both. The difference is the role: a consultant defines what to build and why, while an integrator builds and commissions it. Make sure your contract is clear about which you are paying for. **How long does a SCADA upgrade take?** It depends on site count, legacy equipment and downtime windows. Plan for an assessment of a few weeks before anyone can give a reliable schedule for the build. **Do we need to replace our PLCs to get data into the cloud?** Usually not. Edge gateways can read existing controllers over OPC UA, Modbus or native drivers and publish data outbound securely. **Which standards should our project follow?** For security, ISA/IEC 62443 and NIST SP 800-82 are the main references. For data, OPC UA is the common interoperability standard. ### Working with Axio Intelligence Axio Intelligence is a veteran-led engineering firm in San Antonio. Through our [IoT product development](https://axiointelligence.com/services/iot-product-development) and [edge AI](https://axiointelligence.com/services/edge-ai-computer-vision) work, we help manufacturers, utilities, water systems and energy companies connect plant-floor systems to the rest of the business: industrial IoT, automation, edge AI and cloud. If you are planning a SCADA/PLC project and want an engineering team that can carry it from assessment through OT/IT integration, [we'd be glad to talk](https://axiointelligence.com/book). ## OPC UA vs MQTT: Plant Data to the Cloud Without Replacing PLCs URL: https://axiointelligence.com/blog/opc_ua_vs_mqtt Published: 2026-10-14 · Author: Brice Ayres · Tags: IoT, industrial IoT, OPC UA, MQTT, edge Short answer: OPC UA and MQTT aren't rivals. OPC UA describes what your machine data means; MQTT moves it efficiently through a broker. Most plants get to the cloud with an edge gateway that reads PLCs over OPC UA or Modbus, publishes outbound-only over MQTT with store-and-forward, and lands data in a Unified Namespace or a cloud service like AWS IoT SiteWise or Azure IoT Operations, without replacing the controllers. Most plants we walk into have the same problem. The controllers on the floor work, some of them for decades, and nobody wants to touch them. Meanwhile the business wants that data in the cloud for dashboards, maintenance planning and AI. The question that usually comes next is OPC UA vs MQTT: which one should we standardize on? It's the wrong question, but it's an understandable one. The two solve different problems, and the best architectures use both. Here's how we think about it when we design plant-floor connectivity for manufacturers, utilities and the controls integrators who serve them. ### What is OPC UA? [OPC UA](https://opcfoundation.org/about/opc-technologies/opc-ua/) is an industrial interoperability standard from the OPC Foundation. Its classic mode is client/server: an **OPC UA server** runs on or next to a PLC, and clients such as SCADA, historians or gateways browse it and read, write or subscribe to values. What makes the OPC UA protocol valuable isn't the transport. It's the information model. A tag isn't just a number at an address; it's a node with a type, engineering units, relationships and metadata, and companion specifications define standard models for whole classes of equipment. A client can discover what a machine is, not just what register 40001 holds. The tradeoffs: client/server is a point-to-point, poll-or-subscribe pattern that works best inside a plant network. Pointing cloud services directly at OPC UA servers on the floor means opening inbound paths to OT, which is exactly what you don't want. ### What is MQTT, and what does an MQTT broker do? [MQTT](https://mqtt.org/) is a lightweight publish/subscribe transport. Devices don't talk to each other; they publish messages to topics on an **MQTT broker** (also called an MQTT server), and anything interested subscribes. Publishers and consumers never need to know about each other. That decoupling is why MQTT dominates edge-to-cloud links. Connections are initiated outbound from the site, it tolerates flaky cellular and satellite links, and one published value can feed a historian, a cloud service and an analytics team at once. The catch is that plain MQTT says nothing about what the payload means. Topic names and JSON shapes are whatever someone decided, and across a few plants and integrators that turns into chaos. Common brokers include Eclipse [Mosquitto](https://mosquitto.org/documentation/) (the usual choice when people search for a small, open-source **mosquitto mqtt broker**), [EMQX](https://docs.emqx.com/en/) and [HiveMQ](https://docs.hivemq.com/hivemq-platform/index.html), which add clustering, enterprise authentication and management at scale. All three implement the standard; the choice comes down to scale, high availability, support model and how you operate it. ### OPC UA vs MQTT: when to use which | Need | Better fit | Why | |---|---|---| | Rich, self-describing machine data inside the plant | OPC UA client/server | Information models, browsing, standard equipment types | | Reading many PLCs from SCADA or a historian on the OT network | OPC UA client/server | Mature, widely supported by controllers and HMIs | | Moving data from many sites to the cloud | MQTT | Outbound connections, low bandwidth, one-to-many | | Unreliable links (cellular, satellite, remote assets) | MQTT | Session persistence, QoS, small overhead | | Standard semantics over a pub/sub transport | OPC UA PubSub over MQTT or Sparkplug B | Meaning plus decoupling | | Writing setpoints or commands to equipment | OPC UA (on-site), carefully gated | Typed methods, access control, stays inside OT | | Plant-wide event backbone shared by many apps | MQTT broker as a Unified Namespace | Single source of current state, consumers subscribe | The short version: OPC UA is the language, MQTT is the delivery route. Inside the fence, OPC UA client/server is usually right. Crossing the fence, MQTT is usually right. ### OPC UA PubSub over MQTT and Sparkplug B You don't have to choose between semantics and transport. Two approaches carry structure over MQTT. **OPC UA PubSub** is part of the [OPC UA specification](https://reference.opcfoundation.org/) and defines how OPC UA data, with its information model, is published over brokers including MQTT. It fits well when your equipment and software already speak OPC UA and you want to keep that richness end to end. **[Sparkplug B](https://sparkplug.eclipse.org/)** is an Eclipse Foundation specification that defines MQTT topic structure, payload encoding and state management, including birth and death messages so consumers know when an edge node or device goes offline. It's popular with SCADA-centric teams that want plug-and-play MQTT without designing their own conventions. We pick based on the systems already in place and who will maintain it. Mixing both is fine as long as each topic tree has one owner and one convention. ### Where Unified Namespace fits **Unified Namespace** (UNS) is an architecture pattern, not a product: an MQTT broker becomes the single place where the current state of the business is published, organized by a hierarchy such as enterprise, site, area, line and cell. ERP, MES, historians, dashboards and AI models subscribe instead of building point-to-point integrations with each PLC. A UNS succeeds or fails on governance: naming, payload conventions, who can publish where, and versioning. The broker is the easy part. If you're evaluating a UNS, spend your first weeks on the namespace design and access rules, not on broker benchmarks. ### The edge gateway pattern: keep your PLCs, add a gateway This is how most plants get data to the cloud without ripping anything out. An industrial IoT gateway sits at the boundary between the controls network and the outside world: - **Southbound**, it reads from what's already there: OPC UA servers, and legacy Modbus TCP, Modbus RTU and serial devices that will never speak OPC UA. Modbus to MQTT translation, with mapping into a proper model, happens here. - **Northbound**, it publishes over MQTT with TLS to a site or cloud broker. - **Outbound-only.** The gateway initiates every connection. No inbound firewall ports into OT, no VPN from the cloud into the plant. - **Store-and-forward.** When the WAN drops, the gateway buffers locally and replays in order once the link returns, so you don't get gaps in the historian. - **Read-only by default.** Writes to equipment are a separate, deliberately designed path with its own approvals, if they exist at all. The OPC Foundation's timing here is useful. In September 2026 it [released an open-source Cloud Initiative Reference Solution](https://opcconnect.opcfoundation.org/2026/09/cloud-corner-september-2026/) under the MIT license. It turns the Foundation's cloud reference architecture into a deployable stack that combines OPC UA Client/Server, OPC UA PubSub, MQTT and REST, with components such as UA Edge Translator for connecting devices that don't natively support OPC UA and UA Cloud Publisher for data transport. The Foundation says it can run on standard Linux systems, industrial PCs or low-cost industrial edge gateways. It's a good, vendor-neutral starting point for prototyping exactly this pattern. Separately, on Sept. 30 the OPC Foundation and Avnu Alliance [announced a collaboration](https://opcfoundation.org/news/press-releases/opc-foundation-and-avnu-collaborate-to-advance-tsn-in-industrial-automation-through-testing-certification-and-interoperability/) on testing and certification of OPC UA FX over Time-Sensitive Networking. That's about deterministic communication at the field level rather than cloud links, but it's another sign that OPC UA is extending from the controller down to the network, while MQTT carries data out of the plant. ### Security: certificates, no inbound ports, and the new NIST draft Connecting OT to the cloud is a security architecture decision first. The baseline we design to: - **Mutual TLS with per-device certificates** for every gateway-to-broker connection, plus OPC UA's own application certificates and signed, encrypted sessions on the plant side. No shared passwords baked into images. - **No inbound ports into OT.** Gateways sit in a DMZ or conduit and dial out. - **Least-privilege topic access.** Each gateway can publish only to its own branch of the namespace and subscribe to nothing it doesn't need. - **Zones and conduits** as described in [ISA/IEC 62443](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards), so the gateway is a defined, monitored crossing point. - **Certificate lifecycle** planned up front: issuance, rotation and revocation across hundreds of devices. NIST published the initial public draft of [SP 800-82 Rev. 4, Guide to Operational Technology Security](https://csrc.nist.gov/pubs/sp/800/82/r4/ipd), on Sept. 21, 2026, with comments due Nov. 30, 2026. The revision expands its coverage to include IIoT and cloud convergence, restructures around the NIST Cybersecurity Framework 2.0, and adds security architecture guidance focused on protecting system management functions and applying zero trust principles. If you're designing an edge-to-cloud path now, it's worth reading the draft alongside 62443, and commenting if your environment isn't well represented. ### Landing the data in the cloud Once data flows over MQTT, the cloud side is about modeling and storage, not protocols. - [AWS IoT SiteWise](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/what-is-sitewise.html) collects, organizes and models industrial equipment data at scale, with asset models that map well to an OPC UA or UNS hierarchy. - [Azure IoT Operations](https://learn.microsoft.com/en-us/azure/iot-operations/overview-iot-operations) runs at the edge on Kubernetes with an MQTT broker and OPC UA connectivity, then sends data to Azure services. Whichever you choose, keep your namespace and models portable. If your topic tree and asset models are your own, switching clouds or adding a second one is a data pipeline change, not a re-instrumenting project. ### How we'd approach it When a plant or integrator brings us in, we typically start with a short assessment: inventory the controllers and protocols, decide where OPC UA, Sparkplug B or plain MQTT fits, design the namespace, and stand up one line or one site with an outbound-only gateway, store-and-forward and certificate-based security. Then we scale it out. That's the core of our [IoT product development](https://axiointelligence.com/services/iot-product-development) work. For remote assets on cellular or satellite links, see our [connectivity practice](https://axiointelligence.com/services/cellular-satellite-connectivity) and our post on [same-SIM satellite IoT](https://axiointelligence.com/blog/satellite_iot_same_sim). If the goal is vision or AI at the line, our [edge AI and computer vision](https://axiointelligence.com/services/edge-ai-computer-vision) team works from the same gateway foundation. When you'd rather bring in a specialist team than staff up, we wrote about [when that makes sense](https://axiointelligence.com/blog/outside_engineering_team_iot_edge_ai_cloud). > Keep the PLCs. Add a gateway. Let OPC UA describe the data and MQTT move it. If you're working out how to get plant-floor data into the cloud, [book a call](https://axiointelligence.com/book) and we'll walk through your controllers, network and goals. ## Staff augmentation vs. consulting: when to bring in an outside engineering team URL: https://axiointelligence.com/blog/outside_engineering_team_iot_edge_ai_cloud Published: 2026-10-13 · Author: Brice Ayres · Tags: staff augmentation, IoT integration services, edge AI, cloud cost optimization, defense Short answer: Bring in outside engineers when the problem is specialized, time-boxed or stuck, not when you need permanent capacity. Use staff augmentation when you can direct the work, a project team when you need someone to own an outcome, and fractional leadership when nobody can say what the next step should be. In defense work, ask about US persons, ITAR handling, ATO evidence and handoff before you ask about rates. Most of the people who call us aren't short on smart engineers. They're short on one specific kind of engineer, for one specific stretch of time, on a project that has a date attached to it. That's the honest test for outside help. If the gap is permanent, hire. If it's specialized, time-boxed or stuck, an outside team usually costs less than the months it takes to recruit for a skill you'll need for two quarters. This post is the framework we'd use if we were sitting on your side of the table: at a prime, an integrator or a larger company with an IoT rollout, an edge AI effort or a cloud bill that isn't going the way the plan said. ### Signals you need outside help - **The project has stalled on one hard problem.** The rest of the team is fine, but everything waits on the modem firmware, the model that won't fit on the device, or the one engineer who understands the Terraform. - **The skill is narrow and you need it for months, not years.** Cellular and satellite connectivity, on-device inference and cloud cost work all fall here. They're deep specialties, and most teams need them in bursts. - **The date won't move.** A demo, a test event or a contract milestone is fixed, and recruiting won't land someone in time. - **Your leads disagree about the fix.** When two senior people have incompatible theories, adding hands just picks a side by accident. An outside read settles it faster. - **Nobody owns the bill.** Cloud spend keeps climbing because cost isn't anyone's job. ### Signals you should keep it in-house - The work is your core product and will be for years. Build that knowledge on your payroll. - You need steady capacity, not expertise. If the backlog is well understood and endless, hire. - You can't give an outside team a decision-maker. Without someone on your side who can approve trade-offs, any outside team burns time waiting. Outside help shouldn't replace your team. The goal is to get a stuck project moving and leave your people stronger than they were. ### Staff augmentation vs. consulting vs. a project team Buyers search for staff augmentation vs. consulting all the time, and the honest answer is that they solve different problems. Augmentation adds people you direct, consulting buys judgment and a plan, and project delivery buys an outcome someone else owns. Here's how we'd map that onto engineering work: - **Staff augmentation.** You have a clear backlog and a lead who can review the work. You need one or two specialists to slot into your sprints. You keep control, and the knowledge stays with your team. - **Project team (fixed scope).** You can describe the result, such as "devices report reliably over cellular with satellite fallback" or "cut the monthly bill and keep it down," but you don't want to manage how it gets done. The outside team owns delivery against acceptance criteria. - **Fractional leadership.** Nobody can say with confidence what the next step is, or the step is expensive enough that you want a senior outside view first. This is where a [fractional CTO](https://axiointelligence.com/services/fractional-cto) fits: a short, bounded engagement that ends with a decision and a plan your team can carry out. Many good engagements use all three in order. A short assessment defines the work, a project team builds the hard part, and one or two engineers stay on in an augmented role while your team takes over. ### Three scenarios we see often **IoT connectivity that works in the lab and fails in the field.** Devices drop off the network, data arrives late, and nobody can say whether it's the carrier, the antenna, the firmware or the backend. This is a classic case for a small project team with connectivity experience, because the fix crosses hardware, radio and cloud. It's the work behind our [IoT product development](https://axiointelligence.com/services/iot-product-development) and [cellular and satellite connectivity](https://axiointelligence.com/services/cellular-satellite-connectivity) services, and we wrote up the current state of [same-SIM satellite IoT](https://axiointelligence.com/blog/satellite_iot_same_sim) for teams planning a fallback path. **Edge AI on drones or in disconnected environments.** The model performs well on a workstation, then it has to run on a small, power-limited device with no reliable link. That means quantization, picking the right accelerator, deciding what runs on the device and what waits for a sync, and testing it all in conditions close to the real ones. Your data scientists know the model. An outside edge team knows how to make it run on the hardware. See [edge AI and computer vision](https://axiointelligence.com/services/edge-ai-computer-vision) and our [defense and dual-use](https://axiointelligence.com/industries/defense-dual-use) page. **A cloud bill that keeps growing.** This one is usually a fixed-scope job: find the waste, fix the biggest items, and put guardrails in place so it doesn't come back. The FinOps Foundation's framework treats cloud cost as a shared practice across engineering, finance and the business, not a one-time cleanup ([FinOps Framework](https://www.finops.org/framework/)). That's why the handoff matters as much as the savings. We describe our approach in [how we find waste in a cloud bill](https://axiointelligence.com/blog/quietly_cutting_cloud_bills) and on the [cloud cost reduction](https://axiointelligence.com/services/cloud-cost-reduction) page. If the real problem is infrastructure nobody can safely change, start with [infrastructure-as-code that survives the team](https://axiointelligence.com/blog/iac_that_survives_the_team). ### What to ask an outside engineering partner Rates matter, but in defense and regulated work they're rarely what sinks an engagement. Ask these first: 1. **Who exactly will do the work, and are they US persons?** Under ITAR, access to technical data generally depends on US-person status, which the regulations define ([22 CFR 120.62](https://www.ecfr.gov/current/title-22/chapter-I/subchapter-M/part-120/subpart-C/section-120.62)). Ask about clearances too, if your program needs them. 2. **How do you handle controlled data?** Ask where code and data will live, what systems the partner will touch, and whether they'll work inside your environment. 3. **Will your work produce ATO evidence?** If the system needs an authority to operate, the architecture diagrams, scan results and configuration records should come out of the work as it happens, not get written afterward. 4. **What does handoff look like?** Ask for documentation, runbooks, infrastructure as code and paired sessions with your engineers. If the partner can't describe the exit, you're buying a dependency. 5. **Can you fix the scope?** For a project team, ask for acceptance criteria and a price tied to them. For augmentation, ask how fast someone can start and how replacements work. 6. **Have you done this specific thing before?** Ask about IoT connectivity, edge inference or cost work specifically, not general software work. ### Where we fit We're a small, senior team in San Antonio. Brice Ayres, our founder, is an Army veteran who previously ran a telecom company that gave deployed troops more than a million minutes of talk time. Connectivity in hard places is where we started. Today we take on IoT connectivity and integrations, edge AI apps, drone and autonomy integration, automation, cloud cost reduction, mainframe modernization and fractional CTO work for primes, integrators and larger companies. We usually come in when a project is stuck or a team is stretched, solve the hard part, and hand it back documented. If you have a project that fits one of these scenarios, [book a call](https://axiointelligence.com/book). We'll tell you honestly whether you need us, another kind of partner, or a new hire. ## Army NGC2 is buying commercial apps: how a small software shop plugs in URL: https://axiointelligence.com/blog/army_ngc2_commercial_apps Published: 2026-10-12 · Author: Brice Ayres · Tags: defense, NGC2, Army, acquisition, San Antonio Short answer: On Oct. 7 the Army awarded about $93.6 million in first-year Next Generation Command and Control (NGC2) application contracts to nine commercial vendors, on top of the Anduril, Palantir, Raft and Striveworks data layer. More apps will come through the NGC2 Commercial Solutions Opening (CSO), a fixed-price, commercial buying route that is different from an Other Transaction. For a small software shop, the realistic entry points are teaming with an awarded vendor, integration and data work against the common data layer, and building authorization evidence early. The Army's biggest software story this fall isn't a new weapon. It's an app store, more or less. On Oct. 7 the Army announced its first round of [Next Generation Command and Control (NGC2) application awards](https://www.army.mil/article-amp/295991/new_contract_awards_support_army_next_generation_command_and_control_software_delivery_to_i_corps), and it said plainly that more would follow through an open solicitation. With the AUSA annual meeting running Oct. 12–14 in Washington, NGC2 is the program a lot of software people are talking about this week. We're a small software firm in San Antonio, and we've been asked the same question several times already: can a shop like ours actually get into this? Here's what was awarded, how the buying works, and where we think smaller teams realistically fit. ### What the Army actually awarded According to the Army, commercial applications were "evaluated and awarded" to nine vendors: General Dynamics Mission Systems, Air Space Intelligence Federal, Immersive Wisdom, LMI, Mente Systems, Stilman Advanced Strategies, Onebrief, Rune Technologies and AIR. The initial collective one-year value is about $93.6 million. Those apps sit on top of work already underway. The same announcement says the awards "add to the software capabilities provided by Anduril, Palantir, Raft and Striveworks for the NGC2 data layer and core artificial intelligence capabilities." Together, the Army says, the ecosystem covers six warfighting functions: C2, Fires, Intelligence, Movement/Maneuver, Sustainment and Protection. The software has been through real use. It was prototyped with the 4th and 25th Infantry Divisions, used across a division formation at Project Convergence Capstone 6 in July, and I Corps is next in line to receive it. Separately, on Oct. 12, AIR (the company styles itself Air) [announced a $200 million, five-year contract](https://www.prnewswire.com/news-releases/department-of-war-awards-air-200-million-contract-supporting-army-next-generation-command-and-control-302905180.html) supporting NGC2, focused on sustainment and readiness. That's a company press release, so treat it as the vendor's description rather than an Army statement. ### The line that matters for everyone else The most important sentence in the Army's announcement isn't about the nine winners. It's this: > The Army will continue to evaluate and award commercial technologies via the NGC2 Commercial Solutions Opening (CSO), aligned with NGC2's approach to deliver affordable capability at the pace of relevance. Brig. Gen. Shane Taylor added that the Army is "providing a blueprint and reference point for how industry can integrate in the future with interoperability and speed." In other words, the door didn't close on Oct. 7. The Army built a common data layer and is now buying apps that plug into it, on a rolling basis. ### Commercial Solutions Opening vs OTA People mix these up constantly, so here's the short version. A **Commercial Solutions Opening** is authorized by [10 U.S.C. 3458](https://uscode.house.gov/view.xhtml?req=(title:10%20section:3458%20edition:prelim)) and implemented in [DFARS Subpart 212.70](https://www.acquisition.gov/dfars/subpart-212.70-defense-commercial-solutions-opening). The government publishes a general solicitation describing a problem area, companies send in proposals (often a short white paper or pitch first), and the government reviews them by peer, technical or operational review instead of a traditional side-by-side source selection. Key points: - Awards must be **fixed-price** (including fixed-price incentive). - What you're selling is **treated as commercial**, which brings lighter FAR Part 12 terms. - The process counts as competitive, and the statute allows **follow-on production**, including sole-source follow-ons subject to approvals. An **Other Transaction** (OT), most often a prototype OT under [10 U.S.C. 4022](https://uscode.house.gov/view.xhtml?req=(title:10%20section:4022%20edition:prelim)), isn't a FAR contract at all. It's a flexible agreement for prototyping, and if the prototype was competitively awarded and successfully completed, it can lead to a follow-on production award without recompeting. The two aren't rivals. As MITRE's [Acquiring Commercial Solutions guide](https://aida.mitre.org/acquiring-commercial/) notes, a CSO can itself be used to award FAR contracts or prototype OTs. The practical difference for a vendor: a CSO wants a commercial product with a price, and an OT wants a prototype project. NGC2's app round is shopping for the first. ### Where a small software shop fits Being honest: a five- or ten-person firm is unlikely to win a standalone NGC2 app award next quarter. Those went to companies that already had fielded products and had been through the division-level prototyping. But an ecosystem like this creates a lot of work around the apps, and that's where smaller teams fit. **Teaming with an awarded vendor.** Nine app vendors and four data-layer companies now have to deliver to I Corps on a one-year clock. Some will need extra hands for integration, testing, deployment and training support. That's classic subcontract work, and we covered the mechanics in [how to become a software subcontractor for defense primes](https://axiointelligence.com/blog/defense_software_subcontracting). **Integration against the data layer.** The whole point of NGC2 is a common data layer that many apps share. Every app, and every future CSO entrant, needs connectors, data mapping, message translation and test harnesses against that layer. If your team is good at plumbing (APIs, event streams, schemas, edge sync over bad networks), that's a direct fit. **Data standards and interoperability.** "Modular, open architecture" only works if the data contracts are disciplined. Shops that can write and enforce schemas, versioning and conformance tests are useful to everyone in the ecosystem. **Authorization evidence.** No app runs on an Army network without an Authority to Operate. Software Fast Track (SWFT) and continuous ATO are pushing toward automated, machine-readable security evidence: SBOMs, pipeline scans, signed builds. We wrote about that in [faster ATO for small vendors](https://axiointelligence.com/blog/swft_cato_fedramp_20x). A vendor that shows up with that evidence already flowing is easier to buy and easier to team with. **A narrow app of your own.** If you do have a real product in one of the six functions, especially a sustainment, logistics or planning niche, the CSO is the route to watch. Expect to show it working, priced fixed, and integrated with the data layer. ### How to get ready this quarter If NGC2 is on your list, here's what we'd do now: 1. **Get registered.** Active SAM.gov registration and a UEI. Nobody can pay you without them. 2. **Read the NGC2 CSO and its areas of interest** when you find the current posting, and note how submissions are made (white paper, demo, pitch). 3. **Map yourself to one function and one layer.** "We do C2 software" is too vague. "We build sustainment data connectors to the common data layer" is a pitch. 4. **Pick two or three of the awarded vendors** whose products sit near your skills, and reach out about integration or delivery support. 5. **Build your security evidence now**, not after someone asks. SBOMs, CI scanning and a written system boundary go a long way. 6. **Price it as a product.** CSO awards are fixed-price, so know what a deployment, a license or an integration costs before the conversation starts. ### The San Antonio angle San Antonio is a military city with a fast-growing defense tech scene, and a lot of the I-35 corridor's defense software work looks exactly like this: integration, data and secure delivery around larger platforms. We wrote about that cluster in [the I-35 defense corridor](https://axiointelligence.com/blog/i35_defense_corridor). NGC2 is a good example of why. The headline awards go to a few companies, but the work of making an ecosystem actually function spreads much wider. ### Where we can help We work with [defense and dual-use teams](https://axiointelligence.com/industries/defense-dual-use) on integration, data platforms and secure delivery pipelines, and as a [fractional CTO](https://axiointelligence.com/services/fractional-cto) for startups figuring out how to position a product for programs like NGC2. If you're sizing up the NGC2 Commercial Solutions Opening or looking for an integration partner, [book a call](https://axiointelligence.com/book) and we'll tell you honestly whether it's a fit. ## DHH's Campfire shootout, part 2: the Elixir port played by different rules URL: https://axiointelligence.com/blog/dhh_campfire_shootout_part_2 Published: 2026-10-11 · Author: Brice Ayres · Tags: Elixir, Rust, benchmarks, AI coding agents Short answer: The Campfire ports weren't held to one set of rules. Rust's instructions let it diverge from Rails and it replaced Redis, Resque and Thruster with in-process code, while Elixir's instructions say to preserve the pinned Rails behavior, its benchmark runner requires a drained Redis queue, and a PR that removed Redis was closed partly for that reason. DHH's stated reasons, durable jobs and compatibility with existing installs, are reasonable on their own, but they weren't applied to every port. A fair benchmark needs one rulebook for all of them. In [part 1](https://axiointelligence.com/blog/dhh_campfire_shootout) we laid out DHH's argument: AI agents ported 37signals' Campfire chat app from Rails to Rust, Go and Elixir, Rust came out fastest, and if agents write the code, languages they can't write well out of the box will struggle. Then we looked at [the effort gap between the ports](https://axiointelligence.com/blog/fair_language_benchmark) and [what a reliability test showed](https://axiointelligence.com/blog/fast_isnt_reliable). Since then, more ports have arrived (Express, Laravel, Django and C), and DHH has moved the benchmarking into a [shared verification repo](https://github.com/basecamp/once-campfire-verification). This morning, José Valim, Elixir's creator, posted what he found when he asked why PRs speeding up Elixir were being turned down while similar ones were accepted elsewhere. We went through the repos ourselves to check. The short version: he's right, and the evidence is in the repos. ### What José said From his [post this morning](https://x.com/josevalim/status/2109281857128796472): > It turns out that, not only each project had a different starting point and a different prompt, but also each project also has a different set of verifications that they are required to pass! > For example, Elixir is the only guided to 'preserve the pinned Rails reference behaviour', the only with a explicit verification that we are using Redis and draining its queue (so we cannot remove it while others can), and the only one actively enforcing it. He linked [a write-up his agent produced](https://gist.github.com/josevalim/aecb6a602673a5dde173dd825346f749). We didn't take it on faith. Everything below we checked directly in the repos. ### What the repos actually say Each port has an `AGENTS.md` file: the standing instructions the coding agents follow. **Rust** ([AGENTS.md](https://github.com/basecamp/once-campfire-rust/blob/main/AGENTS.md)): parity with Rails "is done," and "The app may now diverge from Rails where that makes it faster or better." Its [README](https://github.com/basecamp/once-campfire-rust/blob/main/README.md) says "One `campfire` executable replaces Ruby, Puma, Redis, Resque and Thruster," and that Redis and Resque "are replaced by in-process queues." It's upfront about the cost: "Queued pushes and webhooks are lost on a crash." **Go** ([AGENTS.md](https://github.com/basecamp/once-campfire-go/blob/main/AGENTS.md)): a "Port of the Rust Campfire," told to preserve "the behavior of the Rust app," not Rails. Its README: "As in Rust, background queues are bounded and in-process," and "a process crash can lose queued jobs." **Express** ([AGENTS.md](https://github.com/basecamp/once-campfire-express/blob/main/AGENTS.md)): reads the Rails reference for behavior and preserves the schema, storage and cookie signing. Jobs run on "A separate leased SQLite queue," per its README. **Elixir** ([AGENTS.md](https://github.com/basecamp/once-campfire-elixir/blob/main/AGENTS.md)): "Preserve the pinned Rails reference behavior, SQLite schema, storage layout, signed/encrypted cookies, frontend, and Action Cable protocol." And the Elixir benchmark runner enforces it. In [`bench/run`](https://github.com/basecamp/once-campfire-elixir/blob/main/bench/run), after each sample, the Elixir app must report a Redis/Resque backend with a drained queue, or the run fails: ```python if app in {"reference", "baseline", "elixir", "candidate"}: assert jobs.get("backend") == "redis_resque" and jobs.get("drained") is True, jobs ``` The same runner also refuses to benchmark at all unless Elixir's parity ledger is complete, every contract is marked `verified`, and the last full verification ran on the exact current source (`bench/validate.py`). We didn't find an equivalent pre-benchmark gate in the other ports. ### The comparison | | Rust | Go | Express | Elixir | |---|---|---|---|---| | Behavior baseline | Rails, but "may now diverge" | The Rust port | Rails reference | "Preserve the pinned Rails reference behavior" | | Redis / Resque | Replaced, in-process | Replaced, in-process | Replaced, leased SQLite | Required; drain checked by runner | | Thruster | Replaced | Not stated | Replaced by a Thruster-style in-memory cache | Kept in the original port | | Jobs lost on crash? | Yes, documented | Yes, documented | No (durable queue) | No (Redis) | | Pre-benchmark parity gate | None found | None found | None found | Required | | PRs merged / total | 42 / 47 | 2 / 11 | 1 / 4 | 1 / 13 | | Commits on main | ~437 | ~40 | ~43 | ~45 | PR and commit counts are from the GitHub API as of this morning. The Rust repo is also where DHH did most of his own tuning, so its PR count mostly reflects his work, not outside contributions. ### DHH's stated reasons To be fair, the closed Elixir PRs weren't waved away. The reviews posted on them are specific and technical. On [Zach Daniel's PR](https://github.com/basecamp/once-campfire-elixir/pull/1), the review said the rewrite "removes the durable Redis/Resque job path and live Rails interoperability that existing installs depend on," and that a narrower PR, #4, was merged instead. On [PR #2](https://github.com/basecamp/once-campfire-elixir/pull/2), [PR #5](https://github.com/basecamp/once-campfire-elixir/pull/5) and [PR #7](https://github.com/basecamp/once-campfire-elixir/pull/7), the reviews found real cache-invalidation problems, and on #2 and #7 the authors agreed. On PR #7, the author wrote: "Agreed on all three points." Several reviews also note that the claimed speedups "were not independently reproduced." DHH's public line has been consistent: "Happy to take any improvements that actually hold up to verification!" ([post](https://x.com/dhh/status/2108282279240036707)). And the Elixir port did get faster. The latest [performance review](https://github.com/basecamp/once-campfire-verification/blob/main/docs/performance-review.md) shows its room page at 5,350 requests per second, ahead of Rails at 4,101. Durable jobs and compatibility with existing installs are good reasons to turn down a change. We'd make the same call on a client project. ### Where the rules don't line up The problem isn't any single review. It's that the same reasons weren't applied to every port. - **Durable jobs.** Zach's PR was turned down partly for removing "the durable Redis/Resque job path." Rust and Go have no durable job path, and their own READMEs say queued jobs are lost on a crash. That was accepted for them. - **Rails interoperability.** Rust's instructions say it "may now diverge from Rails where that makes it faster or better." Elixir's say "Preserve the pinned Rails reference behavior." - **Who replied to Zach.** On his closed PR, Zach answered: "I modeled it after the rust implementation which also does not do those things by my understanding." Based on Rust's own README, his understanding was correct. - **The gate.** Only Elixir has a runner that requires Redis and blocks benchmarking until a full parity run passes on the exact source. None of this requires bad intent to explain. Each port was set up at a different time, with a different prompt and different instructions to its agent, and those instructions then judged incoming PRs. José makes the same point: "each project had a different starting point and a different prompt." The result is still a table where Elixir runs a heavier architecture under stricter rules, sitting next to ports that were allowed to drop that architecture. The headline numbers make the cost visible: in the latest table, Express serves the room page at 42,636 requests per second and Elixir at 5,350. Some of that gap may be Elixir. But Express is allowed an in-process cache and no Redis, and Elixir's runner requires Redis. Until the rules match, we can't tell how much. ### What a fair benchmark needs We said this in [the effort post](https://axiointelligence.com/blog/fair_language_benchmark), and it applies even more now: 1. **One rulebook.** Either every port must preserve Rails' Redis/Resque architecture, or every port may replace it. Not some of each. 2. **One set of checks.** If a parity gate or a job-drain check is required for one port, require it for all of them, through the shared runner. 3. **Published instructions.** The `AGENTS.md` for each port is part of the benchmark and belongs next to the results. 4. **Same-session reruns.** The current review notes that Elixir, Go, Rust and C "retain exactly their independently verified figures from the previous published comparison" and weren't rerun. Rerun everything together. DHH's underlying question, which languages agents write well out of the box, is still a good one. Answering it takes the same rules for every language. If you're running your own comparison of stacks or vendors, [we can help set it up fairly](https://axiointelligence.com/book). ## Build vs. buy has flipped: when custom AI-built tools beat SaaS URL: https://axiointelligence.com/blog/build_vs_buy_has_flipped Published: 2026-10-11 · Author: Brice Ayres · Tags: build vs buy, AI coding agents, fractional CTO, SaaS Short answer: Agentic coding tools cut the cost of building small internal tools from weeks to days, and McKinsey's 2026 survey finds 32% of organizations have already skipped at least one software purchase because they could build it. Build when the workflow is yours, the scope is small and you're paying for glue or per-seat sprawl. Buy anything regulated, security-critical or full of edge cases. Either way, someone technical has to own what you build. For years the build-vs-buy answer for a small company was boring: buy. Unless the software *was* your product, writing your own CRM, scheduler, or reporting dashboard was a great way to burn six months and end up with something worse than a $49/month tool. That math has changed, and not just for us. McKinsey's *State of AI in 2026* survey found that **32% of respondents say their organizations decided against buying at least one software product or feature because they could build it in-house with agentic coding tools**. In tech it's 41%. Healthcare is 39%. Professional services is 38%. ([McKinsey, The state of AI in 2026](https://beszerzes.hu/wp-content/uploads/2026/09/The-state-of-AI-in-2026-On-the-road-to-ROI-.pdf)) That's a third of companies saying "we'll build that ourselves." It lines up with what we're seeing with clients. ### What actually changed Coding agents didn't make software engineering free. They made the *first 80%* dramatically cheaper. A focused internal tool (an intake form that writes to your database, a dashboard that joins three spreadsheets, a script that reconciles invoices) used to be a few weeks of work. Now it's often a few days, sometimes an afternoon. When the build cost drops that much, a lot of SaaS stops making sense. Especially the kind you're paying per-seat for while using 10% of the features. ### When we tell clients to build - **The workflow is yours, not generic.** If you've spent months bending a tool to fit how your business actually works, that's the signal. Custom software that matches your process is a real advantage. - **The scope is small and stable.** Internal tools with a handful of users and clear inputs and outputs are the sweet spot. - **You're paying for glue.** A lot of SaaS spend is really just moving data between other SaaS. That's exactly what agents are good at writing. - **Per-seat pricing is eating you.** If a tool costs more every time you hire, run the numbers on a one-time build. ### When we still tell clients to buy - **Anything regulated or security-critical.** Auth, payments, payroll, compliance. Pay someone whose entire job is getting that right. - **Things with a long tail of edge cases.** Email deliverability, accounting, tax. The demo is easy; year three isn't. - **When nobody will own it.** This is the big one. ### The catch nobody puts in the demo Building got cheap. *Owning* didn't. Every tool you build is a tool you maintain: dependency updates, API changes, the one person who knows how it works going on vacation. AI-generated code makes this worse if nobody reviews it. You can end up with a pile of working-but-mysterious scripts that nobody wants to touch. Our rules for keeping custom tools from becoming a liability: 1. **Someone technical owns it.** An employee, a contractor, or a fractional CTO, but a name, not "the AI." 2. **It lives in a repo with tests.** Even a few. Agents are great at writing tests if you ask. 3. **Keep it boring.** Mainstream languages, managed hosting, no clever infrastructure. 4. **Write down the exit.** If this thing breaks and we can't fix it, what do we buy instead? ### How to decide this week Pull up your software subscriptions. For each one, ask: - Do we use more than a third of it? - Does it match how we actually work? - What would a simple version we own cost to build *and* maintain for two years? You'll probably find one or two tools where building wins clearly. Start there, keep it small, and treat it like real software. If you want a second opinion on which ones are worth building, that's exactly the kind of call we help with at Axio Intelligence. [Book a call](https://axiointelligence.com/book). ## Fast isn't the same as reliable: what the Campfire reliability test shows URL: https://axiointelligence.com/blog/fast_isnt_reliable Published: 2026-10-10 · Author: Brice Ayres · Tags: Elixir, Rust, reliability, benchmarks Short answer: A reliability benchmark proposed for the Campfire ports found that at light load, the Rust version delivered messages far faster than Rails or Elixir. With 64 clients posting at once, it disconnected hundreds of subscribers and delivered only 66 of 23,192 messages to every client in one round, while Rails and Elixir kept every subscriber and delivered every message, with higher latency. Throughput benchmarks tell you how fast a system is when things go well; for anything real-time, you also need to know what it does when they don't. This has been a busy week for one open-source chat app. DHH had AI agents port 37signals' Campfire from Rails to Rust, Go and Elixir and [shared benchmarks with Rust on top](https://axiointelligence.com/blog/dhh_campfire_shootout). The Elixir community dug in and found [a large gap in effort between the ports](https://axiointelligence.com/blog/fair_language_benchmark). Pull requests followed. Now there's a new kind of test, and it asks a different question: not how fast, but how reliable. ### The headline benchmark has a blind spot The original benchmark measured throughput: requests per second at a fixed number of clients. It's a useful number, but as Zach Daniel explained in his [reliability pull request](https://github.com/basecamp/once-campfire-verification/pull/6), it "measures throughput at 16 clients and aborts on the first failure, so it can't show how an implementation behaves past that point." For a chat app, behavior past that point is the whole question. What happens when lots of people post at once? Do messages still arrive? ### What the reliability test does The PR adds a `bin/reliability` script to the [shared verification repo](https://github.com/basecamp/once-campfire-verification). It uses the same production images, data, CPU limits and response checks as the main benchmark, but records failures instead of stopping. It runs two profiles: - **Overload:** the main read routes at 64 and 256 clients, reporting valid requests per second, errors and latency percentiles. - **Cable:** 1,000 subscribers to a busy chat room, counting how many subscribed, how many the server disconnected, and how many posted messages reached every subscriber. It runs once with 4 clients posting and again with 64. Zach ran it on a 16-vCPU machine with the server limited to 4 CPUs. He notes that machine is slower per core than the one used for the published report, so the numbers should only be compared with each other. ### The results #### Chat delivery, 1,000 subscribers, two rounds | | Posters | Disconnected | Delivered to all | Messages/s | |---|---:|---|---|---:| | Rails | 4 | 0, 0 | 128/128, 139/139 | 8.5 | | Rails | 64 | 0, 0 | 191/191, 192/192 | 8.9 | | Elixir | 4 | 0, 0 | 476/476, 492/492 | 32.2 | | Elixir | 64 | 0, 0 | 576/576, 602/602 | 35.2 | | Rust | 4 | 0, 0 | 3,874/3,874, 3,744/3,744 | 253.7 | | Rust | 64 | 756, 404 | 66/23,192, 97/11,156 | 5.4 | At light load, Rust is in a different league: about 254 messages per second delivered, against 32 for Elixir and 8.5 for Rails. At 64 posters, it flips. Rust disconnected 756 subscribers in one round and 404 in the other, and delivered only 66 of 23,192 messages to every client in the first round. The PR explains why: Rust "disconnects subscribers that fall 256 messages behind," as documented in its cable server. Rails and Elixir kept every subscriber and delivered every message, with higher latency. José Valim, Elixir's creator, summed it up: "Rust is dropping more than 99% of messages under load, delivering fewer messages than Rails or Elixir." ([post](https://x.com/josevalim/status/2108573335231832392)) #### Read routes under overload | | Errors / invalid | Valid req/s at 256 clients | p99 at 64 → 256 clients | |---|---|---:|---| | Rails | 0 / 0 | 1,791 | 171ms → 1,108ms | | Elixir | 0 / 0 | 1,943 | 48ms → 154ms | | Rust | 0 / 0 | 18,229 | 7ms → 26ms | On plain page loads, Rust is far ahead even under overload, and all three stayed correct. This isn't a story where Rust is bad. It's a story where *one design choice*, dropping slow subscribers, trades delivery for speed. ### A design choice, not a language verdict This is the most important point. Disconnecting subscribers that fall too far behind is a reasonable choice in some systems. It protects the server from slow clients. It's a bad fit for a chat app where people expect every message to arrive. The Rust code could be changed to buffer more or reconnect. The Elixir code could be tuned to go faster. Neither result is fixed by the language. What the test shows is that **a throughput number alone can hide a reliability problem**, and that you only find it by measuring failure on purpose. ### Where things stand The work is still open. José has opened several PRs on the Elixir port, including one to [remove Redis and run jobs and Action Cable delivery in process](https://github.com/basecamp/once-campfire-elixir/pull/10). He's asked that Elixir be allowed to "deviate from the Rails version in the same way Express/Go/Rust/ do" ([post](https://x.com/josevalim/status/2108489592496116203)), and that request is the crux of a fair comparison. It's also worth keeping the bigger picture. Brian Cardarella, a long-time Elixir advocate, said: "I don't believe that DHH did the benchmark to dunk on anybody" ([post](https://x.com/bcardarella/status/2108673701952860423)), and that his only issue is that "everybody is hung up on the numbers and not that DHH created all of those implementations without knowing those stacks. That is the value." ([post](https://x.com/bcardarella/status/2108675201257046360)) Meanwhile, Phoenix keeps moving. José announced an upcoming LiveView feature where any LiveView or LiveComponent can [subscribe to a PubSub topic and have LiveView manage the subscription for you](https://x.com/josevalim/status/2107891893245779995) ([PR](https://github.com/phoenixframework/phoenix_live_view/pull/4441)). ### What to test before you trust a benchmark If you're choosing a stack, a vendor or an architecture, especially for real-time work: - **Push past the happy path.** Run at several times your expected load and record failures instead of aborting. - **Measure delivery, not just acceptance.** A server that accepts a message hasn't delivered it. - **Watch the tail.** p99 latency under load tells you more than averages. - **Look for documented limits.** Buffer sizes, timeouts and disconnect rules are design decisions with real costs. - **Test reconnects.** Clients drop. What happens next matters. Fast is great. Fast and reliable is what users actually need. If you want help testing a system before you bet on it, [book a call](https://axiointelligence.com/book). *Rust logo © Rust Foundation, used under CC BY 4.0.* ## How to become a software subcontractor for defense primes, from a San Antonio dev shop URL: https://axiointelligence.com/blog/defense_software_subcontracting Published: 2026-10-09 · Author: Brice Ayres · Tags: defense, subcontracting, CMMC, San Antonio Short answer: Most small software firms enter defense work as subcontractors, not prime contractors. The path is to register in SAM.gov, pick a narrow lane, get in front of primes and funded startups that need delivery help, and be ready for their security questions: CMMC Level 1 or Level 2 self-assessments are still required even though Phase 2 is paused, and export-controlled programs will limit who can work on them. Primes hire subcontractors who reduce their risk, not add to it. We get this question from other small software firms about once a month: how do you actually get defense software work? The honest answer is that almost nobody starts as a prime contractor. You start as a subcontractor, doing a well-defined piece of work for a prime or a funded defense startup that already has the contract. Here's how that works, from our seat in San Antonio. ### Prime or subcontractor? A **prime contractor** holds the contract with the government. A **subcontractor** works for the prime. For a small software team, subcontracting is usually the right first move: - The prime handles the government relationship, the contract vehicle and most of the paperwork. - You get to prove you can deliver on real programs without carrying all the risk. - Past performance as a sub helps you win more work later, including as a prime. The trade-off is that you depend on the prime for work and your margins are thinner. For most firms starting out, that's worth it. ### Step 1: get registered Even as a sub, primes will usually ask for your basic federal identifiers. Register your business in [SAM.gov](https://sam.gov/), the government's System for Award Management. Registration gives you a Unique Entity ID, and you'll also get a CAGE code. Keep your registration current, since primes check it. ### Step 2: pick a lane "We do software" isn't a pitch. Primes and program managers are looking for a specific capability that fills a gap on a specific program. Good lanes for small software firms include: - Data pipelines and integrations with legacy or government systems - Operator dashboards and web applications - Cloud infrastructure and DevSecOps - Modernizing legacy systems - Test automation and tooling Pick one or two, and be ready to show work in them. ### Step 3: find the primes and startups that need help Defense work isn't just Lockheed and Raytheon anymore. Some of the best subcontracting opportunities are at fast-growing defense startups that just won something big and need to deliver faster than they can hire. Along the I-35 corridor, for example: - **Allen Control Systems** in Austin was selected for an Army counter-drone contract with a [ceiling of up to $500 million](https://www.austinfoundersfeed.com/stories/allen-control-systems-500m-army-counter-drone-contract). - **Darkhive** in San Antonio won a [$49.7 million APFIT production award](https://hoodline.com/2026/05/south-side-drone-upstart-snags-nearly-50-million-pentagon-production-deal/). - **Telos** just won a [$13.5 million contract](https://www.globenewswire.com/news-release/2026/10/05/3374949/0/en/telos-secures-13-5-million-contract-to-continue-support-of-air-force-intelligence-community-cyber-operations.html) supporting Air Force intelligence community cyber operations. We wrote more about this cluster in [the I-35 defense corridor](https://axiointelligence.com/blog/i35_defense_corridor). Local programs help too: Capital Factory's [Defense Academy](https://portsanantonio.us/defense-academy) at Port San Antonio connects startups with people on the government contracting side. SBIR is another way in. The programs are [reauthorized through 2031](https://www.congress.gov/crs-product/IN12705), and startups that win Phase I and Phase II awards often need engineering help to deliver. We covered that in [our SBIR post](https://axiointelligence.com/blog/sbir_sttr_through_2031). ### Step 4: answer the security questions Before a prime gives you access to anything sensitive, they'll ask how you protect it. Have clear answers ready. #### CMMC: paused, not gone The Cybersecurity Maturity Model Certification was supposed to make third-party Level 2 assessments a condition of award starting November 10, 2026. On July 13, the Department of War [suspended that Phase 2 transition](https://dowcio.war.gov/Portals/0/Documents/Library/ImplementingSuspensionCMMC-PhaseII.pdf). During the suspension, program offices can only require CMMC Level 1 (Self) or Level 2 (Self) assessments. That isn't a free pass. As [Automata noted on October 7](https://www.automata.org/insights/cmmc-phase-2-suspended), the department says, "All Phase I self-assessment requirements remain firmly in place," and the CMMC rule itself still contains the original phase schedule. [Clark Hill](https://www.clarkhill.com/news-events/news/dow-pauses-cmmc-phase-2-defense-contractors/) adds that contractors handling covered defense information are still responsible for DFARS 252.204-7012 and NIST SP 800-171 Revision 2. For a subcontractor, that means: know whether you'll handle Federal Contract Information or Controlled Unclassified Information, do the matching self-assessment honestly, and keep your System Security Plan current. #### Export control and ITAR Some programs involve export-controlled technical data. On those, the prime will limit who can access the work, and you'll need to show your team and systems can comply. Ask about this early, before you staff a project. #### Your development environment Expect questions like: Where does the code live? Who has access? Is multi-factor authentication on everything? Where does CUI live, and how is it kept separate? Having good answers is often what separates the firms that get hired from the ones that don't. ### What primes check before they hire a subcontractor From the conversations we've had, primes look for: - **Delivery.** Have you shipped similar work, and can they call a reference? - **Seniority.** Will experienced engineers do the work, or will they be training juniors on the program's budget? - **Security posture.** Do your answers to the questions above hold up? - **Fit with their process.** Will you work in their repos, tools and ticketing, or insist on your own? - **Low drama.** Clear scope, honest estimates, early warnings when something slips. ### Step 5: start small and deliver Your first subcontract will probably be small. Treat it as the audition it is. Deliver on time, communicate early and leave the codebase better than you found it. Defense is a small world, and program managers talk. ### Where we fit We're a San Antonio software firm that subcontracts for defense and dual-use companies: building software around the core product, modernizing legacy systems and setting up secure delivery pipelines. For startups without a senior technical leader, we also work as a [fractional CTO](https://axiointelligence.com/services/fractional-cto). See our [defense and dual-use page](https://axiointelligence.com/industries/defense-dual-use), or [book a call](https://axiointelligence.com/book) if you're a prime or startup that needs software delivered. ## How companies save millions leaving the mainframe, and why AI-assisted COBOL rewrites still need a plan URL: https://axiointelligence.com/blog/cobol_modernization_with_ai Published: 2026-10-08 · Author: Brice Ayres · Tags: mainframe, COBOL, modernization, AI Short answer: Companies that move COBOL workloads off the mainframe report large savings: The New York Times' converted system costs 70% less a year to run, and the Air Force cut one system's annual cost from about $30 million to about $3 million. AI tools from Anthropic, AWS and IBM now make reading and converting COBOL much faster, but translating code is the easy part. The savings come from planning: knowing what each job does, writing it down as a spec, dual-running old and new, and moving one job at a time. In February, Anthropic published a post saying its Claude Code tool could modernize COBOL. That day, [IBM's stock fell 13.2%](https://www.reuters.com/business/ibm-posts-steepest-daily-drop-since-2000-after-anthropic-says-ai-can-modernize-2026-02-24/), its steepest one-day drop since October 2000. Investors heard "AI can rewrite COBOL" and drew a straight line to the end of the mainframe. The reality is more useful, and less dramatic. AI really has changed the economics of COBOL modernization. But the companies saving millions aren't the ones that pointed a model at their code and hit go. They're the ones with a plan. ### Can AI rewrite COBOL code? Yes, and it's getting good at it. Three of the biggest players have shipped tools: - **Anthropic** said Claude Code can map dependencies across large COBOL codebases, document workflows and surface risks that "would take human analysts months to surface," according to [CNBC's coverage](https://www.cnbc.com/2026/02/23/ibm-is-the-latest-ai-casualty-shares-are-tanking-on-anthropic-cobol-threat.html) of its post. The pitch: "Legacy code modernization stalled for years because understanding legacy code cost more than rewriting it. AI flips that equation." - **AWS Transform** handles IBM z/OS COBOL modernization. AWS says [customers are completing full transformation and testing of 250,000-line mainframe applications in six weeks](https://aws.amazon.com/blogs/migration-and-modernization/aws-transform-one-year-milestone/), and that its assessments find an average of 35% in compute and 45% in licensing savings. - **IBM watsonx Code Assistant for Z** converts COBOL to Java. IBM Research reports its pipeline delivers [a median structural quality score of over 80% and a functional score above 75%](https://research.ibm.com/publications/enterprise-scale-cobol-to-java-translation-llms-augmented-with-program-analysis) on its test set. So if you're asking whether AI can convert COBOL to Java, the answer is yes. Notice what IBM's own numbers say, though: a functional score above 75% means a meaningful share of the converted logic still needs work. That's where the real project is. ### Translation isn't migration IBM's response to the sell-off was self-interested, but it wasn't wrong. As Rob Thomas, IBM's SVP of software, [wrote](https://www.cio.com/article/4137185/anthropics-claim-that-ai-can-quickly-refactor-cobol-rattles-ibm-investors.html): "The modernization challenge is not a COBOL language problem. It is everything the application runs on and integrates with." [VentureBeat](https://venturebeat.com/technology/ibms-usd40b-stock-wipeout-is-built-on-a-misconception-translating-cobol-isnt) put the IBM view more bluntly, quoting a spokesperson: the real work is "data architecture redesign, runtime replacement, transaction processing integrity, and hardware-accelerated performance." In our experience, the hard parts of a mainframe migration are: - **Data.** Db2, VSAM, IMS and flat files, with formats and encodings decades old. - **Batch scheduling.** Hundreds of jobs with dependencies nobody has fully written down. - **Integrations.** Partner feeds, EDI, reports that land in someone's inbox every morning. - **Business rules nobody remembers.** The tax edge case, the month-end exception, the hard-coded store number. AI helps with all of these, especially the last one. But it doesn't remove the need to understand them. ### How much can leaving the mainframe save? Real examples, with numbers from the organizations and vendors involved: - **The New York Times** moved a COBOL-based system to Java and later to AWS. It now [costs 70% less to operate per year](https://aws.amazon.com/blogs/apn/automated-refactoring-of-a-new-york-times-mainframe-to-aws-with-modern-systems/) than it did on the mainframe in 2015. - **The U.S. Air Force** converted 1.3 million lines of COBOL to Java on AWS GovCloud. Per the [vendor case study](https://tsri.com/video-lowered-tco-by-90-cobol-to-java-on-aws-the-u-s-air-force-s-modernization/), annual cost went from $30 million to about $3 million. You don't have to move everything to start saving. As we covered in [what actually sets your z/OS software bill](https://axiointelligence.com/blog/zos_peak_software_cost), IBM's monthly software charges usually follow the busiest four hours of the month. Moving the right batch jobs out of that window can lower the bill well before a full migration. ### A mainframe modernization plan that works This is the approach we use. It's slower than "convert everything," and much less likely to fail. #### 1. Inventory and rank List every job, what it reads, what it writes and who depends on it. Rank by dollars, meaning share of the cost peak, and by risk. Start where dollars are high and risk is low. #### 2. Write the spec before the code For each job you move, write down what it does: inputs, outputs, rules, rounding, edge cases, error handling. AI is very good at drafting this from COBOL source. A person who knows the business has to check it. The spec, not the old code, becomes the source of truth. #### 3. Let AI do the heavy lifting Use AI to read the COBOL, draft the spec, generate the new code and write tests. This is where the time savings are real. #### 4. Verify independently Build a check that doesn't come from the same place as the new code, such as a separate model of the spec or reconciliation against real historical outputs. Plant known bugs and make sure your checks catch them. #### 5. Dual-run Run the new job alongside the old one every cycle and compare outputs record by record, including month-end and year-end, until they match. #### 6. Cut over one job at a time Turn off the old job only after the outputs match and the people downstream sign off. Then do the next one. ### When to bring in a mainframe modernization consultant You probably need outside help if: - Your COBOL experts are retiring and nobody is shadowing them - You've tried a big-bang migration and it stalled - You want AI to do the conversion work but don't have a way to prove the results are right - Your licensing bill keeps climbing and you don't know which jobs drive it ### How we help We're a small, senior team that does AI-assisted COBOL modernization the careful way: spec first, independent verification, dual runs, one job at a time. We work alongside your mainframe team, not around them. See our [mainframe migration services](https://axiointelligence.com/services/mainframe-migration), or [book a call](https://axiointelligence.com/book) to talk through which jobs would save you the most to move first. ## Faster ATO for small vendors: SWFT, continuous ATO and FedRAMP 20x explained URL: https://axiointelligence.com/blog/swft_cato_fedramp_20x Published: 2026-10-07 · Author: Brice Ayres · Tags: ATO, FedRAMP, DevSecOps, defense Short answer: Getting software authorized to run on government systems has long taken longer than building it. The Department of War's Software Fast Track (SWFT) initiative and FedRAMP 20x are both moving authorization toward continuous, automated, machine-readable evidence. Small vendors that build a clean DevSecOps pipeline, track their software supply chain and generate security evidence automatically from day one will be ready for either path. Ask anyone who has sold software to the government what the slowest part was, and you'll often hear the same answer: not building it, but getting approval to run it. That approval is an Authority to Operate, or ATO, and for a small vendor it can feel like a wall. That's starting to change. Two efforts, one on the defense side and one government-wide, are pushing in the same direction. Here's what they are and what a small software team should do about them. ### Why ATO has been the bottleneck A traditional ATO is a point-in-time review. You document your system, an assessor reviews it against a set of controls, and someone accepts the risk. Then you change the software, and the question becomes how much of that work you have to repeat. That model fits poorly with teams that ship every week. The Department of Defense said as much in an April 2025 memo, [Accelerating Secure Software](https://dowcio.war.gov/Portals/0/Documents/Library/Memo-AcceleratingSecureSoftware.pdf): "Lengthy, outdated cybersecurity authorization processes frustrate agile, continuous delivery." ### SWFT: the Software Fast Track That memo, signed by Katherine Arrington, then performing the duties of DoD CIO, set up the **Software Fast Track (SWFT)** initiative. It directed the department to define clear, specific: 1. Cybersecurity and supply chain risk management (SCRM) requirements 2. Rigorous software security verification processes 3. Secure information-sharing mechanisms 4. Government-led risk determinations to speed up cybersecurity authorizations The memo is also blunt about open source: the department "currently lacks visibility into the origins and security of software code." Expect questions about where your dependencies come from. The department then asked industry for input. The [combined RFI summary](https://dowcio.war.gov/Portals/0/Documents/Library/SWFT-RFI-Combined-Summary.pdf) describes what respondents already do: continuous monitoring, code reviews, regular penetration testing and red-teaming internally, plus third-party audits and independent penetration tests. Respondents tied this to frameworks like FedRAMP, NIST, SOC 2 and ISO 27001. As [GovCIO reported](https://govciomedia.com/pentagon-swft-rfis-back-shift-to-continuous-software-authorization/), the feedback pushed the Pentagon to move past "checking boxes" toward a data-driven trust model, including continuous ATO. ### Continuous ATO in plain terms Continuous ATO (cATO) flips the model. Instead of proving security once and hoping nothing changes, you show that your platform and process keep the software secure as it changes: automated testing, monitoring and supply chain controls running all the time, with evidence a reviewer can check. The key shift for a vendor: **your pipeline is the evidence.** If your build system scans, tests and records everything automatically, you have most of what a reviewer wants. If it doesn't, you'll be assembling documents by hand every release. ### FedRAMP 20x: the same idea for cloud services On the civilian side, [FedRAMP 20x](https://www.fedramp.gov/20x/) is rebuilding how cloud services get authorized. The program says it's in Phase 3, wide-scale adoption. The milestones so far: - A **Moderate pilot** ran from November 18, 2025 through March 2026. FedRAMP received 14 qualifying submissions, and the first cohort got pilot authorizations on March 6, 2026. - The pilot tested **Key Security Indicators**, machine-readable measures of a provider's security, at the Moderate level. - FedRAMP 20x will first support **Class A (Pilot), Class B (Low) and Class C (Moderate)** certifications, with a High pilot planned next. - FedRAMP says it will stop accepting new Rev5 certifications on **June 11, 2027**. FedRAMP itself notes that future dates are estimates and will shift. ### What they have in common SWFT and FedRAMP 20x come from different places, but they reward the same things: - **Automated, machine-readable evidence** instead of static documents - **Visibility into the software supply chain**: what's in your code and where it came from - **Continuous monitoring** rather than one-time checks - **Independent verification** where the risk calls for it ### What small vendors should build in now You don't need to wait for final rules to get ready. Everything below is good engineering anyway. #### A real CI/CD pipeline Every change goes through the same automated build, test and deploy path. No manual deploys from someone's laptop. #### Software bills of materials Generate an SBOM on every build so you can say exactly which dependencies, at which versions, are in each release. #### Automated scanning Static analysis, dependency vulnerability scanning and container image scanning, run on every build, with results saved. #### Infrastructure as code If your environments are defined in code, you can show exactly how they're configured and that they haven't drifted. #### Logging and monitoring you can export Centralized logs and alerts, with a way to share evidence without giving outsiders the keys. #### Clear access control Know who can touch code, pipelines and production, and keep a record. ### Don't overbuild A three-person startup doesn't need an enterprise compliance platform on day one. Start with the pipeline, the SBOM and the scanning. Add the rest as contracts and data sensitivity require it. The goal is that when someone asks for evidence, you can produce it from your systems instead of writing it from scratch. ### Where we help We build and run DevSecOps pipelines, cloud infrastructure and the evidence trail that goes with them. For defense startups without a senior technical leader, we also serve as a [fractional CTO](https://axiointelligence.com/services/fractional-cto) to make these decisions early. See our [defense and dual-use page](https://axiointelligence.com/industries/defense-dual-use) or [book a call](https://axiointelligence.com/book). ## 398 commits vs 2: how to run a fair language benchmark with AI-written code URL: https://axiointelligence.com/blog/fair_language_benchmark Published: 2026-10-06 · Author: Brice Ayres · Tags: benchmarks, Rust, Elixir, AI coding agents Short answer: Before DHH posted his Campfire benchmark, GitHub shows the Rust port had about 400 commits from three authors, while the Go and Elixir ports had two commits each. Measured from the first port, Rust ran 4.4 times faster than Rails and Elixir 3.3 times, and once community PRs applied similar optimizations, Elixir matched or beat tuned Rust on some read routes. A fair benchmark gives every option the same prompt, the same effort budget and the same freedom to change the design. Two days ago we wrote about [DHH's Campfire shootout](https://axiointelligence.com/blog/dhh_campfire_shootout): AI agents ported 37signals' Campfire from Rails to Rust, Go and Elixir, and Rust came out fastest. His argument was that if agents write the code and nobody reads every line, the fastest language agents can write well wins. Since then, people have dug into the repos. What they found is a good lesson in how to benchmark anything, and especially code written by agents. ### What the commit history shows The three ports are public on GitHub. We counted commits on each one up to the moment DHH posted his comparison on October 4: | Port | Commits before the benchmark post | Authors | |---|---:|---| | [Rust](https://github.com/basecamp/once-campfire-rust) | 400 | 3 | | [Go](https://github.com/basecamp/once-campfire-go) | 2 | 1 | | [Elixir](https://github.com/basecamp/once-campfire-elixir) | 2 | 1 | The Rust repo was created on September 26, so those 400 commits came over about a week. The Elixir port's first commit is titled "Port Campfire to Elixir with Rails parity and Rust benchmarks," and it landed the morning of the same day the results were posted. Others found the same gap. Developer @jskalc summarized it: "Rust's first port from Ruby: 4.4× Rails. Elixir's: 3.3×. Then Rust got 398 commits and 18 perf PRs. Go was ported from that tuned Rust. Elixir got one small tuning pass." ([post](https://x.com/jskalc/status/2107221398003527718)) José Valim, Elixir's creator, looked at the Rust repo's own early numbers and found that they "are in same order of magnitude as Elixir/Go (sometimes worse)" ([post](https://x.com/josevalim/status/2107219957478039784)). So the first-pass ports were close. The big gap came later, after a week of tuning that only one port got. ### What happened when Elixir got the same treatment DHH invited patches, and people sent them. Two pull requests are worth reading. [Zach Daniel's PR](https://github.com/zachdaniel/once-campfire-elixir/pull/1) went after the design. Among other changes, it "Replaced the single database process with a pool of read-only connections plus one writer," moved message caching from Redis into ETS, and fixed a bug where Bandit closed WebSockets that hadn't sent anything for 60 seconds. Action Cable clients mostly listen, so idle chat tabs kept getting disconnected. [A second PR from GitHub user lau](https://github.com/basecamp/once-campfire-elixir/pull/5) built on that and posted these numbers against the tuned Rust port, in requests per second: | Route | Elixir (improved) | Rust (improved) | |---|---:|---:| | Room page | 17,237 | 26,796 | | Messages page | 25,238 | 28,335 | | Sidebar | 32,121 | 27,538 | | Search | 26,790 | 25,488 | | Post a message | 1,995 | 6,101 | Rust still wins on writes and on the room page. But on two of the five routes, Elixir is ahead. That's very different from the original chart. @jskalc also noted a limit of the benchmark itself: it has no writes on the read routes, and he believes both tuned versions are hitting cache nearly every time, "so it's not very realistic" ([post](https://x.com/jskalc/status/2107231340328636673)). ### In fairness to DHH It's worth being fair here. DHH has said he has no stake in the outcome: "I don't have a horse in this race. If you can get the elixir to go faster, awesome! Send a patch and I'll merge it" ([post](https://x.com/dhh/status/2106893034172322221)). He's also said he didn't spend time on the other ports because he isn't interested in those stacks: "I kicked off six conversions of an open source app to see where the agents would take them" ([post](https://x.com/dhh/status/2107377114681086070)). And Brian Cardarella, who runs the Elixir consultancy DockYard, pointed out that the benchmark "showed how much faster Elixir is than Ruby" ([post](https://x.com/bcardarella/status/2107225221509808316)). The point isn't that anyone cheated. It's that the result reflects effort as much as language. ### How to run a fair benchmark Whether you're choosing a language, a framework or a vendor, the same rules apply. #### Give every option the same budget Same prompt, same number of tuning rounds, same hours. If one option gets a week and another gets an afternoon, you're measuring the week. #### Give every option the same freedom The Elixir port was told to keep Rails parity, including Redis and the Rails-style design. The Rust port was free to diverge. Either hold everyone to the original design or let everyone redesign. #### Compare first passes and tuned versions separately The first-pass comparison answers "how good is the agent out of the box?" The tuned comparison answers "how fast can this get?" Both are useful. Mixing them isn't. #### Measure what users feel Throughput on cached reads is easy to measure. For a chat app, you also care about writes, latency under load, and whether messages actually arrive. #### Publish the method with the numbers Commit counts, prompts and tuning steps should sit next to the chart. Otherwise readers can't tell what's being compared. ### What this means for agent-led rewrites DHH's premise still deserves attention: agents make rewrites cheap, and how well agents write a language out of the box matters. But "out of the box" has to mean the same thing for every option. If you're planning to have agents rewrite part of your stack and want to compare options fairly before committing, that's work we do. [Book a call](https://axiointelligence.com/book). *Rust logo © Rust Foundation, used under CC BY 4.0.* ## The I-35 defense corridor: where software subcontractors fit in Austin and San Antonio URL: https://axiointelligence.com/blog/i35_defense_corridor Published: 2026-10-05 · Author: Brice Ayres · Tags: defense, San Antonio, Austin, subcontracting Short answer: Austin and San Antonio have become a real defense tech corridor: Allen Control Systems was selected for an Army counter-drone contract with a ceiling of up to $500 million, San Antonio's Defense Unicorns reached a $1 billion valuation, and Darkhive won a $49.7 million APFIT production award. Hardware gets the headlines, but every one of these companies runs on software, and a lot of it is built with outside help. Software subcontractors fit where startups and primes need to deliver faster than they can hire. San Antonio has called itself Military City USA for a long time. What's changed in the last couple of years is the startups. Between Austin and San Antonio, along I-35, there's now a cluster of defense tech companies winning real contracts and raising real money. We're a San Antonio engineering firm, so we watch this closely. Here's a snapshot of what's happening, and where software subcontractors like us actually fit. ### Austin: counter-drone and autonomy The biggest recent news is from Austin. On October 1, the Austin Business Journal reported that [Allen Control Systems won an Army counter-drone contract](https://www.bizjournals.com/austin/news/2026/10/01/anti-drone-startup-wins-army-contract-texas.html) as part of Domestic Shield, a program focused on counter-unmanned aircraft systems for facilities inside the U.S. Per [Austin Founders Feed](https://www.austinfoundersfeed.com/stories/allen-control-systems-500m-army-counter-drone-contract), the contract has a ceiling of up to $500 million. The company builds Bullfrog, an autonomous weapon station that uses computer vision and AI to detect, track and target incoming drones. It raised a $200 million Series B earlier this year at a $2.2 billion valuation and announced a 191,000-square-foot manufacturing facility in the Austin area. It's not the only one. In August, the Austin Business Journal reported that [NODA AI secured a $100 million DoD contract](https://www.bizjournals.com/austin/news/2026/08/18/big-contracts-land-local-defense-tech-startups-atx.html) for autonomous mission command, about six months after a $25 million Series A. The same piece covered Smack, an Austin- and California-based startup founded by two Marine Forces Special Operations Command veterans, which raised a $61 million Series B for an AI reasoning layer that helps commanders model scenarios. ### San Antonio: drones, secure software and cyber San Antonio's cluster leans toward secure software, cyber and tactical hardware. - **Defense Unicorns**, founded in 2021, provides secure delivery of software across military operations. In January it announced a [$136 million Series B at a $1 billion valuation](https://www.bizjournals.com/sanantonio/news/2026/01/14/san-antonio-defense-tech-startup-raises-136m.html). - **Darkhive**, based on the South Side, won a [$49.7 million award](https://hoodline.com/2026/05/south-side-drone-upstart-snags-nearly-50-million-pentagon-production-deal/) through the Pentagon's APFIT program to ramp up production of tactical drones and battlefield communications gear. The report notes it's the program's single largest award to date. Darkhive also announced a $30 million Series B led by RTX Ventures. - **Cyber work continues** around the 16th Air Force. Today, Telos announced a [$13.5 million, three-year contract](https://www.globenewswire.com/news-release/2026/10/05/3374949/0/en/telos-secures-13-5-million-contract-to-continue-support-of-air-force-intelligence-community-cyber-operations.html) to continue supporting Air Force intelligence community cyber operations. There's also infrastructure for founders. Capital Factory runs its Center for Defense Innovation at the Boeing Center at Tech Port, and its [Defense Academy](https://portsanantonio.us/defense-academy) helps startups learn to sell to the Department of Defense. As Port San Antonio's Will Garrett put it, the federal government is "more frequently looking outside the traditional federal contractor space to find technology and solutions that are moving more quickly." ### Every one of these companies is a software company Look at the list again. Computer vision targeting. Autonomous mission command. An AI reasoning layer. Secure software delivery. Tactical communications. Even the hardware companies are, underneath, software companies. That creates a predictable crunch. A startup wins a contract or a big round, and suddenly needs to: - Ship features on a delivery schedule a program office is watching - Build the data pipelines, dashboards and integrations around the core product - Meet security requirements that a seed-stage team never had to think about - Hire cleared or clearable engineers in a tight market Hiring alone rarely keeps up. ### Where software subcontractors fit In our experience, outside software teams are most useful in a few specific places: #### Around the core, not in it Your core IP, whether that's the targeting model, the autonomy stack or the radio, should usually stay in-house. The work around it is often a better fit for a subcontractor: operator dashboards, data ingestion, test harnesses, admin tools, integrations with government systems, and the cloud infrastructure everything runs on. #### When the timeline beats the hiring plan A contract award comes with dates. If it takes four months to hire and onboard a senior engineer, a team that can start next week is worth a lot. #### Senior technical leadership Many defense startups are founded by operators and domain experts, not career software leaders. A [fractional CTO](https://axiointelligence.com/services/fractional-cto) can own architecture, security and delivery decisions until it makes sense to hire full-time. #### Getting ready for compliance and authorization Primes and program offices will ask how you handle sensitive data, how you build securely, and how your software gets approval to run on government systems. Designing for that early is much cheaper than retrofitting it. ### What primes and startups look for in a subcontractor If you're on the hiring side, here's what we'd ask of any software partner: - **U.S.-based people** who can work within export-control rules when the program requires it - **A security story** that holds up: who can access code and data, and how - **Senior engineers**, not a bench of juniors learning on your contract - **Willingness to work inside your process,** your repos and your tools - **A track record of delivering**, with references you can call ### Why being local still matters A lot of this work can be done remotely. But proximity still helps: being able to sit in a room at Port San Antonio or drive up to Austin for a test day builds trust faster than any number of video calls. That's the work we do. If you're a defense or dual-use company on the I-35 corridor and you need software delivered, see our [defense and dual-use page](https://axiointelligence.com/industries/defense-dual-use) or [book a call](https://axiointelligence.com/book). ## DHH's Campfire shootout: AI agents rewrote one app in Rust, Go and Elixir URL: https://axiointelligence.com/blog/dhh_campfire_shootout Published: 2026-10-04 · Author: Brice Ayres · Tags: Rust, Elixir, AI coding agents, benchmarks Short answer: DHH had frontier coding agents port 37signals' open-source Campfire chat app from Rails to Rust, Go and Elixir, then shared benchmarks with Rust on top. His argument isn't that Ruby is bad: it's that if agents write the code and you no longer read every line, Ruby's productivity and joy matter less, and languages agents can't write well out of the box will struggle. The early pushback from the Elixir community is about how the ports were done, which is a fair question to ask of any benchmark. David Heinemeier Hansson, the creator of Ruby on Rails, spent the last week doing something a lot of us have wondered about: he had AI coding agents rewrite a real Rails app in other languages, then compared how they performed. The app is [Campfire](https://github.com/basecamp/once-campfire), 37signals' open-source group chat product. The results landed on X today and started an argument. We'll lay out what he did and what he claimed, in his own words, before getting into the critiques. ### What DHH actually did On September 28, DHH posted that he'd been [running a beta of Campfire rewritten in Rust](https://x.com/dhh/status/2104633108092092880): > The code itself is still ugly as sin, and 6x as verbose, but the conversion was free*, and I never had to look at the Rust directly, so this is awesome The Rust port lives at [basecamp/once-campfire-rust](https://github.com/basecamp/once-campfire-rust). Go and Elixir ports followed. Today he posted the comparison: > I've had agents implement and optimize the Campfire web app in Elixir, Go, and Rust. Yes, Ruby is the slowest. I didn't care about that when the pay-off was huge in terms of productivity and developer joy. But if you're no longer reading the code? ([post](https://x.com/dhh/status/2106810173683851564)) He also described how little steering the ports got. Replying to José Valim, Elixir's creator, he said the prompt was "just something like 'Rewrite this in Elixir. Review with Codex. Optimize it.' Same as what was used for Go, Laravel, Rust, etc." ([post](https://x.com/dhh/status/2106883833773650428)) ### The argument, in his words It's easy to read this as "Rust good, Ruby bad." That's not what he said. The argument has three parts. **1. Developer joy was the reason to accept slower code.** For two decades, the case for Ruby has been that the productivity and happiness were worth the performance cost. DHH still says that was the right trade *when humans wrote and read the code*. **2. If agents write it, the trade changes.** "I'm not saying that all apps need Rust levels of performance. Far, far from it! But I am saying that if agents are really good at writing Rust, and you're onboard with agent acceleration meaning we don't read all generated lines, then it's a good argument for Rust!" ([post](https://x.com/dhh/status/2106844850742259736)) **3. Languages agents struggle with will struggle.** This is the part aimed at Elixir and Go: "If your answer here is 'frontier agents aren't good at writing Elixir or Go', then it only makes the argument worse. Any programming language that agents can't write well out of the box is going to have a hard time in the future." ([post](https://x.com/dhh/status/2106844184392991137)) He's also clear this isn't a personal conversion: "Do you know how badly I would hate having to personally write Rust?? But when the premise changes, you need to update your priors." ([post](https://x.com/dhh/status/2106846641906978939)) And he's invited fixes more than once. To one critic: "Please do send a PR to speed things up! But also realize that it's not exactly extra points for Elixir if frontier agents can't find the magic 'go fast' switches." ([post](https://x.com/dhh/status/2106864061832991134)) ### Why we take the argument seriously Strip away the language war and there's a real point here, one we see in client work. - **Porting got cheap.** DHH says each conversion took "less than two hours" and produced "tens of thousands of lines" ([post](https://x.com/dhh/status/2106841744239194569)). Even if you discount that, a working port of a medium-sized web app is now days of work, not months. - **Out-of-the-box agent quality is a fair test.** Most teams using agents won't hand-tune prompts per language. If one language gets good results from a plain prompt and another needs an expert steering it, that's a real cost. - **Not reading every line is already happening.** Whether or not you like it, many teams are reviewing agent output rather than writing it. ### The first pushback The Elixir community responded within hours, and the critique is about *method*, not the premise. Christian Ertel pointed at the Elixir port's database module, [`lib/campfire/db.ex`](https://github.com/basecamp/once-campfire-elixir/blob/main/lib/campfire/db.ex), and noted that its design "guarantees that every query is serialized into a single process mailbox" ([post](https://x.com/crertel/status/2106862177147650447)). In plain terms: every database call waits in one line. Chris McCord, Phoenix's creator, made a broader point: "Given campfire started as ruby, it's going to be designed as stateless app," and that's not how you'd design a chat app in Elixir ([post](https://x.com/chris_mccord/status/2106865316899037391)). And Tom Gosling looked at the repos and summarized the effort behind each port: "Rust: 3 human authors, 397 commits over 6 days, 32 perf experiments, free to diverge from Rails. Go: 1 author, a port of the Rust port, 2 days, 12 experiments. Elixir: 1 author, 1 day, one ~1hr tuning pass, kept Rails' Redis and Thruster." ([post](https://x.com/tomgosling/status/2106869782045925422)) That last point is the one to watch. If the ports didn't get the same amount of work, the benchmark compares effort as much as languages. ### What to take away today - **The premise stands on its own.** Agents changing the cost of a rewrite is real, and so is the question of which languages agents write well. - **The benchmark needs a closer look.** Whether the comparison was apples to apples is a separate question from whether the premise is right. We'll dig into that next. - **DHH has asked for patches.** The repos are public, and there's an open invitation to make the slower ports faster. If you're thinking about an agent-led rewrite of your own app, the most useful lesson is about process: decide up front how you'll judge the result, and give every option the same chance. If you'd like help setting that up, [book a call](https://axiointelligence.com/book). ## Elixir in fall 2026: gradual types, LiveView 1.2 and AI coding tools URL: https://axiointelligence.com/blog/elixir_fall_2026 Published: 2026-10-03 · Author: Brice Ayres · Tags: Elixir, Phoenix, LiveView, AI coding Short answer: Elixir v1.20, released June 3, 2026, made Elixir a gradually typed language that finds verified bugs and dead code without type annotations. Phoenix LiveView 1.2 added colocated CSS and smaller quality-of-life fixes, and Tidewave keeps adding tools for coding agents working inside Phoenix apps. If you last looked at Elixir a few years ago, the language is safer and better suited to AI-assisted work than it was. We get asked about Elixir a lot, usually by teams who know Ruby or Node well and have heard good things about Phoenix. The question is almost always the same: is it worth adopting now, especially with so much code being written by AI agents? This post is a snapshot of where the language and its main web stack stand this fall. We'll keep it to what has shipped. ### Elixir v1.20: a gradually typed language The big news this year is [Elixir v1.20](https://elixir-lang.org/blog/2026/06/03/elixir-v1-20-0-released/), released June 3. José Valim's announcement sums it up: with this release the team completed its first milestone, which was "to perform type inference and gradually type check every Elixir program, without introducing type annotations." In practice, that means the compiler now reports two kinds of problems in code you've already written: - **Dead code.** Clauses that can never match. - **Verified bugs.** In the release post's words, "typing violations that are guaranteed to fail at runtime if executed." You don't have to add annotations to get this. The [v1.20 release notes](https://github.com/elixir-lang/elixir/releases/tag/v1.20.0) walk through what it can infer. A guard like `when is_map_key(x, :foo)` tells the compiler `x` is a map with a `:foo` key. A function body like `data.foo + data.bar` tells it the argument must be a map with those keys, holding integers or floats. The [changelog](https://github.com/elixir-lang/elixir/blob/v1.20.0/CHANGELOG.md) adds inference across clauses, occurrence typing on `case`, `cond` and `with`, and warnings for redundant clauses. The release requires Erlang/OTP 27 or later and is compatible with OTP 29. #### What's next for the type system Type *signatures* aren't here yet. The release post lists what has to happen first: the team needs to be happy with type-checking performance, and needs efficient implementations of recursive types, parametric types and a way to treat map key-value pairs as an enumerable. Typed structs and then type signatures come after that. This was planned well ahead: the January post announcing the first release candidate, on [Elixir's 15th birthday](https://elixir-lang.org/blog/2026/01/09/type-inference-of-all-and-next-15/), laid out the release-candidate schedule month by month. ### Why types matter more when agents write code This is our take, not something from the release notes. If an agent writes a large share of your code and you're reviewing rather than typing, you want the compiler to catch as much as possible before a human looks. An agent that misreads a data shape tends to produce code that looks fine. A type checker that flags guaranteed failures, with no annotations to keep up to date, is a cheap safety net. ### Phoenix LiveView 1.2 [LiveView 1.2](https://phoenixframework.org/blog/phoenix-liveview-1-2-released) shipped June 10. The headline is **colocated CSS**: you can keep styles next to the component that uses them. The team deliberately didn't ship scoping by default, because the CSS `@scope` rule wasn't yet well supported across browsers. Instead there's a behaviour you can implement for your own scoping strategy. The smaller changes are the kind you notice day to day: - A `TagFormatter` behaviour for formatting certain embedded tags in HEEx with a tool of your choice (the docs show prettier) - `Phoenix.LiveView.JS` structs encoded automatically when sent with `push_event` - HEEx debug annotations configurable per module - Test warnings configurable by category - Separate documentation for the JavaScript client Upgrading from 1.1 is a version bump in `mix.exs`. ### Tidewave: tooling for coding agents in Phoenix [Tidewave](https://github.com/tidewave-ai/tidewave_phoenix/blob/main/CHANGELOG.md) connects coding agents to a running Phoenix app through MCP, so an agent can do more than read files. The changelog shows steady releases this year: - **v0.9.1 (September 23):** `mix tidewave.proxy`, and instructions included in the MCP initialization response - **v0.9.0 (August 18):** a `create_design_canvas` tool, and removal of the `get_*_schema` tools - **v0.8.3 (August 13):** LiveView patching diagnostics - **v0.8.1 (July 29):** Tidewave Connect support The direction is clear: give agents the same view of a running app that a developer has, instead of asking them to guess from source files alone. ### So, should you pick Elixir now? Our honest answer hasn't changed much, but the reasons have shifted: - **It's a great fit** for real-time features, many concurrent connections, background work, and systems that need to keep running when parts fail. That's what the BEAM was built for. - **The type system** removes one of the most common objections from teams coming from typed languages, without making you write type annotations. - **The tooling for agents** is real and maintained by people close to the core team. The open question is how well general-purpose coding agents write *idiomatic* Elixir without that tooling. Elixir works best when you design around processes and messages rather than copying patterns from Rails or Express. An agent told to port an app one-to-one will often copy the old design, and that can hide what the platform is good at. We expect that question to get more attention soon. If you're weighing Elixir for a new product or a rewrite, we're happy to talk it through. [Book a call](https://axiointelligence.com/book). ## SBIR/STTR are back through 2031: what to do before the October 21 deadline URL: https://axiointelligence.com/blog/sbir_sttr_through_2031 Published: 2026-10-02 · Author: Brice Ayres · Tags: SBIR, STTR, defense, startups Short answer: Congress reauthorized SBIR and STTR through September 30, 2031, ending a six-month lapse, and the continuing resolution that started October 1 doesn't stop the programs. The current Department of War SBIR/STTR release closes October 21. If you're a defense startup, use the next three weeks to pick one topic, lock down the technical approach and line up the engineering help you'll need for Phase I and Phase II. For six months, the SBIR and STTR programs were stuck. Their legal authority expired on September 30, 2025, and agencies couldn't issue new solicitations until Congress acted. For a lot of small defense tech companies, that meant a pipeline of Phase I and Phase II work simply stopped. That's over. And with a new fiscal year starting under a continuing resolution, we've been getting the same question from founders: is SBIR safe to plan around right now? Short version: yes. Here's what changed, what didn't, and what we'd do with the next three weeks. ### SBIR and STTR reauthorization: what actually passed On April 13, 2026, the Small Business Innovation and Economic Security Act became [Public Law 119-83](https://www.congress.gov/119/plaws/publ83/PLAW-119publ83.pdf). It reauthorized SBIR, STTR and the related pilot programs through **September 30, 2031**, ending what the Congressional Research Service called [a six-month lapse in authority](https://www.congress.gov/crs-product/IN12705). A few details matter for planning: - **Five years of runway.** A 2031 sunset means you can plan a Phase I to Phase II to Phase III path without betting on another reauthorization fight next fall. - **Carry-over funds.** Section 9 lets agencies that have SBIR or STTR money left at the end of fiscal 2026 use it in fiscal 2027. Some of the money that couldn't be awarded during the lapse can still go out. - **Foreign influence and eligibility got attention.** CRS notes the law addressed foreign influence, eligibility and commercialization, which were [the subject of debate](https://www.congress.gov/crs-product/IN12705) before it passed. Expect due-diligence questions about ownership, investors and foreign ties to be taken seriously. [Crowell & Moring's summary](https://www.crowell.com/en/insights/client-alerts/sbirsttr-programs-reauthorized-after-six-month-lapse) is a good read if you want the legal detail. ### Does the continuing resolution stop SBIR? No. This is the most common confusion we hear, and [BW&CO lays it out clearly](https://www.bwcoconsulting.com/blog/continuing-resolution-sbir-funding): last year's stoppage was an *authorization* problem. A continuing resolution is a *funding* question. SBIR doesn't have its own appropriation. Agencies with more than $100 million in extramural R&D set aside 3.2% of it for SBIR, and agencies above $1 billion set aside another 0.45% for STTR. The reauthorization left those percentages alone. Under the CR, agency R&D budgets continue at the fiscal 2026 rate, so the SBIR share continues with them. What a CR *can* do is slow award decisions. Plan for that. Don't plan for a stop. ### The October 21 deadline The current Department of War SBIR/STTR release [closes October 21](https://www.bwcoconsulting.com/blog/continuing-resolution-sbir-funding). If you were waiting for the dust to settle, it has. Three weeks is enough time to submit a solid Phase I if you start now and stay focused. ### What we'd do in the next three weeks #### 1. Pick one topic and say no to the rest The temptation after a long pause is to chase every topic that's close to your product. Don't. One strong proposal beats three rushed ones. Pick the topic where you can show the clearest technical approach and the most believable path to a real user. #### 2. Write the technical approach like an engineer will read it Reviewers aren't grading prose. They want to know you understand the problem, have a specific plan, and know where the risk is. A good technical volume names: - The system you'll build or prove out, at the architecture level - The data it needs and where that data comes from - How you'll know it worked: measurable results, not adjectives - What you won't do in Phase I, and why #### 3. Plan Phase II now Phase I is short and small. The real goal is Phase II, and after that, a program office that wants to keep paying for it. Write the Phase I so its results feed directly into a Phase II scope. If you can't sketch what Phase II looks like, the Phase I is probably too vague. #### 4. Line up your engineering capacity This is where a lot of small teams get stuck. A founder with a strong concept and two engineers can win a Phase I and then struggle to deliver it while also running the company. Decide now who's going to build what: - What stays in-house because it's your core IP - What a trusted partner can build under your direction - Who owns architecture, security and delivery #### 5. Get your security house in order Even at Phase I, you'll be asked how you handle sensitive information. Make sure you know what kind of data you'll touch, where it'll live, and who can get to it. If you expect to handle Controlled Unclassified Information later, start designing for it now rather than retrofitting. ### Where we fit We're a San Antonio engineering firm. We help defense and dual-use startups with the technical side of SBIR work: shaping the technical approach, designing the architecture, and building the software when a Phase I or Phase II comes through. We also act as a [fractional CTO](https://axiointelligence.com/services/fractional-cto) for teams that need senior technical leadership without a full-time hire. You can see more about the kind of work we do on our [defense and dual-use page](https://axiointelligence.com/industries/defense-dual-use). ### The bottom line SBIR and STTR are authorized through 2031, they keep running under the CR, and the next DoW deadline is October 21. The programs are stable enough to plan around again. Pick one topic, write a technical approach an engineer would respect, and make sure you can actually deliver what you propose. If you want a second set of eyes on a technical volume before you submit, [book a call](https://axiointelligence.com/book). ## Same-SIM satellite IoT: what works today URL: https://axiointelligence.com/blog/satellite_iot_same_sim Published: 2026-10-01 · Author: Brice Ayres · Tags: IoT, satellite, NTN, connectivity Short answer: Satellite IoT can now run on the same SIM as cellular through 3GPP Release 17 NTN, but only when the module, the connectivity provider's satellite agreement, the antenna and the firmware all support it. In our testing, many providers advertising satellite IoT connected intermittently or not at all, so ask for a test SIM and written coverage before you commit. Cell networks were built where people are. A lot of the things worth monitoring aren't: wellheads, pump stations, livestock water tanks, rail cars, shipping containers, sensors on a ridgeline. When a device drives or floats out of coverage, it goes quiet, and you find out what happened later, if at all. Until recently, the answer was a second radio. You added a satellite modem next to the cellular one, signed a second contract, paid for a second data plan, and built a second pipeline into your cloud. It worked, but it doubled the hardware, the firmware paths and the billing for a link most devices only need occasionally. That's changing. Satellite networks can now act like another cell network, reachable from a standard IoT module on the SIM already in the device. That's the promise, anyway. Here's what makes it hard, and what we've learned from testing it. ### Why is satellite IoT harder than cellular? Satellite isn't cellular with a longer range. Your device and your software need to handle it differently. - **Small payloads.** Think tens to a few hundred bytes per message: a position, a tank level, an alarm. It isn't a pipe for logs, photos or firmware updates. - **Latency in seconds, not milliseconds.** Messages can take seconds or longer to land, and some networks queue them until a satellite is overhead. Anything that expects a fast round trip, like a chatty protocol or a TLS handshake on every message, needs to be rethought. - **The device has to know where it is.** Under the 3GPP standard for satellite IoT, the device uses a GNSS position fix to correct for satellite motion and timing before it transmits. Many modules can't run GNSS and the cellular radio at the same time, so firmware has to sequence them, and that costs time and battery. - **Sky view and antennas.** The device needs a clear view of the sky, and satellite runs on different frequency bands than terrestrial LTE. An antenna tuned for cellular, mounted inside a steel enclosure, won't close the link. - **Power.** Transmitting to a satellite takes more energy per message than transmitting to a tower a few miles away. Battery-powered devices need a budget for how often they're allowed to use it. - **Cost per byte.** Satellite data costs far more than cellular. Without rules about which messages may go over satellite, a misbehaving device can burn through a month's budget in an afternoon. - **Failover is your problem.** Something has to notice that cellular is gone, decide satellite is worth the cost, switch, queue what can wait, and switch back. Most of the time that's your firmware, not the network. None of these is a deal-breaker. All of them have to be designed for from the start, not added after the device ships. ### How does same-SIM satellite IoT work? The standards work that made this possible is 3GPP Release 17, which defined non-terrestrial networks (NTN) for NB-IoT and LTE-M. In plain terms, a satellite network can now present itself to a device the way a cell network does. From there, it works much like roaming. If your connectivity provider has an agreement with a satellite network operator, the satellite network shows up as one more network your SIM is allowed to join. The device keeps its SIM and its identity, and traffic can come back to your cloud through the same path as your cellular traffic. You keep one SIM, one device record and one pipeline. The conditions matter, though. You need: 1. **A module that supports NTN**, with firmware that actually has it enabled, on the right satellite bands. 2. **A connectivity provider with a working satellite agreement** that covers the places your devices go. 3. **The right antenna and mounting** for the satellite bands, with a view of the sky. 4. **Firmware that knows the difference** between a cellular link and a satellite one, and behaves accordingly. When all four line up, it's a real improvement over a second radio. When one is missing, you get a device that says "satellite-ready" on the box and never sends a byte over satellite. ### "We have satellite" can mean very different things Over the past several months we've tested satellite offerings from several connectivity providers on real devices, on the bench and in the field. Many advertise satellite IoT. In our testing, a lot of them connected only intermittently, in limited areas, or not at all. The marketing was ahead of the network. That isn't always bad faith. This is a new technology, and an announced partnership, a pilot and a commercial service are three different things that tend to share one press release. But if you're planning a product around it, the difference matters. Before you commit, ask: - **Is it NTN on the same SIM, or a separate satellite modem and contract?** Both are valid. They're very different engineering and cost decisions. - **Is it commercially live where your devices operate today?** Not "launching," not "in trials." Ask for the coverage area in writing. - **Which modules and firmware versions are approved to use it?** Can you buy those modules in volume now? - **Can we test it before we sign?** A provider confident in its network will put a test SIM in your device. If they can't, that tells you something. - **Who handles failover?** Does anything in their stack help, or does "support" just mean the SIM is allowed to try? - **What does a message actually cost,** and does satellite data come back through the same endpoint as cellular, or a separate one you have to integrate? If the answers are vague, plan as if satellite isn't there yet. ### What we're building After a lot of testing, we found one network that connects consistently. We're working toward a partnership with them. On top of that partnership, we plan to build a platform that lets anyone get satellite connectivity for their devices without becoming a satellite expert first. The idea is simple: pick a device that supports satellite, activate it, and have its data arrive in your cloud, with the cellular-to-satellite switching and the message budgeting handled for you. No second radio, no separate pipeline, no months of integration work to find out whether it connects. It's early. There's no name or launch date yet, and we'll share more as the partnership and the platform take shape. If you have devices that need to work beyond cell coverage and want to be among the first to try it, email us at [contact@axiointelligence.com](mailto:contact@axiointelligence.com). We'd like to hear what you're connecting. If you need cellular-to-satellite failover designed into a device now, that's [work we already do](https://axiointelligence.com/services/cellular-satellite-connectivity). ## What actually sets your z/OS software bill URL: https://axiointelligence.com/blog/zos_peak_software_cost Published: 2026-10-01 · Author: Brice Ayres · Tags: mainframe, z/OS, COBOL, cost reduction Short answer: IBM's monthly-licensed z/OS software, including z/OS, CICS, Db2, IMS and MQ, is usually billed on the highest rolling four-hour average of MSU use in the month, so the busiest four hours set the bill. To lower it, find the batch jobs in that window with SCRT, SMF and scheduler data, rank them by share of the peak rather than total CPU, then reschedule them or rebuild them in the cloud one at a time with a dual run. Most companies still on an IBM mainframe know the monthly software bill is large. Fewer know which four hours of the month set it. That matters because the bill for IBM's monthly-licensed software on z/OS isn't based on how much you use the machine over the month. It's based on the busiest stretch. If you can find what runs in that stretch and move it, the bill comes down. You don't have to rewrite everything at once to get there. This post covers how the peak works, how to find the jobs inside it, and the two levers for lowering it. ### The bill is set by four hours, not thirty days IBM's Monthly License Charge (MLC) software, which includes z/OS itself, CICS, Db2, IMS and MQ, is usually billed on **sub-capacity pricing**. Capacity is measured in MSUs (millions of service units, IBM's unit of processing capacity). For each product, IBM looks at the LPARs where it runs and takes the **highest rolling four-hour average** of MSU use during the month. That one number sets the charge. The data comes from your own system. SMF records track CPU use continuously, and IBM's Sub-Capacity Reporting Tool (SCRT) turns them into the monthly report you submit. So the peak is no secret. It's in a report your systems programmers already produce. Two consequences follow: - **Quiet hours are cheap.** A job that burns a lot of CPU at 3 a.m. on a Sunday, when nothing else is running, may not add a dollar to the bill. - **One busy window is expensive.** A job that adds modest CPU at the moment of the monthly peak raises the bill for the whole month. The rolling four-hour peak is common, but it isn't the only model. Depending on the vendor and the contract, mainframe software can be priced on the peak, on the machine's full capacity, on total consumption, or through an enterprise agreement, and third-party software from Broadcom and BMC adds its own terms. The details vary too much to generalize. What holds under every model is simpler: the bill follows the work that runs on the mainframe. Less work means less to license and less to run. ### Which jobs are in the peak? For most manufacturers, distributors and retailers, the monthly peak isn't the online day. It's batch: - Nightly inventory and replenishment runs - Pricing and promotion feeds to stores, e-commerce and partners - Month-end close and the reports that go with it - Extracts to the data warehouse, planning tools and EDI partners Many of these jobs follow the same pattern: **read IBM data, write a file, feed or report.** They don't post transactions or change the system of record. They're islands, and islands are the easiest thing to move. To see which ones are in your peak, line up three sources: 1. **SCRT reports** for the last several months, to find the peak hour each month and which LPARs drive it. 2. **SMF records** for those windows: job-level accounting (type 30) and workload activity (type 72) show which jobs and service classes were consuming CPU at the time. 3. **The scheduler export** (Control-M, CA-7, IBM Z Workload Scheduler or similar), to see what each job depends on, what depends on it and when it's allowed to run. ### Rank by share of the peak, not total CPU This is where most cost exercises go wrong. The instinct is to go after the biggest CPU consumers. But the bill doesn't care about total CPU. It cares about CPU in the peak window. So rank every job on two axes: - **Dollars**: how much of the monthly peak this job accounts for, and what that's worth at your MLC and third-party rates. - **Risk**: what breaks downstream if the job is late or wrong, and how well anyone still understands it. The best first candidates sit high on dollars and low on risk: big contributors to the peak with simple inputs, simple outputs and a clear owner. ### First lever: move the job in time If your contract is priced on the peak, the cheapest fix is often a scheduling change. If a job is in the peak only because it was always scheduled at that time, and nothing downstream needs it then, moving it to a quiet window can lower the peak without new code. Check this before anything else. Also check whether your team already caps capacity (defined capacity or group capacity limits). Capping lowers the bill by slowing work down when the four-hour average hits the limit, which is exactly what you don't want for time-sensitive batch. Some work can also run on **zIIP** specialty engines, which don't count toward the MSU figure for software pricing. Db2 distributed requests, Java and some utilities qualify. Ordinary COBOL batch generally doesn't. ### Second lever: move the job off the box When a job can't move in time because the stores, the warehouse or a partner needs its output by a deadline, rebuild that one job in the cloud: 1. **Replicate only what it reads.** Land the job's input files or tables in AWS, Azure or Google Cloud, as a scheduled extract or a change data capture feed. Time the replication outside the peak, or you've just moved CPU from one job to another. 2. **Rebuild the logic** against Postgres or the database you already run, with the same output format the downstream systems expect. 3. **Dual-run.** Run the new job alongside the old one every cycle and compare the outputs until they match, including month-end and other edge cases. 4. **Turn the old job off** once the outputs match and the people downstream have signed off. Then the next job. Everything else keeps running on the mainframe while you do this. You're taking load off the box one job at a time, with evidence at every step, and each job you move makes a full migration smaller if and when you choose one. ### Start around the core Start with the jobs around the core, not the core itself. Programs that post transactions are bigger, riskier moves, best made once the team and the cloud platform have a track record from the easier jobs. And some systems, like a bank's deposit core or a government benefits system, aren't candidates for this approach at all. ### Does this apply to IBM i? IBM i (the old AS/400) isn't licensed this way, and there's no rolling four-hour peak. The cost there is licensing and hardware, and usually people: decades of RPG and COBOL batch that fewer people understand every year. The method (inventory the jobs, pick one, dual-run, turn it off) is the same. The ranking is different: by who screams if it's late, and by whether the person who understands it is still around. ### How we run it We start with a diagnostic: your contracts and invoices, the scheduler export and usage reports on z/OS, or the job scheduler and programs on IBM i. The result is a ranked job list, a migration plan and a baseline of today's licensing and compute spend. There's no upfront fee; we're paid a percentage of the net savings against that baseline, after the cost of running the work in the cloud. More on the offer: [mainframe & IBM i migration](https://axiointelligence.com/services/mainframe-migration). If you're working through the same question for your cloud bill, the [cloud cost diagnostic](https://axiointelligence.com/services/cloud-cost-reduction) is the same idea pointed at a different invoice. ## How we usually find 30–50% of a cloud bill in the first week URL: https://axiointelligence.com/blog/quietly_cutting_cloud_bills Published: 2026-05-12 · Author: Brice Ayres · Tags: FinOps, AWS, cost reduction, Kubernetes Short answer: Most cloud waste hides in orphaned resources, forgotten environments and over-provisioned workloads, not where leadership expects. In the first week we inventory every billable resource (typically 5–15% of the bill is things that should have been turned off), right-size the top spenders from 30 days of p95 data, and only then decide on savings plans and spot. The result is a cut-now, cut-next and guardrails list delivered as pull requests. Every cloud cost engagement starts the same way: finance is alarmed, engineering is defensive, and nobody has a complete picture of what's actually running. This isn't because engineers are sloppy. It's because cloud spend grows in the seams between teams, between environments, and between the things people built and the things they forgot to turn off. Almost every time, the waste is somewhere different from where leadership thinks it is. Here's the rough playbook we run in the first week of a typical cost engagement, and what we usually find. ### Day 1–2: where is the waste hiding? The first thing we do is build an inventory of every billable resource, tagged by service, environment, owner, and last-touched. Most teams don't have this. They have a billing dashboard, which is not the same thing. What we're looking for: - **Orphans.** RDS replicas attached to a primary that was migrated two years ago. ELBs pointing at deregistered targets. EBS volumes not attached to any instance. NAT gateways nobody can explain. - **Untagged sprawl.** Resources without owners. If nobody owns it, nobody will turn it off. We start here because it's almost always cheap to delete. - **Forgotten environments.** A staging cluster that's been at production scale since a load test in 2023. A dev account someone spun up for a POC three roles ago. This inventory work isn't glamorous. It is reliably 5–15% of the bill, just from things that should have been turned off and weren't. ### Day 3–4: the workloads that are wrong-sized This is where engineering teams usually get tense, because it feels like a critique. It's not. Workloads are almost always over-provisioned because the cost of being wrong in the other direction is a 3am page. We look at p95 CPU, p95 memory, and request patterns over 30 days for the top spenders. We're trying to answer: - **Are you paying for the worst case all the time?** Most workloads have a 2–4x spread between average and peak. Autoscaling — real autoscaling, not "we have an ASG configured" — closes most of this. - **Is your compute the right shape?** Memory-optimized instances running CPU-bound workloads. GPU instances doing CPU work. ARM workloads on x86 because Graviton wasn't a thing when the instance type was picked. - **Is your storage tier right?** EBS gp2 vs gp3 alone is usually a 20% storage savings. S3 standard for cold archival data. Logs in CloudWatch instead of S3 with a lifecycle policy. This is also where we usually find Kubernetes clusters running at 18% utilization with no horizontal pod autoscaler, no cluster autoscaler, and node groups sized for a peak that happens 4 hours a week. ### Day 5: the commitment + spot conversation Once we know what your actual baseline is, we can talk about reserved instances, savings plans, and spot. This conversation in the wrong order is what gets people stuck on 3-year commits for the wrong instance families. Rough heuristic: anything that runs 24/7 should be on a savings plan. Anything stateless and tolerant of interruption should be on spot. Anything with predictable bursts can usually move to scheduled scaling. For Kubernetes specifically: Karpenter on spot, with a small on-demand base, will typically take a node bill down 50–70% with almost no operational change. ### What we ship at end of week one A short document with three sections: 1. **Cut now.** Things we'd delete or resize today. Usually 15–25% of the bill, often more. 2. **Cut next.** Architectural changes that take a few weeks but compound. Spot migration, Graviton, storage tiering, data egress. 3. **Stop the bleed.** Guardrails so the waste doesn't grow back. Budget alerts per team, anomaly detection, tag enforcement, a quarterly review cadence. The handoff isn't "here's a slide deck." It's PRs against your Terraform, a tagging policy, a budget dashboard, and a list of "next" items prioritized by dollars saved per engineering hour. ### What we don't do We don't run optimization tools that promise to do this in the background. They're a great way to get a 5% improvement and feel like you're done. The actual savings — the 30–50% — comes from looking at workloads as an engineer who understands what they do, not as a script looking at metrics. If your cloud bill has quietly become someone's full-time problem, this is [the kind of thing we do](https://axiointelligence.com/services/cloud-cost-reduction). ## Migrating clouds without the migration freeze URL: https://axiointelligence.com/blog/migration_without_downtime Published: 2026-04-18 · Author: Brice Ayres · Tags: migration, AWS, GCP, Postgres, infrastructure Short answer: Cloud migrations finish on time when there is no cutover weekend. Map everything you run first, migrate one small slice to prove the supporting pieces, move stateful services through dual writes and shadow reads, shift traffic gradually at the load balancer, and turn the old system off two weeks after it stops taking traffic. For a company with about a dozen services, plan on 8–14 weeks while the team keeps shipping features. The reason most cloud migrations slip is that they're scoped as an event. A weekend. A holiday. A window where the team can take a deep breath, flip the switch, and pray. We don't run them that way anymore. After enough migrations, the pattern is clear: the projects that finish on time are the ones where there is no cutover weekend at all. The new system runs alongside the old one for weeks, taking progressively more traffic, until the old system has nothing left to do and you turn it off on a Tuesday afternoon. Here's how we structure it. ### Step 1: forget about the destination for a minute Before we talk about which cloud to move to, we map what you actually have. This sounds obvious. It isn't. Most teams have a partial picture: the services they ship are well-understood, but the queues, jobs, dashboards, and integrations that grew up around them are not. We've inherited migrations that were 80% done when someone discovered a Lambda that nobody owned was pushing critical reports to a third-party SFTP server. The deliverable for this phase is a single diagram and a CSV. The diagram shows every running thing and what it talks to. The CSV lists every billable resource and its owner. If nobody owns it, that's a finding. ### Step 2: pick the smallest viable first slice The most common failure mode is "let's lift-and-shift everything, then optimize later." This works on whiteboards. It fails in practice because you're moving everything at once and you have to coordinate everyone at once. Instead, we pick a slice. Usually it's: - One stateless service - Its database (or a logical subset) - The CI pipeline that ships it - The monitoring + on-call wiring The slice has to be small enough to ship in 2–3 weeks, and complete enough that you can actually run it in production on the new cloud. The point isn't to migrate this service — it's to prove out every supporting piece (IaC, CI, secrets, observability, network) on something low-risk. ### Step 3: dual-write, dual-read, then cut For services with state, we almost always go through a dual-write phase: 1. **Dual-write.** New writes go to both old and new databases. Reads still come from the old. We run this until backfill of historical data is complete and the two systems are byte-for-byte consistent. 2. **Shadow read.** Reads start hitting both systems. We compare results, log discrepancies, and don't return the new system's data to users. This catches every subtle behavior difference — character encoding, sort order, NULL handling — without anyone noticing. 3. **Flip reads.** Move the read source. The old database is now a hot backup. 4. **Stop writing to the old.** Now you can decommission on your own time. For Postgres specifically: logical replication via `pglogical` or AWS DMS, with row-level consistency checks. For Mongo, change streams. For event-sourced systems, replay from your event log and dual-publish. The point is that at every step, you can roll back to the previous state in seconds, not hours. ### Step 4: traffic shifting at the edge Once a service has its new home, we shift traffic gradually at the load balancer or DNS layer. Usually: - 1% for an hour - 10% for a day - 50% for a few days - 100% If anything goes sideways, the rollback is moving the weight back. There is no "let's revert the deploy and restore from backup." This is also where we catch the long-tail issues you couldn't catch in staging: cold caches, region-specific latency, IAM policies that work for the test account but not the production one. ### Step 5: decommission, then prove it A migration isn't done when the new system is taking 100% of traffic. It's done when the old one is off, the bill is gone, and the IaC for it is deleted from the repo. We typically wait two weeks after 100% before we tear things down. After that, the AWS account gets a `terraform destroy`, the IAM users get revoked, and the DNS records get pruned. The PR to remove the old code is sometimes the most satisfying one in the whole project. ### How long does a cloud migration take? A reasonable benchmark for a single-product company with a moderately complex backend (a dozen services, two databases, a queue or two, a frontend, and CI/CD): **8–14 weeks**, with the team continuing to ship features the whole time. What blows that estimate is almost always the same thing: undocumented dependencies discovered halfway through. The inventory step is the cheapest insurance you can buy. If you're staring at a migration plan that has a single weekend cutover on it, we'd recommend re-scoping it. There's no reason to take that risk. Here's [how we run migrations](https://axiointelligence.com/services/legacy-modernization). ## Infrastructure-as-code that survives the team that wrote it URL: https://axiointelligence.com/blog/iac_that_survives_the_team Published: 2026-03-22 · Author: Brice Ayres · Tags: IaC, Terraform, OpenTofu, platform engineering Short answer: Terraform and OpenTofu codebases rot because of their architecture, not the tool. Split state by blast radius, write modules only for real repeated patterns, keep state in a locked remote backend with no applies from laptops, post a plan on every pull request, run drift detection, and limit policy-as-code to a few guardrails. The test is whether a new senior engineer can ship a safe change in their first week without asking anyone. We've inherited a lot of Terraform. The pattern is depressingly consistent: a repo started by a founder or an early platform engineer who knew exactly what they meant, then accreted layers as the team grew, then became something nobody wanted to touch. It's never the tool's fault. It's the architecture. Here's what we've found makes the difference between IaC that ages well and IaC that becomes a museum. ### The single biggest mistake: one-state-to-rule-them-all A surprising number of teams keep everything — networking, databases, IAM, apps, secrets — in a single Terraform state. It works for a while. Then: - A plan takes 4 minutes - An apply locks the state for everyone - One person's change to a Lambda blocks the database team - A `terraform destroy` becomes impossible to reason about The fix is boring: **split state by blast radius**. Things that change together stay together; things that don't, don't. A typical layout we use: ``` stacks/ platform/ # VPC, subnets, IAM baseline, KMS, route53 data/ # RDS, Redis, S3 buckets, replication shared-services/ # observability, secrets, service mesh apps/ api/ worker/ web/ ``` Each stack has its own state. Cross-stack dependencies go through `terraform_remote_state` or, better, a small set of well-known SSM parameters or Secrets Manager entries. Apps don't know how the VPC is built; they just ask for the subnet IDs. This one change — splitting state — typically cuts plan times by 10x and lets multiple engineers work in parallel without stepping on each other. ### Modules, not abstractions The second pattern that hurts is the urge to wrap everything in a custom module. "We don't want people writing raw `aws_instance` resources." So now there's a homegrown `company_ec2_instance` module that's a thin wrapper around the AWS one — with three opinions baked in and twelve variables that nobody understands. A year later, somebody needs to do something the module doesn't support. They open the module, get confused, copy-paste-modify it inline, and now you have three slightly different versions of the same thing. Our heuristic: write modules where you have a real, repeated pattern that benefits from being named — a microservice, a Postgres cluster with the team's standard backup config, an EKS node group with the right tags. Don't write modules to "wrap" upstream resources. The upstream provider is fine. ### Where should Terraform state live? If your team has more than two engineers, your state belongs in a remote backend with locking. S3 + DynamoDB works fine. Terraform Cloud, Spacelift, or Env0 work better — they give you per-PR plan visibility and a permission model. Whatever you pick: nobody applies from their laptop. Period. The mental shift is: the IaC repo isn't a script you run, it's the source of truth that an applier acts on. PRs run plans. Merges run applies. State doesn't live on anyone's machine. ### The pre-merge `plan` is your code review Every PR should post a plan output as a comment. Atlantis, Terraform Cloud, and Spacelift all do this out of the box. Once you have it, your reviewers can actually see what's about to happen — not just what the HCL says, but what AWS is about to do. This single feedback loop catches more would-be incidents than any policy-as-code framework. It's also how junior engineers learn what their changes mean. ### Drift detection isn't optional Manual changes in the console will happen. Somebody will be on-call at 2am, fix a thing, and forget to bring it back into code. Without drift detection, your IaC is silently lying to you, and the next person to plan in that area is going to get a surprise. Cheap version: a nightly scheduled job that runs `terraform plan` and posts to Slack if anything's drifted. Better version: drift detection in Terraform Cloud / Spacelift with auto-remediation policies. ### Policy-as-code, applied lightly OPA / Sentinel are great. They're also great at making your platform team into the bottleneck if you over-rule them. The policies that have paid for themselves in our work: - No public S3 buckets without an explicit `:public` tag - No security groups with `0.0.0.0/0` on non-HTTPS ports - No resources without an `owner` tag - No RDS without backups enabled That's it. Three or four guardrails that catch real mistakes. Save the rest for after the team is mature enough to want them. ### Handoff is part of the work When we finish an IaC rewrite, we don't just hand over a repo. We hand over: - A README that explains the layout in two pages - A "how to do common things" doc — add a service, add a queue, rotate a secret, bootstrap a new env - An onboarding PR that a new engineer can use to learn by doing - A decision log (`docs/decisions/`) explaining why things are the way they are The test for a good IaC codebase is: can a new senior engineer ship a safe change in their first week, without asking anyone? If yes, you're done. If no, the work isn't finished. It's the bar we hold our own [infrastructure-as-code work](https://axiointelligence.com/services/cloud-infrastructure-iac) to. ## Kubernetes, the boring way URL: https://axiointelligence.com/blog/kubernetes_the_boring_way Published: 2026-02-14 · Author: Brice Ayres · Tags: Kubernetes, EKS, GitOps, platform engineering Short answer: A production Kubernetes cluster that a team of eight can run without a dedicated platform engineer needs a managed control plane (EKS, GKE or AKS), one cluster per environment and region, Terraform or OpenTofu for the bootstrap, and GitOps with ArgoCD or Flux for every change after that. Keep secrets in a real secret manager through External Secrets Operator, give every service metrics, logs and traces by default, and upgrade one minor version per quarter. Kubernetes is not a problem. Kubernetes set up by someone who's no longer on the team is a problem. Most of the k8s clusters we inherit have the same two flaws: they were assembled from a hundred good blog posts, and the person who assembled them is gone. The cluster runs, mostly. Upgrades terrify everyone. Nobody can quite explain why ingress works the way it does. Here's the stack we default to when we bootstrap a cluster, and the rules of thumb that come with it. The goal is a cluster a team of 8 can run without a dedicated platform engineer. ### The base - **Managed control plane.** EKS, GKE, or AKS. Self-managed control planes are a discipline. Most teams don't need that discipline. - **One cluster per environment, per region.** Not one cluster with namespaces for prod/staging/dev. The blast radius and IAM boundaries are too important. - **Node pools split by workload.** A general pool, a memory-intensive pool, a spot pool for stateless workloads. Use Karpenter (EKS) or the native cluster autoscaler. Don't pre-size for peak. ### Bootstrap with IaC, then never touch it manually The cluster, node groups, IAM, networking, KMS keys — all in Terraform/OpenTofu. The in-cluster bits — controllers, ingress, monitoring agents — installed via a bootstrap pipeline that the IaC kicks off. After bootstrap, the only thing that changes the cluster is GitOps. `kubectl apply` from a laptop is forbidden. If you can't do it through a PR, you don't do it. ### GitOps with ArgoCD or Flux We use ArgoCD more often because the UI is helpful when you're explaining the system to a new team member. Flux is great if you prefer everything to be CRD-driven and don't need the dashboard. The structure we like: ``` gitops/ apps/ # one folder per app, with kustomize overlays per env api/ base/ overlays/ staging/ prod/ platform/ # cluster-wide things cert-manager/ external-dns/ ingress-nginx/ kube-prometheus/ ``` ArgoCD watches the `apps/` and `platform/` paths. Engineers ship by opening a PR against the overlays. Promotions between environments are PRs, not buttons. ### Ingress: pick one, stop arguing `ingress-nginx` is the boring choice and the right choice for most teams. AWS Load Balancer Controller if you specifically want ALBs per ingress. Don't run three ingress controllers because three different teams had opinions on the same week. If you genuinely need a service mesh — and most teams don't — Linkerd. It has the lowest operational tax of any mesh we've run. ### Where should Kubernetes secrets live? Don't use Kubernetes Secrets as your secret store. Use a real secret manager (AWS Secrets Manager, GCP Secret Manager, or Vault) and pull into the cluster via External Secrets Operator. This way: - Rotation happens in one place - Audit logs are real - Compromising kube doesn't compromise everything ### Observability The default we ship: - **Metrics:** Prometheus + Grafana, deployed via `kube-prometheus-stack`. One Grafana per cluster, federated up if you have many. - **Logs:** Loki or whatever your team is already paying for (Datadog, Splunk, etc). Don't run your own Elasticsearch unless logs are your business. - **Traces:** OpenTelemetry collector → your tracing backend of choice. The point isn't the tools. The point is that on day one, every new service automatically gets metrics, logs, and traces without the team having to opt in. ### How often should you upgrade Kubernetes? The single most important question we ask a team that has Kubernetes: "what's your upgrade story?" If the answer is "we'll figure it out when we have to" — they're going to have a bad time. Kubernetes ships a new minor version every four months and EOL'd versions get scary fast. Our default: 1. **Cadence:** upgrade one minor version per quarter. 2. **Process:** dev → staging → prod, one week apart each, with a checklist. 3. **Documentation:** every upgrade gets a one-page runbook of what changed and what broke. The first upgrade is painful. The third one is boring. That's the goal. ### Hardening: enough to sleep at night - Pod Security Standards (`restricted` for app namespaces) - Network policies that default-deny ingress between namespaces - IRSA / Workload Identity instead of node-level IAM - Audit logging shipped off-cluster - A schedule for re-running CIS benchmarks You don't have to be CKS-certified to run a safe cluster. You do have to do these five things. ### What this gets you A cluster a small team can run for a year without major incidents. Upgrades that take an afternoon instead of a sprint. A platform that new engineers can understand from a README, not from interviewing the founder. If your Kubernetes setup currently requires the founder to operate it, that's the kind of [cleanup we do](https://axiointelligence.com/services/devops-sre).