Hamilton AI upgraded to production-grade infrastructure with a lean team
Founded
2024
Industry
Private Aviation
Migrated from
Railway
Hamilton AI is on a mission to modernize private aviation, a $30 billion industry still running on decades-old software. Their AI platform ingests every customer email, call, and product interaction and turns it into actionable intelligence for operators and brokers, in real time, at volume. They do it with a small, fast-moving engineering team and a clear philosophy: do more with less.
That philosophy set two requirements for their infrastructure. First, it had to be production-grade. In private aviation, response time is a competitive advantage. An operator who doesn't quote before their competitor does loses the deal, and a thousand flight requests can hit the platform at once. Reliability was a product requirement, not an operational detail. Second, it had to stay out of the way. A lean team can't afford to spend its time managing infrastructure when that time belongs to the product.
For Div Shekhar, Founding Engineer at Hamilton AI, those two requirements were really one. "We have a lean engineering team that's moving fast, so every hour spent managing infrastructure is an hour not spent on the product."
The stack had to match the stakes
Hamilton built their stack to answer both requirements. They run web services for customer-facing logic, workers for backend processing, Postgres for structured data, and Redis for the state and queue operations that feed pipelines running continuously in the background. Production-grade sets strict demands. Low latency was critical, and because they depend on AWS, keeping the entire stack in the same region was non-negotiable so services could communicate at millisecond speeds without penalty.
But a serious stack run by a lean team carries a second demand. Anyone on the team has to be able to run it. Div needed clear feature boundaries, predictable behavior, and low support friction. He wanted a platform where any engineer could understand and operate the whole system without a dedicated infrastructure specialist.
Production-grade reliability set the baseline everything else got measured against. Staying lean made that baseline hard to hit. The platform had to deliver both.
Empowering operators and brokers to streamline workflows, automate sales funnels, and optimize trip management.
Not every platform is built for production
Hamilton started on Railway. It seemed sufficient for an early-stage codebase, but as data volume grew and the product matured, the cracks showed. As Div puts it, "Railway wasn't the place to run a serious production business."
The recurring problem was visibility. Div explains, "The platform rarely told us what was actually happening." The visual canvas for arranging services sounded like a nice idea, but in practice it consumed half the screen without offering much functional value. The logging itself compounded the problem. Deploy timestamps showed commit times rather than deploy completion, making it nearly impossible to correlate a bug with a deploy, and commits would occasionally fail without a word. When autoscaling kicked in, it gave no signal about why. It never showed whether an instance had moved, a workload had spiked, or something had genuinely gone wrong.
The pattern pointed to something deeper. Div says, "Railway made product decisions that revealed a limited understanding of what production operations actually require." And the issue that ultimately forced the move was architectural. Railway's data centers sat decoupled from AWS, so every operation between Hamilton's app layer and its data dependencies crossed an unnecessary network boundary. No serious production workload could absorb that penalty at Hamilton.
What production-grade looks like
Div had evaluated cloud platforms before joining Hamilton, and Render had stood out for operational clarity, deploy speed, and a UI that surfaced exactly what engineers needed. When he saw what Railway was costing the team in lost time and added latency, the answer was clear. Render's proximity to AWS sealed it. Hamilton's stack could stay in the same region, and the network penalty that had forced the move disappeared.
The team migrated in early 2025 without friction. They moved their services over and found the operational experience exactly as Div remembered: clear, fast, and dense with the information they needed to run production workloads confidently. "The Redis latency that had been climbing into the tens of milliseconds dropped to a few milliseconds the moment we cut over," Div says.
For the first time, the platform told them what was happening. For example, Render made autoscaling observable. Using Render's API, the team scripted scaling logic for their background workers to match Hamilton's business-hours pattern. Instances scale down on nights and weekends and back up when demand returns. Predictable, and fully under their control.
“We have a lean engineering team that's moving fast, so every hour spent managing infrastructure is an hour not spent on the product.”
Render gave Hamilton’s team production-grade reliability while keeping their team lean and high-velocity. No platform hires, no Kubernetes specialists. Any engineer on the team could operate the entire stack.
That meant adopting good infrastructure practices without the overhead that usually comes with them. The team wanted IaC for repeatability but without the complexity of managing Terraform or Kubernetes. As Div put it: "Render Blueprints is the right balance. You get the infrastructure-as-code discipline without the overhead of Terraform or Kubernetes. For a team our size, that matters."
Every cycle the team saved on infrastructure went back into the product. As Div noted: "Every hour not spent debugging a black-box autoscaler, investigating a misleading timestamp, or untangling a deployment failure is an hour towards the product that Hamilton's customers are paying for."
A foundation for what comes next
Hamilton AI is growing. New customers, faster shipping, and harder engineering questions. Chief among them is what happens when AI-generated code outpaces the team's capacity to review it.
Div and the team know it demands a new way of thinking about sandboxing, environment management, and quality control. They have been exploring isolated, firewalled spaces where new models and agentic workflows can run without touching production. That kind of discipline keeps a lean team in control as complexity compounds.
Render sits at that abstraction layer. The infrastructure complexity stays below. Hamilton's engineers stay focused on the product above, and on the industry they set out to modernize.
