Time-critical logistics is an industry where minutes matter and a missed handoff can mean a missed surgery, a stalled production line or an aircraft stuck on the ground. It’s also an industry that has run on phone calls, spreadsheets and decades-old systems for a long time. Airspace’s goal from day one has been to bring cutting-edge technology to that world.
Lately, one of the biggest accelerators in that mission hasn’t just been new routing algorithms or new integrations. It’s been the way we build software. AI-assisted development is letting us ship features faster than ever, and it’s changing who can take part in building them.
This post covers Airspace Labs, an internal platform that lets anyone at Airspace take an idea from “what if…” to a running, secure, properly managed application.
Great ideas don’t only come from the engineering org
We’re lucky to have some of the best developers in the world, and a company full of people who care deeply about our customers and operations. The dispatcher who has watched the same manual workaround a hundred times knows exactly what tool would fix it. So does the account manager who keeps fielding the same report request.
Those ideas come from everywhere. The challenge is focus, not talent or headcount. Our engineering teams are rightly concentrated on the work that moves the needle for every customer at once. A tool that saves one team five hours a week is worth building, but it’s hard to justify pulling a senior engineer off a customer-facing roadmap item to build it. Too often, good ideas sat in a backlog waiting for a gap in the schedule. We wanted a better answer.
AI changed who can build software and introduced new risks
AI-assisted coding tools have democratized engineering like never before. A motivated person with a clear idea and a coding agent can now produce a working web app in an afternoon. People outside product and engineering can deliver real engineering value, not just mockups and feature requests.
It also comes with real risk.
- Open, unauthenticated endpoints reachable by anyone on the internet.
- Insecurely managed secrets, like API keys in source code and production credentials shared over chat because “it’s just a quick prototype.”
- Life outside our unified infrastructure, with no central logging and no one on the infrastructure team aware the app exists.
- No ongoing maintenance, meaning no CVE monitoring and no dependency updates. A library that was safe in March might be a liability by June.
The easy response would be to lock everything down. But that would throw away one of the most valuable things AI has unlocked: the world-class minds of our dedicated, passionate employees, ready to solve the problems they see every day. So we made the safe path the easiest path.
Introducing Airspace Labs
Airspace Labs is our self-service prototype platform. Anyone at Airspace can deploy a working application in a few clicks onto the same managed infrastructure our engineers use. The builder brings an idea and some code, usually written with an AI coding assistant. Labs handles hosting, a URL, TLS certificates, single sign-on, databases, notifications and cleanup. Nobody files an infrastructure ticket or learns Kubernetes.
Guardrails for AI-assisted development
The heart of Labs is a set of guardrails every prototype must meet. AI agents write much of the code so the guardrails are aimed at AI agents too.
- Secret scan · verified credentialsQueued
- Secret scan · patternsQueued
- CVE scan · dependenciesQueued
- CVE scan · container imageQueued
- Static analysis · OWASP Top TenQueued
- Software bill of materialsQueued
- Automated dependency updatesQueued
- Non-root containerQueued
An agent briefing in every repo
Every prototype starts from our template repository which includes a briefing written specifically for AI coding agents like Claude Code or Cursor. The agent knows our rules from the first prompt: how to structure the app, what never to hard-code and what “done” means.
Security scanning that blocks the merge
Every prototype repo runs the same layered baseline as our production services. That means secret scanning on every commit, CVE scanning of dependencies and container images, static analysis against the OWASP Top Ten, a software bill of materials for every build and automated dependency updates. Nothing reaches main until the checks pass.
A pre-flight check before anything deploys
Labs scans the repository before a prototype can be created. If a required security gate is missing or failing, the create button stays disabled.
Authenticated by default
Every prototype sits behind company single sign-on. If one genuinely needs a public endpoint, such as a webhook receiver, the builder can open specific, narrowly scoped paths while everything else stays locked down. Broad patterns are rejected, and builders get a plain-English risk checklist before opening anything.
Secrets handled properly
API keys and other sensitive values are write-only, stored in the prototype’s own secure storage and audit-logged whenever revealed.
Isolation between prototypes
Each prototype runs under its own identity with access only to its own resources, enforced by cloud permissions rather than application code.
The result is that a prototype built by someone in operations gets the same security posture as a service built by our platform team and nobody had to become a security expert to get there.
Real integrations without real credentials
Most useful internal tools need to talk to the Airspace platform. That’s where prototypes have historically gotten dangerous, because the fastest way to get data is to borrow a production or staging API key from someone who has one.
Labs removes that temptation. A builder can deploy a Preview App alongside their prototype. That’s a scaled-down, self-contained copy of our core production services, loaded with test data and spun up just for that prototype. Labs wires the two together automatically, injecting service addresses and credentials directly into the app’s configuration. The builder never handles a production or staging key and the Preview App is torn down when the prototype goes away.
Infrastructure on a checkbox
The infrastructure a prototype needs is a checkbox in the setup wizard. Options include PostgreSQL databases (shared or dedicated), Redis for caching and queues, cloud storage buckets and scheduled jobs. Labs provisions each resource, scopes access to that one prototype and hands the connection details to the app automatically. There’s no infrastructure-as-code to write and no tickets to file.
Built to expire (unless you need more time)
A prototype is meant to be an experiment so every prototype has an expiration date between 7 and 90 days out. Owners get email and Slack reminders as the date approaches. Extending takes one click. Otherwise, Labs cleans up on schedule, removing everything deployed with the application, including its database, cache, storage and Preview App.
Every company has a forgotten experiment still running, still costing money and still exposed, two years after its author moved on. In Labs, abandoned prototypes clean themselves up.
Graduation: from prototype to production
Some prototypes outgrow the “experiment” label. Real users depend on them, other teams want to integrate with them and a 90-day lifespan isn’t enough. For those, Labs offers graduation, a guided path to a fully supported production service.
- Request and approve. The owner names the production service, identifies the engineering team that will own it and chooses whether to migrate data. The infrastructure team gives it a brief review and approval.
- Generate and check. Labs uses the prototype’s configuration as a blueprint to write a complete infrastructure-as-code changeset, covering the service, data stores, identity-aware access, DNS and monitoring. A policy engine verifies the plan only creates approved resources within the new service’s scope. Anything unexpected is escalated to a human, never forced through.
- Build and verify. The production environment is built automatically and Labs confirms it’s healthy before the final step unlocks.
- Cut over. Labs migrates the prototype’s data into production and points the old URL at the new home.
The graduated service ends up indistinguishable from one our engineers built by hand. It’s fully managed as code, monitored and owned by a real team.
What this means for Airspace
Airspace Labs lets us say “yes” to more ideas without saying “yes” to more risk.
Our engineers stay focused on the work only they can do. People closest to the problem get to build. Every prototype runs on our infrastructure, behind our authentication, with our scanning and our cleanup. And when an experiment proves itself, the path to production is already paved.
Airspace Labs was conceived and built by Alan Orther, our Staff Engineer – Infrastructure. It’s a fitting origin story: an infrastructure engineer who built the platform so that everyone else at Airspace can ship real software without having to become one.
Time-critical logistics has waited a long time for modern technology. With AI-assisted development and the right guardrails around it, we’re delivering it faster than ever, and the ideas behind it are coming from every corner of Airspace.