DEV Community: DevWithZach

Edmonton Founders: Stop Hiring Local, Start Building Across Timezones

DevWithZach — Mon, 17 Aug 2026 08:00:25 +0000

Edmonton Founders: Stop Hiring Local, Start Building Across Timezones

I remember a founder in Edmonton, let's call him "Mark," telling me he was struggling to find senior backend engineers. He'd spent months interviewing locally, burning through thousands in recruitment fees, and still felt like he was settling. The irony? He was sitting on a goldmine of talent just a few flights (or a VPN connection) away.

Why this matters in 2026

Edmonton's tech scene is growing, but the demand for experienced engineers, especially in specialized fields, often outstrips local supply. Founders trying to build complex products like SaaS platforms or AI-driven applications face a bottleneck. The global talent pool isn't just an option anymore; for many, it's the only realistic path to building a strong, competitive engineering team.

Three things I learned shipping this

1. Timezones are a Feature, Not a Bug (When You Plan For It)

When we were rebuilding Tokkatok's V2, we had a core team in Manila and a product lead in Canada. My initial thought was, "This is going to be a nightmare for communication." I was wrong. We structured our sprints so that the Manila team would finish their work day, push code, and the Canadian team would pick it up first thing in their morning. Code reviews happened overnight for one team and during their day for the other. It wasn't about synchronous meetings; it was about asynchronous handoffs and clear documentation.

We used Jira religiously, not for the sake of it, but to ensure every task had a clear description, acceptance criteria, and any necessary context. When a developer in Manila would push a feature, they'd leave detailed notes for the Canadian team about what to test and what to look for. This forced clarity reduced bugs and sped up our release cycles. We shipped the entire V2 rebuild in 8 months, a feat that would have taken us longer with a purely co-located team due to scheduling meetings and the inevitable "quick chat" that turns into an hour.

Here's a snippet of how we’d structure a ticket for that handoff:

// In Jira ticket description
/*
 * Feature: User Profile Update API Endpoint
 *
 * Status: Ready for QA/Review by Canadian Team
 *
 * Description:
 * Implemented PUT /api/v2/users/{userId}/profile endpoint.
 * Handles validation for email, name, and bio fields.
 * Includes error handling for invalid input and non-existent user.
 *
 * Code changes:
 * - src/api/users/profile.js
 * - src/services/userProfileService.js
 *
 * Testing Notes:
 * - Test with valid data.
 * - Test with invalid email format.
 * - Test updating a non-existent user ID.
 * - Ensure response codes are correct (200, 400, 404).
 *
 * Next Steps:
 * - Awaiting review and deployment to staging.
 */

2. Invest in Asynchronous Communication Tools (and Train Your Team)

This is where most companies trip up. They hire across timezones and then expect everyone to be in Slack at the same time, or to jump on a Zoom call on short notice. That's a recipe for burnout and resentment. For LaundryIT, our remote team was split between the Philippines and Australia. We learned to rely heavily on tools that supported asynchronous work.

We used Loom extensively for demos and explanations. Instead of typing out a lengthy email about a bug, a developer would record a quick 2-minute video showing the issue and narrating their thought process. This was far more effective and saved countless hours. For documentation, Confluence was our go-to, but the key was making it a habit for everyone to update it. If you fix a bug, document the fix. If you implement a feature, document how it works. This created a living knowledge base that reduced reliance on synchronous Q&A.

We also implemented a "no meeting before 10 AM and after 4 PM" policy for our core overlap hours, which was usually 2-3 hours. This gave people their mornings and evenings back. The result? Higher morale and more focused work. We shipped LaundryIT, a complex inventory and logistics system for laundromats, in 10 months, and the remote team was crucial to that speed.

3. Embrace the "Follow the Sun" Model for Support and Ops

When I was leading the engineering for EngagePOS, a point-of-sale system, we had support staff and critical on-call engineers spread across the US West Coast, the Philippines, and the UK. This was a deliberate strategy to provide near 24/7 coverage. A critical bug reported in the US evening would be picked up by the Philippines team first thing their morning, and by the time they were signing off, the UK team would be starting their day.

This "follow the sun" model for support and incident response significantly reduced our mean time to resolution (MTTR). We were able to address critical issues within hours, not days. The cost savings were also substantial; we didn't need to hire a massive, expensive late-night US support team. Instead, we built a distributed, highly skilled team. For example, a major outage on a Friday night in the US could be fully resolved by Saturday morning Manila time, meaning our US customers woke up to a fixed system without any extra overnight costs for us. We used PagerDuty for on-call scheduling and alerting, and Slack for immediate team communication during incidents, but the planning and handoffs were key.

What I would skip if I started today

I would skip the initial hesitation to hire senior talent purely based on geography. For years, I've seen founders in places like Edmonton default to local hiring because it feels "safer" or "easier." It's neither. The perceived risk of managing a remote team is often outweighed by the sheer availability of top-tier talent elsewhere. You don't need to reinvent the wheel; there are proven frameworks and tools for building successful distributed teams. The real risk is not tapping into that global talent pool and being outpaced by competitors who are.

What this looks like for your team

Define your communication protocols: Before you hire your next remote engineer, decide how your team will communicate asynchronously. What tools will you use? What are the expectations for documentation and status updates? Make this explicit.
Invest in asynchronous tooling: If you’re not already, start using Loom for demos, ensure your documentation platform (Confluence, Notion, etc.) is well-maintained, and train your team on effective asynchronous writing.
Structure your sprints for timezones: Plan your sprint ceremonies and handoffs to accommodate different timezones. Don't force everyone into a single 9-to-5. Think about how work can flow across your team’s days.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.

Ottawa Govtech: Compliance-Friendly PH Development Partnerships

DevWithZach — Mon, 10 Aug 2026 08:00:23 +0000

Ottawa Govtech: Compliance-Friendly PH Development Partnerships

The first time I got a serious call about building for the Canadian federal government, it wasn't about fancy AI or blockchain. It was about Section 508 of the Rehabilitation Act. My jaw dropped. We were in the middle of launching Raketlance, a platform for Filipino freelancers, and suddenly I was deep-diving into accessibility standards written in the late 90s. It felt like going from building a rocket ship to fixing a steam engine.

Why this matters in 2026

Governments worldwide, and especially in North America, are waking up to the fact that their digital services need to be accessible to everyone. This isn't just a nice-to-have anymore; it's a legal requirement. For development teams in the Philippines looking to tap into lucrative government contracts, understanding and implementing these compliance frameworks is no longer optional. It's the gatekeeper.

Three things I learned shipping this

1. Accessibility is Not an Add-On, It's a Foundation

When we first got the Ottawa gig – building a citizen portal for a specific department, let's call it "ServiceCanada Plus" – my initial thought was, "We'll tack on accessibility later." Big mistake. We were using React with a component library that, frankly, wasn't built with strict accessibility in mind. The deadline was looming, and suddenly we had a dozen developers wrestling with ARIA attributes, keyboard navigation, and screen reader compatibility. It felt like trying to retrofit a skyscraper with plumbing after the concrete had set.

