Calgary Energy Tech and Offshore Engineering Teams: A Match Made in the Cloud

A developer with over a decade of experience building offshore teams for energy clients says Calgary's energy sector must modernize its mindset, not just its tech, to stay competitive. The engineer recounts helping an oilfield services company cut data entry errors by 80% and save $100,000 annually by moving from Excel to a cloud-based system, and building a renewable energy platform with a senior offshore team in the Philippines for $400,000, a fraction of the local cost.

I was on a call with a Calgary-based oil and gas client at 2 AM my time, trying to explain why their monolithic .NET Framework application, running on an on-prem server that hadn't seen a patch in three years, was causing their new cloud-native features to crash. They thought "cloud" meant buying a beefier server. This isn't an isolated incident. Calgary's energy sector has a unique opportunity, and a unique challenge, when it comes to modern engineering. The energy industry is under immense pressure to innovate, reduce costs, and improve efficiency. Digital transformation isn't a buzzword anymore; it's a survival imperative. For Calgary, a city built on traditional energy, embracing new engineering paradigms and talent pools, including offshore teams, is critical to staying competitive and attracting the next generation of tech leaders. The skills needed to build the future of energy – AI for exploration, IoT for operational efficiency, advanced simulation – are global, and so is the talent. The biggest hurdle I consistently see in Calgary's energy tech scene isn't the tech itself, it's the mindset. I worked with a well-established oilfield services company that wanted to modernize their field data capture. They were still using Excel spreadsheets emailed back and forth, with a SQL Server database that was updated weekly by a junior admin. When I proposed a cloud-based solution using Azure SQL Managed Instance and a React frontend with Azure Functions for the backend, the pushback wasn't about cost or complexity, it was about "how do we do it the way we always have?" They had a massive investment in their existing processes, which were deeply embedded in how their engineers and field staff operated. The fear of disruption was palpable. We spent months just on change management, showing them how a simple mobile app could eliminate duplicate data entry, reduce errors by 80%, and provide real-time insights. It took a pilot project, focusing on a single, high-pain area equipment maintenance logs , to break the dam. We used Azure DevOps for CI/CD, and the initial rollout for that pilot was to 50 users. The feedback loop was immediate: "This is so much faster." The eventual savings in manual data processing alone were estimated at $100,000 annually. The lesson: Modernizing tech is easy. Modernizing people's workflows and mental models is the real battle. I’ve built and managed offshore teams for clients across North America and Australia for over a decade. When a Calgary-based renewable energy startup approached me to build their distributed energy resource management platform, they were hesitant about offshore. Their initial thought was cost reduction. I told them, "You're looking at it wrong. You're not looking for cheaper developers; you're looking for more developers with specialized skills that are scarce locally, at a competitive rate." We ended up building a core team in the Philippines. This wasn't about finding junior devs to do grunt work. We hired senior backend engineers with deep experience in Elixir and Phoenix a functional programming stack ideal for handling real-time data streams , and a frontend lead who was an absolute wizard with SvelteKit. The client, based in Calgary, had a lead architect and a product owner. The offshore team handled the bulk of the development, testing, and deployment. We used Slack for daily stand-ups and asynchronous communication, Jira for task management, and GitHub for code reviews. The platform, which manages thousands of solar and battery installations, was built in 18 months with a total engineering spend of around $400,000. This would have easily been $1 million+ with a purely local team, and frankly, finding that depth of Elixir/Phoenix talent in Calgary would have been a multi-year struggle. The key is to hire for skill and experience, not just location. Treat them as an extension of your team, not a separate entity. This one burns. I had a client in the oil and gas sector, let’s call them PetroSolutions, who had a massive on-prem Oracle database. They decided to "move to the cloud" by lifting and shifting their Oracle instance to an EC2 instance on AWS. They paid a fortune for the AWS compute, the Oracle licenses, and the data transfer. Six months later, they were paying more than they were on-prem and their application was still slow. They called me in a panic. The problem? They hadn't re-architected. They were still running a monolithic application that was tightly coupled to the database. They hadn't embraced microservices, serverless functions, or managed cloud databases. They were paying for "cloud" but still thinking like an on-prem shop. We spent the next year refactoring their core application. We broke down services into smaller, independent units deployed on AWS ECS Elastic Container Service with Fargate. We replaced parts of the Oracle database with Amazon Aurora PostgreSQL for new microservices and used AWS Lambda for event-driven processing. We implemented a Kafka-based event bus for inter-service communication. The result? A 60% reduction in infrastructure costs, a 3x improvement in application performance, and the ability to scale individual services independently. The lesson: "Cloud-native" isn't a destination; it's a way of building. It means embracing services, elasticity, and fault tolerance from the ground up. Simply moving your old stuff to a new data center doesn't make it cloud-native. I would skip trying to build everything in-house from day one. When I started, I felt this immense pressure to have every single piece of the puzzle myself. Build the UI, build the backend, manage the database, deploy it. It’s a recipe for burnout and slow progress. Today, I’d lean heavily on managed services and well-vetted third-party APIs for anything that isn’t core to my unique value proposition. For example, if I were building a new energy trading platform, I wouldn't build my own real-time market data ingestion pipeline from scratch. I'd integrate with a reputable provider like Refinitiv or Bloomberg. Similarly, for authentication, I’d use Auth0 or AWS Cognito instead of rolling my own. This frees up my team to focus on the complex, differentiating problems, and it dramatically speeds up time-to-market. I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.