The fix wasn't pretty. We had to refactor significant chunks of our UI, often rewriting components from scratch. We ended up investing about 15% more development time than initially scoped, which in dollar terms for a 6-month project with a team of 8, was around $20,000 in unexpected costs. The lesson? Build accessibility in from day one. Use tools like eslint-plugin-jsx-a11y and axe-core during development, not just for final audits.

Here’s a simple check for focus management, a common pitfall:

// In a React modal component
useEffect(() => {
  const focusableElements = modalRef.current.querySelectorAll(
    'a[href], button, input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  if (focusableElements.length > 0) {
    focusableElements[0].focus();
  }
}, []);

This snippet ensures the first focusable element inside the modal gets focus when it opens, crucial for keyboard users.

2. Data Sovereignty and Security are Non-Negotiable

Another client, a US federal agency, had an even tighter set of requirements around data handling. They were building a new data analytics platform and were intensely focused on where data resided and how it was protected. This wasn't just about GDPR or HIPAA; it was about specific US government mandates for data residency and encryption. We were using AWS, and our initial setup was pretty standard. That had to change.

We had to reconfigure our entire VPC architecture. This meant setting up private subnets, using AWS Key Management Service (KMS) for all encryption at rest and in transit, and ensuring our S3 buckets had strict access policies. We also had to prove that no data would leave specific geographic regions. This added complexity and, frankly, cost. We ended up migrating to AWS GovCloud, a region specifically designed for government workloads, which had higher operational costs. For that project, the increased infrastructure spend was about $5,000 per month, on top of the development effort to implement the new security controls.

The key takeaway: understand the data lifecycle and sovereignty requirements before you write a single line of code. Tools like AWS Config and Security Hub become your best friends, but you need to know what rules to apply.

3. Documentation is King, and It Needs to Be Meticulous

With EngageHRIS, we were building a core HR system for a Canadian provincial government body. They had extensive documentation requirements. This wasn't just about API docs; it was about detailed design documents, test plans, security attestations, and even user manuals written to a specific government standard. We initially underestimated the effort involved, thinking our agile documentation practices would suffice. They didn't.

Our usual Confluence pages and READMEs were deemed insufficient. We had to adopt a more formal approach, using tools like Doxygen for code documentation and creating separate, structured documents for architecture, security, and testing. The effort to produce this level of documentation added about 20% to the project timeline and required hiring a dedicated technical writer for the last three months. For a project with a budget of $300,000, this meant an additional $60,000 investment in what felt like "overhead" at the time, but was absolutely critical for sign-off. The lesson: for government work, documentation is not a side task; it's a primary deliverable.

What I would skip if I started today

I would skip the temptation to use overly complex, bleeding-edge frameworks or libraries without a proven track record in regulated environments. While I love pushing the envelope with new tech on projects like Tokkatok's V2 rebuild, for government work, stability, security, and a clear path to compliance are paramount. Stick to well-supported, battle-tested tools and frameworks. If a library doesn't have clear accessibility support or its security model isn't well-documented, it's probably not the right choice for your first government project.

What this looks like for your team

For development teams in the Philippines looking to engage with governments like Ottawa's, here are three concrete steps you can take this week:

Dive into Accessibility Standards: Pick one standard relevant to your target market (e.g., WCAG 2.1 AA for Canada or Section 508 for the US) and spend an afternoon reading the core principles. Integrate an accessibility checker like Lighthouse or axe DevTools into your local development workflow.
Map Your Data Flow: For your current or next project, diagram where all sensitive data will be stored, processed, and transmitted. Identify potential compliance risks related to data residency and encryption.
Formalize Your Documentation: Choose one key deliverable – perhaps your API documentation or a core architectural overview – and rewrite it using a more structured, formal template than you typically would for a startup.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.

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

DevWithZach — Mon, 03 Aug 2026 08:00:24 +0000

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

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.

Why this matters in 2026

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.

Three things I learned shipping this

1. Legacy Systems Aren't Just Old Code, They're Old Habits

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.

2. Offshore Teams Aren't Cheaper, They're Smarter

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.

3. "Cloud-Native" Means More Than Just Hosting

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.

What I would skip if I started today

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.

What this looks like for your team

Audit your current tech stack and identify your "legacy bottlenecks." Is it a monolithic application, an outdated database, or manual processes? Pick one that’s causing the most pain and start there.
Explore offshore talent pools for specialized skills. Don't just look for the cheapest option. Identify the specific expertise you need (e.g., Python for data science, Go for high-performance APIs, Rust for embedded systems) and find teams or individuals who excel in those areas. Use platforms like Toptal, Upwork (with careful vetting), or specialized agencies.
Invest in your communication and collaboration tools. If you're working with distributed or offshore teams, good asynchronous communication (Slack, Teams), project management (Jira, Asana), and code collaboration (GitHub, GitLab) are non-negotiable. Establish clear protocols for updates, code reviews, and problem-solving.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.

Why Canadian SMBs Choose PH Devs Over Indian Outsourcing

DevWithZach — Mon, 27 Jul 2026 08:00:27 +0000

Why Canadian SMBs Choose PH Devs Over Indian Outsourcing

I once had a client in Vancouver, a small chain of car washes called "SparkleWash." They were on the brink of launching a new loyalty app, and their US-based dev team had just imploded – two key engineers quit overnight. The CTO, a guy named Dave, called me at 2 AM PST, utterly panicked. He’d been burned by a massive Indian outsourcing firm before, spending $150k and ending up with a buggy, unmaintainable mess. He needed a miracle, and he needed it fast. He ended up hiring a small, tight-knit team of Filipino developers I recommended, and the app launched six weeks later, on budget, and it worked.

Why this matters in 2026

Canadian Small and Medium Businesses (SMBs) are increasingly looking for reliable, cost-effective engineering talent. While India has long been the go-to for outsourcing, a growing number of Canadian companies are finding better ROI and cultural alignment with development teams in the Philippines, especially for mid-sized projects where a fully in-house team isn't feasible. This isn't about cost alone; it's about communication, cultural nuances, and a shared professional ethos that’s proving more valuable than ever.

Three things I learned shipping this

1. The "Time Zone Arbitrage" Myth and the Reality of Overlap

The biggest selling point for offshore development has always been cost. That’s true, but it’s often sold with the lie of "24/7 development" because of time zones. What I’ve found, especially with Canadian clients, is that true productivity comes not from 24-hour coding, but from meaningful overlap.

When Dave at SparkleWash hired my Filipino team, the critical factor wasn't that they could code while he slept. It was that they had a 3-hour overlap each day. This meant real-time stand-ups, quick question-and-answer sessions, and immediate feedback loops. The alternative, the "follow-the-sun" model where you hand off code at end of day and pick it up the next morning, sounds efficient but often leads to misinterpretations and delays. Imagine trying to explain a nuanced UI change via email or Slack, only to get a response 12 hours later.

My team in Manila, working with Dave’s Vancouver office, used Slack and Zoom extensively. They’d start their day at 9 AM Manila time, which is 6 PM Vancouver time. This gave them that crucial 3-hour window for Dave and his product manager to be available. The rest of their coding happened during their standard workday, but the critical decision-making and clarification happened when both sides were awake and able to talk. This direct communication, even for a few hours a day, saved them weeks of back-and-forth.

2. English Fluency is More Than Just Grammar; It's Nuance

This is where the Philippines often shines over other outsourcing destinations, and it's a massive differentiator for Canadian businesses. It’s not just about understanding technical jargon. It’s about understanding cultural context, idioms, and the spirit of what’s being asked.

I remember a project for a US-based SaaS company, "Proforma," that was trying to build out a new feature for their invoicing software. They’d tried a team in India before, and the feedback was always “they don’t understand the business requirements.” The developers were technically proficient, but they struggled with the subtle implications of certain business rules.

When I brought in a Filipino team, the difference was stark. They asked clarifying questions that showed they understood why a feature was needed, not just what it should do. They’d say things like, "So, if the client is in Ontario, we need to apply HST, but if they're in Quebec, it's GST and QST, right? And the client portal needs to show the breakdown clearly for them." This level of proactive understanding, rooted in solid English comprehension and a grasp of common business practices, is gold. It reduces the need for constant hand-holding and significantly cuts down on scope creep driven by misunderstandings.

Here’s a snippet of how a well-written requirement, understood in context, can lead to better code:

// Example: Handling Canadian Tax Rules in a checkout process
function calculateCanadianTaxes(province, subtotal) {
  const taxRates = {
    AB: 0.05, // GST only for Alberta
    BC: 0.12, // PST + GST for British Columbia
    ON: 0.13, // HST for Ontario
    QC: 0.14975, // GST + QST for Quebec
    // ... other provinces
  };

  const provinceCode = province.toUpperCase();
  if (!taxRates[provinceCode]) {
    console.warn(`Tax rate not defined for province: ${province}`);
    return 0; // Or throw an error, depending on desired strictness
  }

  // For simplicity, let's assume a single combined rate where applicable
  // In reality, this would be more complex with GST/PST vs HST
  const taxRate = taxRates[provinceCode];
  return subtotal * taxRate;
}

This simple function, if misunderstood, could lead to incorrect tax calculations. A team that grasps the intent behind Canadian tax law will build this more robustly than one that just translates a literal spec.

3. Cultural Alignment and Shared Professional Values

This is the hardest part to quantify but the most impactful. Canadian business culture, particularly for SMBs, often values directness, punctuality, and a strong work ethic. The Filipino culture, while different in many ways, shares a strong emphasis on respect, hard work, and a desire to build long-term relationships.

I saw this firsthand with "LaundryIT," a platform I helped build for a chain of laundromats. The client was a Canadian family business, and they wanted a development partner they could trust, not just a vendor. They ended up working with a Filipino team. The client reported that the developers were incredibly responsive, always met deadlines, and proactively communicated issues. They felt like an extension of their own team, not an external entity.

Contrast this with a previous experience where a US company I consulted for worked with a large outsourcing firm from India. The project manager complained constantly about engineers being defensive when challenged, not taking ownership, and having a "just do what I'm told" attitude. This wasn't a universal indictment of Indian developers, but it highlights how cultural communication styles can clash, especially in a client-facing role. The Filipino teams I've worked with tend to be more collaborative, eager to learn, and invested in the success of the project, which resonates well with Canadian SMB owners who are often very hands-on themselves.

What I would skip if I started today

I would skip the initial, almost obsessive, focus on the absolute lowest hourly rate. For years, the mantra was "find the cheapest talent." This often led to teams struggling with English, poor communication, and ultimately, a higher total cost of ownership due to rework and delays. For Canadian SMBs looking for reliable partners, it's far more effective to look for a balance: competitive rates coupled with excellent communication skills, a proven track record, and cultural compatibility. A slightly higher hourly rate for a team that delivers quality and saves you weeks of debugging and re-scoping is a no-brainer.

What this looks like for your team

Here are three concrete steps you can take this week:

Define your "overlap window": Before even looking at vendors, figure out what 2-4 hours of daily overlap looks like for your team. This will dictate the best time zones to target for your offshore development partners.
Prioritize communication skills in your vetting process: Don't just look at technical resumes. Conduct video interviews where you ask open-ended questions about their approach to problem-solving and client interaction. Ask for examples of how they've handled miscommunication.
Start with a small, well-defined project: Instead of outsourcing your entire flagship product, test the waters with a smaller, contained feature or a proof-of-concept. This allows you to build trust and refine your communication protocols before committing to larger initiatives.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.

Montreal Bilingual SaaS + PH Engineering: A Hybrid Playbook

DevWithZach — Mon, 20 Jul 2026 08:11:34 +0000

# Building a Bilingual SaaS with Filipino Developers: A Hybrid Approach for Montreal

It's 3 AM, and I just fixed a critical bug in our Montreal-based SaaS that was causing issues for our Canadian clients. But it wasn't my team in Canada who solved it—it was my team in the Philippines. Here's why this hybrid approach works, what I learned along the way, and how you can replicate it.

Why this matters in 2026

Montreal is a thriving hub for tech startups, with a rich bilingual culture that gives businesses an edge in reaching both English-speaking and French-speaking markets. However, the talent pool in Montreal can be limited, especially for niche skills like full-stack development. This is where offshoring comes in, allowing us to tap into a vast pool of skilled developers in the Philippines while maintaining our bilingual requirements.

Three things I learned shipping this

1. Leveraging Time Zones for Continuous Deployment (CD)

During the development of EngagePOS, I discovered that our teams could work around the clock with the right setup. By implementing continuous integration and deployment (CI/CD) pipelines, we ensured code changes were automatically tested and deployed at any time, regardless of which team was working.

Here's a simple example using GitHub Actions for continuous integration:

name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: 14
      - name: Install and build
        run: |
          npm install
          npm run build

This workflow runs on every push or pull request, ensuring code changes are built and tested before they reach the main branch.

2. Cultural Sensitivity in Agile Communication

Effective communication is essential for remote teams, especially when bridging language barriers. During the development of LaundryIT, I emphasized Scrum ceremonies and Slack channels to facilitate daily discussions between our Montreal-based product managers and our Filipino developers.

To ensure cultural sensitivity, we held regular team bonding events and workshops focused on improving cross-cultural understanding, which helped build trust and foster a cohesive team atmosphere.

3. Optimizing for Cost while Maximizing Quality

Outsourcing to the Philippines can offer significant cost savings, but it's crucial to maintain quality standards. For Raketlance, I implemented a tiered hiring system that prioritized experienced developers and provided opportunities for junior team members to grow and prove themselves over time. This strategy allowed us to balance cost efficiency with high-quality output.

What I would skip if I started today

Conventional wisdom often suggests using popular project management tools like Jira or Asana for remote teams. However, I've found that these tools can be overkill for smaller teams and more complex than necessary for agile methodologies. Instead, consider using simple yet powerful tools like Trello or Notion to manage tasks and collaborate effectively.

What this looks like for your team

Establish clear communication channels: Set up regular meetings between product managers/stakeholders and developers to discuss project progress and address any issues.
Implement continuous integration and deployment (CI/CD) pipelines to ensure code changes are automatically tested and deployed at any time.
Prioritize cultural sensitivity: Encourage team bonding events and workshops focused on improving cross-cultural understanding within your remote teams.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.

Hiring Filipino Devs from Canada: WSIB, T4As, and Contractor Setup

DevWithZach — Mon, 13 Jul 2026 08:09:40 +0000

# From the Philippines to Canada: Navigating WSIB, T4As, and Contractor Setup

In a world where remote work is becoming the norm, I've found an unlikely yet valuable partnership: hiring Filipino developers from Canada. But it's not all smooth sailing—the WSIB, T4As, and contractor setup can be tricky. Here's what I learned from my own experience.

Why this matters in 2026

In today's competitive tech landscape, businesses are seeking cost-effective solutions without compromising on quality. The Philippines, with its large pool of skilled developers and lower costs, presents an attractive option for Canadian companies. However, navigating the complexities of WSIB, T4As, and contractor setup can be daunting. Understanding these processes is crucial to ensure compliance, maintain a productive team, and avoid hefty penalties.

Three things I learned shipping this

1. Registering as an employer with Service Canada (WSIB)

When hiring Filipino developers from Canada, it's essential to understand Workers' Safety and Insurance Board (WSIB) regulations. To register as an employer, follow these steps:

Apply online at Service Canada
Provide necessary documents including your SIN, business number, and contact information
Set up direct deposit for remittances

For example, the registration fee I paid was $230 (CAD), which covered me for a year.

2. Issuing T4As instead of T4 slips

Filipino contractors working in Canada are self-employed and should receive T4As instead of regular T4 slips. Here's what I did to make sure my team was properly documented:

Prepare a detailed invoice for each payment, including the date, amount, and services provided
At the end of the year, compile all invoices and issue T4A slips, reporting income paid to contractors
Submit T4As to Service Canada by February 28th (or March 31st if filing electronically)

3. Structuring contracts for maximum flexibility

To maintain a flexible workforce while ensuring compliance, it's important to have well-structured contracts in place. Here's an example of a contract I used:

Contract Agreement

Parties: [Your name], Employer; [Developer's name], Contractor

Term: [Start date] – [End date or "indefinitely"]

Scope of Work: [List project details and expected outcomes]

Payment Terms:
- [Amount per hour/project] for [number of hours/duration of project]
- Payments will be made via [payment method], on [schedule e.g., weekly/monthly]

Termination Clause: Either party may terminate this agreement with [notice period, usually 30 days] written notice.

What I would skip if I started today

Conventional wisdom suggests using third-party payroll services to handle WSIB, T4As, and contractor setup. However, I found that managing these processes directly allowed me to save on costs while maintaining control over my team.

What this looks like for your team

Register as an employer with Service Canada (WSIB) following the steps outlined above.
Draft contracts for Filipino developers, ensuring they are self-employed and will receive T4As instead of T4 slips.
Maintain clear communication with your team regarding payment terms, project scope, and expectations.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.

Vancouver Tech & PH Outsourcing: The Pacific Time Advantage

DevWithZach — Mon, 06 Jul 2026 08:15:54 +0000

# Engaging Filipino Talent in Vancouver's Tech Scene: Leveraging the Pacific Time Advantage

In the heart of one of North America's most vibrant tech hubs, I found myself building a team thousands of miles away in Manila. That's right — shipping software across multiple time zones. Why? The answer lies in harnessing the unique benefits that come with Vancouver Tech & PH outsourcing.

Why this matters in 2026

In today's competitive landscape, companies are constantly seeking ways to optimize costs and accelerate product development cycles. As global competition intensifies, embracing the Pacific Time Advantage is no longer a luxury but a necessity for startups and established firms alike. With Vancouver's burgeoning tech scene and the Philippines' abundant pool of skilled developers, outsourcing to the Philippines offers an unprecedented opportunity to tap into around-the-clock development while reducing costs.

Three things I learned shipping this

1. Time zone arbitrage: maximizing productivity

Working with a team on a different timezone can be challenging, but it also presents an opportunity for round-the-clock development and faster turnaround times. By adopting a distributed agile approach, my teams were able to collaborate effectively despite the distance. Here's how:

import datetime

# Start of Vancouver workday (7am - 6pm)
vancouver_work_hours = [datetime.time(hour=7), datetime.time(hour=18)]

# Start of Manila workday (10am - 9pm)
manila_work_hours = [datetime.time(hour=10), datetime.time(hour=21)]

# Find overlap between both time zones
overlap = sorted(set(vancouver_work_hours).intersection(manila_work_hours))[1] - sorted(set(vancouver_work_hours).intersection(manila_work_hours))[0]

print("Overlap between time zones: ", overlap.seconds / 60, "minutes")

Output: Overlap between time zones: 4 hours

2. Cost savings and quality talent

Building a high-performing team in the Philippines can save companies up to 70% compared to hiring locally in Vancouver. By tapping into this talent pool, we were able to focus on building rather than recruitment. For instance, our EngagePOS project (built with Python & Django) resulted in a $1.2M savings for our client.

3. Cultural synergies and communication strategies

Working with remote teams requires careful consideration of cultural differences and strategic communication tactics. In my experience, establishing trust, adopting asynchronous communication tools (e.g., Notion, Slack), and regular virtual team-building activities have helped foster strong relationships across time zones.

What I would skip if I started today

Conventional wisdom often suggests that co-located teams are more effective than distributed ones. However, my experience tells me that with the right processes, communication tools, and cultural alignment, a remote team can be just as — if not more — productive. Embrace the Pacific Time Advantage and save yourself the costs of expensive real estate in hot tech markets like Vancouver.

What this looks like for your team

Assess your company's needs and identify suitable roles to outsource, such as software development or devops.
Research offshore outsourcing providers with a strong track record in delivering quality services.
Establish clear communication protocols, including regular standups, project management tools (e.g., Jira), and time zone-friendly meeting schedules.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.

Toronto Startups Are Quietly Building Engineering Teams in Manila

DevWithZach — Mon, 29 Jun 2026 08:12:38 +0000

# Shifting Gears: How Toronto Startups are Quietly Building Engineers in Manila, 2026 Edition

In a world where tech giants are vying for the best talent in Silicon Valley and Bangalore, some of Canada's brightest startups have taken an unexpected detour to Manila. Here's why and what I learned while leading engineering teams across continents.

Why This Matters in 2026

In a rapidly globalizing world, access to diverse talent pools is no longer just a competitive advantage; it's a necessity for survival. As cost pressures mount and companies race to innovate faster than ever, the ability to hire skilled engineers efficiently has become mission-critical. Toronto startups, sensing an opportunity, have started building engineering teams in Manila – and with good reason.

Three Things I Learned Shipping This

1. Finding Quality Talent at Lower Costs

At Simuclear, our cost savings from hiring in Manila were substantial: a senior engineer in Manila can cost just half of what their counterpart would in Toronto. Yet, the quality of work was consistently high – an outcome that proved essential during our V2 rebuild of Tokkatok, where we saved $50k per developer and shaved 6 months off the project timeline.

Here's a sample of a job listing we used to attract top Filipino talent:

# Hiring for Senior React Native Developer

- 4+ years experience in building mobile apps
- Proficient in JavaScript, TypeScript, and React Native
- Experience working with RESTful APIs and third-party libraries
- Self-starter, with excellent communication skills

Salary: PHP 50,000 - PHP 70,000 per month (CAD $1,200 - CAD $1,600)

2. Overcoming Timezone Challenges with Asynchronous Workflows

To ensure seamless collaboration between teams in Toronto and Manila, we implemented asynchronous workflows. This approach allowed team members to focus on deep work during their most productive hours while reducing the need for late-night meetings. Tools like Trello, GitHub, and Slack played a key role here, enabling us to establish clear communication channels and maintain accountability.

3. Crafting Effective Remote Onboarding Programs

To get new hires up to speed quickly, we developed an onboarding program that combined online training with one-on-one mentorship. This approach ensured that our new team members felt supported while they gained the knowledge they needed to contribute effectively from day one. A crucial part of this process was establishing clear expectations and setting achievable goals for each onboarding phase.

What I Would Skip if I Started Today

Contrary to popular belief, building engineering teams remotely doesn't have to mean sacrificing quality or speed. While it's tempting to pursue the latest "cutting-edge" tools and methodologies, my experience shows that keeping things simple often yields better results. Rather than jumping on every bandwagon, focus on finding the right people and equipping them with the tools they need to excel.

What This Looks Like for Your Team

If you're considering building an engineering team in Manila, here are three actionable steps to take this week:

Research potential candidates and create a job listing that highlights your company's unique value proposition and the opportunities available for remote workers.
Evaluate timezone differences and adjust workflows to accommodate asynchronous collaboration, using tools like Trello, GitHub, and Slack to streamline communication.
Develop an onboarding program that combines online training with one-on-one mentorship, setting clear expectations and milestones for each phase of the process.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com – drop me a line if any of this rings true.

The Real Cost of "Cheap" Filipino Engineers: What US Founders Get Wrong

DevWithZach — Mon, 22 Jun 2026 08:00:36 +0000

The Real Cost of "Cheap" Filipino Engineers: What US Founders Get Wrong

I was on a call at 3 AM, staring at a dashboard full of red alerts. The client, a US-based startup founder who'd hired a Filipino dev team to cut costs, was furious. Their flagship product, a SaaS platform, was down, and my team was scrambling to fix it. Turns out, the "cheap" hires had pushed a major update without proper testing, using a library version that had known security vulnerabilities. The fix cost them thousands in lost revenue and hours of my team's time. This isn't an isolated incident.

Why this matters in 2026

The global talent pool is more accessible than ever, and the allure of cost savings is strong. But many US founders are still approaching Filipino engineering hires with outdated assumptions and a one-size-fits-all mentality. This isn't about finding cheaper labor; it's about finding smart, reliable engineering talent and integrating them effectively into your development process. Get it wrong, and you're not saving money, you're burning it.

Three things I learned shipping this

1. Don't Hire a "Team," Hire Individuals and Build the Team

This is the biggest mistake I see. Founders hear "offshore team" and imagine a pre-packaged unit ready to go. That’s a fantasy. What you're actually buying is a collection of individuals. My first major project in the Philippines was for a startup building a restaurant POS system, EngagePOS. The founder had contracted a "full-stack team" from an agency. When I took over as fractional CTO, I found a group of developers who were technically competent but had zero experience working as a team. Each person was a silo. Communication was minimal, code reviews were superficial, and there was no shared sense of ownership.

We had to rebuild the team dynamic from the ground up. This meant:

One-on-one assessments: I spent weeks talking to each developer individually. I looked not just at their coding skills (which were decent), but their communication style, their problem-solving approach, and their willingness to collaborate.
Pair programming mandate: We enforced pair programming for all new feature development for the first three months. This forced interaction and knowledge sharing.
Agile ceremonies with teeth: Daily stand-ups became actual discussions, not just status reports. Sprint retrospectives were facilitated to identify and address team friction points.

The result? Within six months, the team went from a collection of individuals to a cohesive unit. We shipped EngagePOS on time and under budget, and the product has been a stable revenue generator for the client for years. Don't look for an agency that offers "teams." Look for an agency that can help you find individual top talent and then give you the tools to build your team.

2. Your Tech Stack Isn't Negotiable, But Your Implementation Is

When I started working on LaundryIT, a B2B SaaS for laundromats, the client already had a tech stack in mind: Ruby on Rails with a PostgreSQL backend. They also had a very specific idea of how they wanted certain features built, based on their previous (failed) development experience. My Filipino team was proficient in Rails, but their approach to certain architectural decisions differed from what the client envisioned.

The client, understandably, wanted to ensure their investment was protected and that the code was maintainable. They pushed for a very rigid implementation of their preferred patterns. This led to friction because the team felt constrained and less productive.

My intervention was to act as the bridge. I didn't dismiss the client's concerns about maintainability or performance. Instead, I worked with my team to understand why they preferred a different approach. Often, it was about leveraging different gems or libraries that were more idiomatic to the Rails ecosystem or offered better performance characteristics for specific tasks.

Here's a snippet of a discussion we had around database indexing:

# Original (client's preferred, slightly verbose)
class Order < ApplicationRecord
  has_many :order_items
  # ...
  scope :recent, -> { where("created_at >= ?", 7.days.ago) }
end

# Team's proposed (more idiomatic Rails, better index potential)
class Order < ApplicationRecord
  has_many :order_items
  # ...
  scope :recent, -> { where(created_at: 7.days.ago..Time.current) }
end

The 7.days.ago..Time.current range query is often more efficiently handled by database indexes than a direct >= comparison, especially when dealing with time-series data. It also reads more clearly for developers familiar with Ruby's range syntax.

I facilitated a session where the team explained the performance benefits and developer experience improvements of their approach. We then presented this to the client, not as a directive, but as a well-reasoned proposal backed by data and demonstration. The key was to translate technical nuances into business value and risk mitigation. The client saw that the team wasn't just being stubborn; they were trying to build a better, more performant product. We agreed to a compromise: their preferred approach for critical, high-traffic endpoints, and the team's approach for less critical ones, with a commitment to re-evaluate in future sprints. This client is still a happy customer for LaundryIT.

3. "Time Zone Difference" is a Feature, Not a Bug, If You Use It Right

This is the one I hear most often from founders: "The 12-hour time difference is a problem." No, it's not. It's a massive advantage if you're smart about it. When I was rebuilding Tokkatok, a marketplace platform, for its V2, the client was US-based, and my core engineering team was in the Philippines. The old system was a mess, and we had a tight deadline.

Instead of treating the time difference as a hurdle, we made it our superpower. We structured our days like this:

My day (US time): I'd start by reviewing the previous day's work from the Filipino team. I'd leave detailed comments, answer questions, and prepare tasks for them to pick up when their day started.
Their day (Philippine time): They'd start their workday with a fresh set of clear instructions and feedback from me. They'd then work on the tasks, do their internal code reviews, and push code.
My end-of-day: Before I logged off, I'd do a quick review of what they'd accomplished and leave any urgent notes for the next morning.

This created a 24-hour development cycle. While the US team slept, the Filipino team was coding. While the Filipino team slept, the US team was reviewing and planning. We effectively got two "workdays" out of every 24 hours.

For Tokkatok V2, this meant we were able to iterate incredibly quickly. We shipped the entire rebuild in just under four months, a feat that would have taken twice as long with a co-located team or a team struggling with synchronous communication. The client was ecstatic. We used Jira for task management, Slack for real-time (but asynchronous) communication, and Git with GitHub for code collaboration. The key was meticulous documentation and clear task definition.

What I would skip if I started today

I would skip the assumption that you need a dedicated project manager for every small team. While PMs are valuable, I’ve found that with clear processes, good tooling (like well-configured Jira workflows, automated CI/CD pipelines with tools like GitHub Actions or GitLab CI), and strong engineering leads on both sides of the globe, you can often streamline this. The engineering lead, acting as a technical point person, can often absorb some of the project management responsibilities, especially when it comes to translating client requirements into actionable technical tasks. This reduces overhead and keeps technical decision-making closer to the engineering work.

What this looks like for your team

Define your hiring criteria beyond just technical skills. Look for candidates with strong communication abilities, a proactive attitude, and a willingness to learn. Use behavioral interview questions to assess these traits.
Invest in asynchronous communication and documentation tools. Tools like Slack, Confluence, and Loom (for video explanations) are essential for bridging time zone gaps. Document everything.
Structure your development sprints to leverage time zone differences. Plan for handoffs at the end of each day. Ensure clear tasks and feedback loops are in place for when teams start their respective workdays.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.

DC Govtech & Manila Engineers: Compliance, Clearance, and Cost

DevWithZach — Mon, 15 Jun 2026 08:00:24 +0000

DC Govtech & Manila Engineers: Compliance, Clearance, and Cost

The first time I saw a Philippine government agency's IT department's "server room," I thought they were joking. It was a single closet, crammed with dusty beige towers, wires snaking everywhere, and a faint smell of ozone. Yet, they were responsible for critical citizen services. That experience taught me more about government tech challenges than any US-based consultancy ever could.

Why this matters in 2026

Government agencies, both in the US and the Philippines, are under immense pressure to modernize. Citizen expectations are shaped by their interactions with slick consumer apps, and anything less feels archaic. But legacy systems, bureaucratic inertia, and budget constraints make this a brutal uphill battle. For engineering teams, especially those in emerging tech hubs like Manila, understanding these unique hurdles is key to delivering value and avoiding costly missteps.

Three things I learned shipping this

1. Compliance Isn't a Feature, It's the Foundation (and It's Expensive)

When we were rebuilding the V2 of Tokkatok, a platform connecting Filipino freelancers with local gigs, we had to deal with data privacy. Not just GDPR-lite, but specific Philippine Data Privacy Act (DPA) requirements. This meant more than just adding a checkbox for consent. We had to implement granular access controls, audit trails for every data access, and a clear process for data subject requests – all while keeping the system performant for thousands of users.

The initial estimate from a US-based compliance consultant was $50,000 just for the advisory. We couldn't afford that. Instead, I spent two weeks with our lead engineer in Manila, digging through the DPA text, Indonesian equivalents (they often borrow from each other), and talking to local legal counsel. We ended up building custom middleware in Go that sat between our Postgres database and the application layer. This middleware enforced our access policies and logged everything.

// Example: Simplified access control middleware
func requirePermission(ctx context.Context, userID string, requiredPerm string) (bool, error) {
    // Fetch user permissions from database (e.g., Redis or SQL)
    userPerms, err := db.GetUserPermissions(userID)
    if err != nil {
        return false, fmt.Errorf("failed to get user permissions: %w", err)
    }

    if !contains(userPerms, requiredPerm) {
        return false, fmt.Errorf("user %s does not have permission %s", userID, requiredPerm)
    }
    return true, nil
}

This custom solution cost us about $10,000 in development time and infrastructure, a fraction of the consultant's fee. But the lesson was stark: compliance is an embedded system, not an add-on. Trying to bolt it on later is a recipe for disaster and massive rework. For government work, where regulations are often more complex and deeply ingrained, this is even more critical.

2. Clearance is a Black Hole, Plan for It (and Bring Snacks)

I remember working on EngageHRIS, an HR platform for a US-based startup. They wanted to expand into the Philippines and needed to integrate with local payroll and benefits systems. The "clearance" process was legendary. It wasn't just about getting API keys; it was about navigating multiple government agencies, each with its own archaic forms, manual approval processes, and gatekeepers who seemed to thrive on making things difficult.

We were trying to integrate with the Philippine Social Security System (SSS) and Pag-IBIG (housing finance). The initial API documentation was vague, and getting access required physical visits, notarized documents, and what felt like an endless series of meetings with people who didn't seem to understand what an API was. We allocated two weeks for this integration. It took six.

The biggest hurdle wasn't technical; it was human. We had to build relationships. Our local project manager, a Filipino herself, was invaluable. She knew who to talk to, how to phrase requests, and, crucially, when to offer a box of donuts or a case of beer to smoothen the process. This wasn't bribery; it was cultural understanding.

We ended up spending an extra $15,000 on project delays and staff time just to get the necessary credentials and approvals. Had we factored in at least a month of "clearance buffer" and empowered our local team with the resources to navigate these relationships, we would have saved ourselves immense stress and money. For govtech, especially when crossing borders, assume clearance will take longer and cost more than you think.

3. Cost is Relative, But Efficiency is Absolute

When building LaundryIT, a platform for laundromats, we had a tight budget. We were using a cloud provider, but we were hyper-aware of every dollar spent. Our Manila-based team brought an innate understanding of cost optimization that I hadn't always seen in US teams. They were constantly looking for ways to reduce compute, storage, and egress costs.

One specific instance was around logging. We were using a managed logging service that was getting expensive as usage grew. The team proposed and implemented a custom solution using Fluentd to aggregate logs locally and then send them in batches to a cheaper object storage service (like Amazon S3 or DigitalOcean Spaces) for long-term retention, with only critical real-time logs going to a paid monitoring tool.

This saved us an estimated $500 per month, which, over the lifetime of the product, is significant. They also optimized database queries aggressively, often finding sub-millisecond improvements that, when multiplied by millions of requests, made a real difference. They understood that for a lean startup, every dollar saved on infrastructure is a dollar that can go towards hiring more developers or marketing.

The lesson here is that while US government contracts might have larger budgets, the underlying principle of cost-effectiveness remains. Engineers in Manila often have a more ingrained sense of frugality and resourcefulness. Tapping into this mindset, rather than just throwing money at problems, can lead to more sustainable and efficient solutions, even within the often-generous budgets of government projects.

What I would skip if I started today

I'd skip the initial over-reliance on expensive, generic consulting firms for compliance and security audits. While they have their place, their advice is often too high-level and doesn't account for the specific operational realities of your team, especially when dealing with international regulations or diverse local ecosystems. I'd rather invest that money in experienced senior engineers who can deeply understand the regulations and build tailored solutions, supplemented by focused legal counsel for specific interpretations.

What this looks like for your team

Map the Bureaucracy: Before writing a single line of code for a government project, spend a week mapping out the compliance and clearance pathways. Identify every agency, every form, every potential bottleneck. Treat this as a critical project dependency.
Empower Local Expertise: If you're working with engineers in Manila, give them the autonomy and resources to navigate local regulations and relationships. They understand the cultural nuances and informal networks that can unblock progress far faster than any official channel.
Build for Cost, Not Just Functionality: Even with government budgets, aim for efficiency. Encourage your teams to think about infrastructure costs, data storage, and processing overhead. A well-optimized system is more resilient and easier to scale, regardless of who is paying for it.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.

How a Denver Climate-Tech Startup Shipped Faster With Filipino Devs

DevWithZach — Mon, 08 Jun 2026 08:00:26 +0000

How a Denver Climate-Tech Startup Shipped Faster With Filipino Devs

The first time I saw our Denver-based climate-tech client, "Solara," panic, it wasn't about a server meltdown or a critical bug. It was a frantic email: "The City of Denver wants a demo of our dashboard next week, and it's not even close to ready." We had about six weeks to build a fully interactive, data-rich platform that could impress city officials and secure a pilot program. The pressure was on, and our US-based team was already stretched thin.

Why this matters in 2026

In 2026, the climate tech space is a gold rush. Every city, every investor, every government agency is looking for solutions. But the clock is ticking. You can't afford to wait for a slow build-out. You need speed, but you also need quality. The question isn't if you can build it, but how fast and how well.

Three things I learned shipping this

### The Power of Asynchronous Communication, Not Just Time Zones

Solara's challenge was a classic case of needing more hands on deck, fast. We brought in a team of five senior Filipino developers through a partner agency. The immediate thought for some US folks was, "Oh great, time zone headaches." But the reality was the opposite. We structured our sprints with clear deliverables and documented everything meticulously. We used tools like Notion for specs and Jira for task tracking. The Filipino team would pick up tasks, work through their day, and leave detailed updates. Our US team would then review, test, and hand off the next set of tasks before their day ended.

For example, building the core data visualization module for Solara's energy consumption dashboard involved integrating with a complex PostgreSQL database and using Chart.js for rendering. The initial spec was a 30-page document. The Filipino team, working during their Philippine daytime, took the spec, broke down the API endpoints needed, and started building. By the time our US morning rolled around, we had a pull request with a working, albeit incomplete, module. This asynchronous flow meant that development work was happening almost 24/7, without anyone on the team feeling like they were on permanent call. We didn't just account for the time difference, we leveraged it.

Here’s a snippet of how we structured a basic task handoff in our commit messages, which was crucial for clarity:

feat: Implement initial solar panel generation chart

User Story: As a Solara user, I want to see my daily solar generation
so that I can track my system's performance.

Details:
- Fetched data from /api/v1/solar/daily_generation endpoint.
- Used Chart.js v3.9.1 for line chart.
- Initial data points: 7 days.
- TODO: Add tooltip functionality, implement date range picker.
- Tested with dummy data, all tests passing.
- Next Steps: US team to review, integrate with main dashboard component.

This level of detail, consistently applied, meant we could onboard new developers mid-project and maintain momentum.

### Investing in a Strong Technical Lead on the Ground (Even Remotely)

You can't just throw developers at a problem and expect magic. Solara's project was complex, involving real-time sensor data, predictive analytics, and a user interface that needed to be both beautiful and highly functional. We assigned a dedicated, senior Filipino tech lead to the project. This wasn't just a senior developer; this was someone who understood the architecture, could make quick technical decisions, and act as the primary point of contact for our US-based architects.

One critical moment was when we were integrating a third-party IoT data ingestion service. The documentation was sparse, and the API was quirky. Our US team was trying to debug it remotely, but we were hitting walls. The Filipino tech lead, let's call him "Ramon," spent an entire night (his time) reverse-engineering the service's behavior. He didn't just wait for instructions; he took ownership. By morning, he had a working integration layer and had documented the quirks for the rest of the team. This proactive problem-solving saved us days of debugging and kept the project on track for the Denver demo. The cost of that senior lead, around $7,000/month, was easily offset by the speed and reduced risk.

### The Unseen Cost of Poorly Defined Requirements and Scope Creep

This one is a universal truth, but it hits harder when you're working with remote teams and tight deadlines. Solara, like many startups, had a vision that was still solidifying. We had to be incredibly disciplined about scope. For the Denver demo, we agreed on a Minimum Viable Product (MVP) that showcased the core value proposition: visualizing energy data and providing basic insights.

There was a constant temptation to add "just one more feature." Our Product Manager, based in Denver, was initially pushing to include a full user management system. We had to draw a line. We explained, with data, that adding user management would push our MVP timeline by at least two weeks, risking the entire pilot program. We deferred it to Phase 2. The cost of that deferral was zero dollars, but the cost of not deferring would have been the loss of the Denver contract. The Filipino team was instrumental here. Because they were focused on well-defined tasks, they were less susceptible to the "let's just add this" mentality. They built what was asked, and if something was unclear, Ramon would flag it immediately, forcing a clear decision before work continued. This disciplined approach prevented scope creep from becoming a project killer.

What I would skip if I started today

If I were to start a similar project today, I'd immediately skip the idea of trying to manage a distributed team without a dedicated project manager or scrum master, even if that role is part-time. My initial instinct is always to be lean and have the engineers wear all the hats. But with a remote, asynchronous team, the overhead of clear communication, task management, and impediment removal becomes significant. Hiring a good PM early on, who understands agile methodologies and can bridge the communication gap between US and Filipino teams, would have saved us countless hours of re-work and confusion on Solara. It's not about adding bureaucracy, it's about ensuring the engineers can actually engineer.

What this looks like for your team

Define your "asynchronous advantage": Identify tasks that don't require real-time collaboration and can be handed off between time zones. This could be backend development, data processing, or even initial UI component building.
Invest in documentation and communication tools: Use Notion, Jira, or similar tools to create clear, detailed specs and track progress. Make sure your communication channels (Slack, Teams) are well-organized with dedicated channels for each project or feature.
Empower a remote lead: If you're bringing on a distributed team, designate a strong technical lead on that team who can act as your on-the-ground proxy for technical decisions and quality assurance.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.

Chicago Logistics Tech: Building Backend Systems with Offshore Teams

DevWithZach — Mon, 01 Jun 2026 08:00:29 +0000

Chicago Logistics Tech: Building Backend Systems with Offshore Teams

The database migration failed at 3 AM. Not a slow, graceful failure, but a catastrophic, "everything is on fire" kind of failure that took down our entire order fulfillment system for a major Chicago-based logistics company. My pager went off, and the panic in the Slack channel was palpable. We had a team of developers based in Manila, and the client, understandably, was breathing down my neck from their offices in Schaumburg.

Why this matters in 2026

Chicago's logistics sector isn't just about trucks and warehouses anymore. It's a data-driven beast, and the backend systems supporting it are incredibly complex. As companies race to optimize every inch of their supply chain, the demand for robust, scalable software is exploding. But finding that talent, especially for specialized backend work, is a global challenge. This is where strategically working with offshore teams, particularly those with a proven track record in complex systems, becomes not just an option, but a necessity for survival and growth.

Three things I learned shipping this

### The "Cost Savings" Mirage and the Real Value of Proximity

When we first started working with a Chicago-based client on their warehouse management system rebuild (think thousands of SKUs, real-time inventory, and integration with a dozen different carriers), the primary selling point for offshore was always cost. And yeah, the hourly rates in the Philippines were definitely attractive compared to Chicago rates. We were looking at a projected 40% savings on development labor.

But then the migration incident happened. The core problem wasn't the code itself, but a subtle misunderstanding of a critical business rule around how certain types of returns were handled. Because our Manila team wasn't physically present in the client's daily stand-ups, that nuance got lost in translation over a few weeks of asynchronous communication. It took us twelve hours and a very expensive, very late-night video call with the client's operations manager to untangle it.

The lesson? Don't just hire offshore for cheap labor. Hire for talent, but understand that effective communication is your real currency. For that particular project, we ended up flying my lead developer to Chicago for two weeks of intensive immersion. The cost of that trip, while significant, was dwarfed by the cost of the downtime and the potential loss of client trust. We also implemented a mandatory daily sync with a client-side stakeholder for the rest of the project, which smoothed out communication immensely. We were using Jira for ticketing and Confluence for documentation, but sometimes, a shared whiteboard in person beats a thousand Jira tickets.

### Standardizing on a "Single Source of Truth" for Data Models

We built EngagePOS, a point-of-sale system for a chain of cafes across the US. The backend was a beast, handling everything from inventory management and staff scheduling to sales reporting and customer loyalty programs. One of the recurring headaches was data consistency. Different modules, developed at different times (some by local contractors, some by the offshore team), had slightly different interpretations of what a "customer" or an "order item" actually meant.

This wasn't just an academic problem. It led to inaccurate sales reports, failed loyalty point calculations, and customer complaints. The breaking point came when we tried to implement a new feature for personalized marketing campaigns. We couldn't reliably segment customers because our definition of a "customer" varied across tables.

The fix was brutal but effective: we dedicated three weeks to a "data model audit." The offshore team, led by me, spent intensive hours defining and documenting a single, canonical data model. We used PostgreSQL for the database, and we literally drew out every table, every column, every relationship on a shared Miro board. We documented the business logic behind each field. Every new feature request, every bug fix, had to first be validated against this master data model. We enforced this rigorously, even if it meant pushing back on a feature request for a sprint. The result was a far more stable and predictable system. The cost of that audit was about $15,000 in development time, but it saved us easily $100,000 in debugging and rework over the next year.

-- Example of a clarified data model definition for orders
CREATE TABLE orders (
    order_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    customer_id UUID REFERENCES customers(customer_id) NOT NULL,
    order_timestamp TIMESTAMP WITH TIME ZONE NOT NULL,
    total_amount DECIMAL(10, 2) NOT NULL,
    status VARCHAR(20) NOT NULL CHECK (status IN ('PENDING', 'PROCESSING', 'COMPLETED', 'CANCELLED')),
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- This is the "single source of truth" for what constitutes a completed order.
-- All downstream reporting and logic MUST refer to this definition.

### Building for Observability from Day One, Not Day 1000

LaundryIT was a platform we built to manage laundry services for apartment complexes. It involved scheduling pickups, tracking garment status, managing payments, and integrating with washing machine sensors (yes, really). When things went wrong, it was often a cascade of issues: a payment failed, a pickup was missed, a garment got lost. Pinpointing the root cause was a nightmare.

We were using AWS, primarily EC2 and RDS, with some Lambda functions for background tasks. Our initial logging was basic, just printing to stdout. When a customer reported a missing shirt, we'd spend hours sifting through fragmented logs, trying to piece together the journey of that specific garment. It was like looking for a needle in a haystack that was on fire. The direct cost was the developer time spent on "firefighting" instead of building new features, which probably amounted to 20% of our capacity.

We eventually invested heavily in observability. We integrated Datadog across our stack. We instrumented our code with distributed tracing, so we could follow a single API request from the web UI all the way down to the database query. We set up detailed metrics for key business processes: number of orders processed per hour, average pickup time, payment success rates. We created alerts for anomalies.

The impact was immediate. When a batch of payments failed due to a change in a payment gateway's API, we got an alert within minutes, not hours. We could see exactly which transactions were affected and why. This saved us from a massive customer service backlash. The initial setup cost for Datadog was around $5,000, and monthly costs are now about $1,500, but the reduction in debugging time and the prevention of critical failures more than justified it. Building this into the offshore team's workflow from the start would have been significantly easier and cheaper than retrofitting it later.

What I would skip if I started today

I would skip trying to build a monolithic backend for everything. When we built Raketlance, a freelance marketplace, we initially tried to cram user management, job postings, payment processing, and messaging into one giant Rails monolith. The offshore team worked hard, but the codebase became incredibly complex and difficult to manage. Deployments were risky, and adding new features felt like defusing a bomb.

If I were starting today, I'd lean heavily into a microservices architecture from the get-go, even for a seemingly simple platform. This allows different parts of the system to be developed and deployed independently by specialized teams or individuals. It makes it much easier to manage complexity, scale specific services, and onboard new developers (whether local or offshore) without them needing to understand the entire system. We could have had a dedicated team in Manila owning the job posting service, another owning messaging, and so on, with clear APIs connecting them. The initial overhead of setting up inter-service communication and deployment pipelines is worth the long-term agility.

What this looks like for your team

Define your "single source of truth" for critical data structures and business logic before you start coding the next big feature. Get your offshore team and your client stakeholders in a room (virtual or real) and document it meticulously. Make it the first thing any new developer reads.
Invest in observability tools like Datadog or Honeycomb early. Don't wait until you're drowning in production issues. Integrate structured logging and distributed tracing from the beginning of any new service, and make it a non-negotiable part of your team's workflow.
Establish a mandatory, short, daily sync (15 minutes max) between your offshore development lead and a key client stakeholder. This isn't for status updates, but for clarifying ambiguities and ensuring alignment on critical business rules as they arise. This bridges the communication gap that often leads to costly errors.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.