DEV Community: DevWithZach

Melbourne SaaS Founders: The PH Engineering Playbook

DevWithZach — Mon, 07 Sep 2026 08:00:26 +0000

Melbourne SaaS Founders: The PH Engineering Playbook

I once spent a week debugging a critical payment gateway integration for a US-based client. It was 3 AM, I was running on lukewarm coffee and sheer stubbornness, and the problem wasn't a bug in my code, but a bizarre edge case in a third-party API that only triggered on Tuesdays. That’s the reality of shipping software, and it’s a reality I’ve lived across continents.

Why this matters in 2026

Melbourne’s SaaS scene is buzzing, but scaling engineering teams efficiently is a perennial challenge. The Philippines offers a deep, talented pool of developers who can significantly de-risk your growth, provided you understand how to work with them. This isn't about cheap labor; it's about smart, cost-effective access to skilled professionals who can help you ship faster and better.

Three things I learned shipping this

Building trust takes more than a Slack channel

When I first started working with teams in the Philippines, I made the mistake of treating them like any other remote team. I’d send over specs, expect daily stand-ups, and assume everyone was on the same page. It wasn't until I was building EngagePOS, a complex point-of-sale system, that I realized how wrong I was. We had a brilliant Filipino dev, let’s call him Rico, who was consistently delivering great code but seemed hesitant to flag issues or suggest alternatives.

It turned out that in many Filipino work cultures, there's a strong emphasis on not questioning authority or appearing incompetent. My direct, "tell-it-like-it-is" style, common in US tech, was coming across as aggressive or dismissive. We were burning money on missed deadlines because Rico was afraid to say, "Zach, I don't think this approach will work because of X, Y, Z."

The fix? I started scheduling 1-on-1 video calls, not just for code reviews, but for casual chats. I asked about their families, their weekends, their favorite Filipino dishes. I learned to frame feedback as collaborative problem-solving. Instead of saying, "This isn't right," I’d say, "Help me understand how we can make this better. What are your thoughts on this challenge?"

One evening, while working on Raketlance, a freelance marketplace, we hit a snag with user authentication that involved a complex JWT implementation. Rico, who was leading the backend, initially just implemented it as requested. During our 1-on-1, I asked him what he thought of the security implications. He paused, then hesitantly brought up a potential vulnerability he’d spotted but hadn’t felt comfortable mentioning in a group setting. We then spent another hour discussing it, and he ended up proposing a more secure, albeit slightly different, implementation that saved us from a potential security headache down the line.

This shift in communication, focusing on building rapport and creating a safe space for ideas, was crucial. It wasn't just about being nice; it was about unlocking the team's full potential.

Asynchronous communication is your friend, but know when to sync

When I was rebuilding Tokkatok's V2, a social discovery app, we had a distributed team spanning Manila, Cebu, and myself in the US. The time difference was significant – often 12-15 hours. Trying to force synchronous meetings for everything was a nightmare. Developers were joining calls at 2 AM their time, and I was staying up late. It was unsustainable and inefficient.

We pivoted hard into asynchronous communication. We used tools like Notion for detailed documentation, Loom for screen recordings explaining complex features or bugs, and GitHub Issues for tracking tasks with clear acceptance criteria. Every code change had a detailed pull request description.

Here’s a snippet of how we documented a new feature for the Tokkatok V2 messaging system in Notion:

## Feature: Real-time Typing Indicators

**Goal:** Improve user experience by showing when another user is actively typing.

**User Story:** As a user, I want to see when the person I'm messaging is typing so I know they are engaged in the conversation.

**Technical Implementation:**
*   Backend: Redis Pub/Sub for broadcasting typing events.
*   Frontend: WebSocket connection to receive typing events.
*   API Endpoint: `POST /api/v2/chat/{chat_id}/typing` (body: `{ "is_typing": true/false }`)
*   Debounce logic on client-side to prevent excessive event firing (e.g., 500ms).
*   Timeout for clearing typing indicator (e.g., 5 seconds after last event).

**Acceptance Criteria:**
1.  When User A starts typing in a chat with User B, User B sees a "User A is typing..." indicator.
2.  The indicator disappears 5 seconds after User A stops typing.
3.  The indicator is not shown if User A's connection is lost.
4.  No more than 2 typing events per second are sent from the client.

This allowed developers to pick up tasks, understand requirements, and provide updates on their own schedules. It also meant that when we did have a sync call, it was for high-value problem-solving or strategic discussions, not status updates. I remember a particularly tricky bug related to message ordering that spanned across two services. Instead of calling an emergency meeting, the relevant developers documented their findings in GitHub issues, shared Loom videos of the behavior, and collaboratively worked through it asynchronously over 24 hours. By the time I logged in, they had a clear proposal and a patch ready.

However, I learned that too much async can lead to isolation. For critical decisions or complex architectural discussions, a well-timed video call was invaluable. For instance, when we were deciding on the database migration strategy for LaundryIT, a laundry service management app, we had a few critical options. We spent an hour on a video call, sketching out diagrams on a virtual whiteboard, and came to a consensus much faster than a lengthy email chain would have allowed. The key is to be deliberate about when you sync.

Invest in your infrastructure, not just your people

My first few projects were lean. I was focused on getting features out the door, and sometimes, the infrastructure took a backseat. This bit me hard when working on EngageHRIS, a human resources information system. We were using a basic Heroku setup, and as the user base grew, performance started to degrade. Deployments became slow, and we experienced occasional outages.

The cost of this neglect was significant. We lost potential enterprise clients because our system couldn't handle their load. The engineering team spent countless hours firefighting instead of building new features. The total cost of downtime and lost revenue was easily in the tens of thousands of dollars annually.

When I started Simuclear, my current role, I made infrastructure a top priority from day one. We use AWS with Terraform for infrastructure as code. We have a robust CI/CD pipeline using GitHub Actions. We implemented New Relic for monitoring and alerting. This upfront investment, which might seem like a luxury to a bootstrapped startup, pays dividends.

For example, when we launched a major update for EngagePOS, we were able to deploy it to production with zero downtime and confident rollback capabilities. The monitoring tools alerted us to a minor performance anomaly within minutes of the deployment, and we were able to hotfix it before any users were impacted. The cost of our AWS bill and the tools like Terraform and New Relic is a fraction of what we would have spent on lost productivity and customer churn due to poor infrastructure. Investing in solid tooling and automation upfront means your Filipino engineering team can focus on building value, not wrestling with flaky deployments or slow servers.

What I would skip if I started today

I’d skip the temptation to micromanage. It’s easy, especially when you’re paying for dedicated resources, to want to be involved in every single task. But that’s not how you build high-performing teams, regardless of location. Instead of assigning tasks and then checking in every hour, I’d focus on defining clear outcomes, setting measurable goals, and empowering the team to figure out the how. Trust them to do their jobs. Your role shifts from taskmaster to facilitator and strategic guide.

What this looks like for your team

Here are three actionable steps you can take this week:

Schedule a 1-on-1 with a key remote engineer. Don't talk about code. Ask them about their day, their challenges outside of work, and what they enjoy most about their role. Build that personal connection.
Document one complex process or feature in your knowledge base. Use Loom to record a quick walkthrough. Make it a template for how you want information shared asynchronously.
Review your CI/CD pipeline and monitoring setup. Are deployments fast and reliable? Do you have alerts set up for critical metrics? If not, identify one small improvement you can make this week.

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 Sydney CTOs Are Outsourcing Mobile Builds to Manila

DevWithZach — Mon, 31 Aug 2026 08:00:31 +0000

Why Sydney CTOs Are Outsourcing Mobile Builds to Manila

I was on a call with a Sydney-based founder, let's call him Mark. He was sweating over a $150k mobile app build that was six months behind schedule and already bleeding cash. He’d hired a local agency, and they were good, technically. But the communication was a nightmare, the costs were astronomical, and the progress was glacial. He asked me, "Zach, is there anywhere else I can get this done without breaking the bank and losing my sanity?" That’s when I told him about Manila.

Why this matters in 2026

The global talent pool for skilled developers is tighter than ever, and the cost of hiring senior engineers in places like Sydney is frankly unsustainable for most startups. Founders are realizing that the "local is best" mantra for software development often means "local is most expensive and slowest." They need to look further afield, and Manila offers a compelling, proven alternative for high-quality mobile development.

Three things I learned shipping mobile apps with Manila teams

1. The "Time Zone Difference" is a Myth if You Use Asynchronous Communication Right

The biggest hang-up Sydney CTOs have about Manila is the 3-hour time difference. "How can we possibly work together?" they ask. My answer: you probably shouldn't be working synchronously that much anyway. On the Tokkatok V2 rebuild, we had a core team in Sydney and a significant portion of the mobile development happening in Manila.

Instead of expecting real-time back-and-forth on every ticket, we leaned heavily on detailed asynchronous communication. Think meticulously written Jira tickets with clear acceptance criteria, Loom videos explaining complex UI flows, and Slack channels dedicated to specific features where discussions could live and be referenced later.

For example, when we were building out the real-time chat feature for Tokkatok, the Manila team would push updates at the end of their day. Our Sydney team would review, add comments, and update tickets first thing in their morning. This meant that by the time the Manila team logged on, they had a clear set of actionable feedback. We didn't waste developer hours waiting for someone to wake up. We were consistently moving forward. The key was building a culture of detailed documentation and clear ownership. If a ticket was unclear, it was the responsibility of the person who created it to clarify it, not the developer to guess.

Here's a snippet of how we'd structure a typical task description in Jira:

**Story:** As a user, I want to see real-time updates in my chat feed so I know when new messages arrive.

**Acceptance Criteria:**
1. New messages appear at the top of the chat feed within 2 seconds of being sent.
2. Unread message count is updated correctly.
3. Message timestamps are accurate.

**Technical Notes:**
- Use WebSockets for real-time updates.
- Integrate with the existing message service API.
- Ensure graceful handling of network interruptions.

**Designs:** [Link to Figma mockups]
**Video Walkthrough:** [Link to Loom recording of expected behavior]

2. Quality Isn't About Location, It's About Process and Talent Pool

I've seen teams in Sydney produce shoddy code and teams in Manila produce absolute gems. The notion that you inherently get better quality because someone is in a more expensive city is a fallacy. What you do get in Manila is a massive pool of highly motivated, technically sound developers who are eager to prove themselves.

When we were building EngagePOS, a point-of-sale system for restaurants, we hired a mobile development team in Manila. We were initially concerned about app performance on lower-end Android devices common in some target markets. Our Manila team didn't just meet the specs; they optimized. They implemented efficient data caching strategies and profiled memory usage aggressively.

The result? EngagePOS ran smoothly on devices that would have choked other apps. We spent significantly less on QA because the development quality was so high from the outset. We specifically looked for developers with experience in React Native and native Android (Kotlin), and we found exceptional talent. The cost savings were substantial – we built the entire MVP for EngagePOS for under $70,000, a fraction of what a Sydney-based team would have charged.

3. Communication is King, and Manila Devs Master "Show, Don't Tell"

This ties back to asynchronous communication, but it’s more than just writing good tickets. Filipino developers I’ve worked with have an incredible knack for understanding a problem and then showing you the solution, rather than just talking about it. This is gold when you're building complex applications.

For LaundryIT, a platform for managing laundry services, we had a tricky integration with a third-party payment gateway. The requirements were dense, and the API documentation was, frankly, awful. Instead of endless Slack threads trying to decipher it, the Manila development lead took it upon himself to build a small, isolated proof-of-concept. He then sent us a video demonstrating exactly how the integration would work, highlighting the specific API calls and data transformations.

This single video saved us days of back-and-forth. We could see the solution in action, identify potential edge cases visually, and provide concrete feedback. It was far more efficient than trying to explain the problem and solution in text. This proactive "show, don't tell" approach is something I actively look for and is incredibly common with the developers I’ve partnered with in Manila.

What I would skip if I started today

If I were starting a new mobile build today, I'd skip the initial phase of trying to find a "full-service" agency that claims to do everything from UI/UX design to backend development. Instead, I’d focus on finding a highly specialized mobile development team in Manila, ideally with a strong track record in the specific framework I need (e.g., React Native, Swift, Kotlin). I'd handle the core product strategy and UI/UX design myself or with a lean, dedicated designer, and then hand off those well-defined requirements to the specialized mobile dev team. This focused approach cuts down on overhead and miscommunication inherent in larger, more generalized agencies.

What this looks like for your team

Here are three concrete steps you can take this week if you're considering outsourcing mobile builds to Manila:

Define Your MVP Scope Rigorously: Before you even look for developers, have your Minimum Viable Product features crystal clear, with detailed user stories and acceptance criteria. Think about what absolutely needs to be in the first release.
Identify Key Frameworks and Technologies: Know whether you need iOS native (Swift), Android native (Kotlin), or cross-platform (React Native, Flutter). This will significantly narrow your search for the right talent.
Start with a Small, Well-Defined Project: Don't outsource your entire flagship product on day one. Engage a Manila-based team for a specific module, a feature enhancement, or even a proof-of-concept. This allows you to test the waters, build trust, and refine your communication processes before committing to a larger build.

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 CAD-PHP Currency Edge: Why Manila Is a 5x Bargain in 2026

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

The CAD-PHP Currency Edge: Why Manila Is a 5x Bargain in 2026

I was staring at a burn rate report for a US-based SaaS startup, the kind where you sweat over every line item. Then I looked at the same line item for a dev team I was working with in Manila. The numbers were so stark, so wildly different, it felt like I was looking at two separate realities. It wasn't just cheaper; it was a fundamental economic advantage that most North American founders were completely missing.

Why this matters in 2026

The global talent market is tightening. Remote work is the norm, but the cost arbitrage is becoming harder to ignore. As founders chase efficiency and sustainability, overlooking the significant cost differences in engineering talent based on location is a strategic misstep. The Philippines, specifically, offers a unique combination of skilled developers, English proficiency, and a favorable exchange rate that creates an undeniable financial edge for businesses operating in strong currencies like the Canadian Dollar (CAD) or US Dollar (USD).

Three things I learned shipping this

1. The 5x Development Cost Advantage is Real, Not a Myth

When I was rebuilding Tokkatok, a Filipino-based gig marketplace, we needed to scale rapidly. We had a small core team in Canada, but we needed more hands on deck for feature development and QA. I brought on a team of five developers and two QA engineers from Manila. The total monthly cost for this team, including overhead and management, was around $15,000 CAD. Meanwhile, a comparable team of seven in Toronto or Vancouver would have easily run me $70,000-$80,000 CAD. That's a legitimate 5x difference, not a marketing gimmick. This wasn't about cutting corners; it was about optimizing our runway and being able to hire more talent for the same budget. We shipped the V2 rebuild 6 months ahead of schedule because of this.

2. English Proficiency Isn't Just a Bonus, It's a Productivity Multiplier

One of the biggest fears founders have about hiring internationally is communication breakdowns. I get it. I've been on calls at 3 AM with clients struggling to understand each other. But with Filipino developers, this is rarely an issue. Their English proficiency is exceptionally high, thanks to the education system and the pervasive influence of American media. On the LaundryIT project, a cloud-based laundry management system I helped launch in Australia, our entire development team was remote, based in Manila. We used Slack and Zoom extensively. The communication was so clear and direct, we barely had any misunderstandings. Meetings were productive, code reviews were thorough, and documentation was precise. I never had to ask a developer to repeat themselves or clarify a complex technical point. This saved us countless hours that would have been lost to translation barriers.

3. Time Zone Differences Can Be Managed, Even Turned into an Advantage

Yes, there's a 12-hour time difference between Toronto and Manila. But this isn't the insurmountable obstacle many assume. For EngageHRIS, a custom HR system I architected for a US client, we structured our workflow around this. Our US-based product manager would end their day by leaving detailed specifications and updates in Jira. The Manila team would start their day with those tasks, work through them, and then leave their progress updates and any questions for the US team to pick up the next morning. It created a near 24-hour development cycle. Issues were identified and often resolved before the next business day even began. We used tools like Jira for task management, GitHub for code collaboration, and Confluence for documentation. The key was clear asynchronous communication and well-defined processes.

# Example of a structured Jira ticket for asynchronous communication
# This would be written by the US product manager at end of day

ticket_id: "ENGAGE-1234"
title: "Implement User Profile Avatar Upload"
description: |
  As a user, I want to upload a profile picture so that I can personalize my account.

  **Acceptance Criteria:**
  1. User can select an image file (JPG, PNG, GIF) up to 5MB.
  2. Image is resized to 200x200px.
  3. Uploaded image is stored in S3 bucket 'engagehris-avatars'.
  4. User's profile page displays the uploaded avatar.

  **Technical Notes:**
  - Use the existing `react-dropzone` library.
  - Backend API endpoint for upload: POST /api/v1/users/me/avatar
  - Ensure proper error handling for invalid file types or sizes.

  **Questions for the dev team:**
  - What is the current S3 bucket configuration for permissions?
  - Are there any existing utility functions for image resizing we can reuse?

assignee: "" # To be assigned by the Manila team lead
priority: "High"

What I would skip if I started today

I'd skip the initial temptation to hire a single "rockstar" developer and instead focus on building a small, cohesive team with a strong lead. When I first started working with international teams, I sometimes fell into the trap of thinking one highly experienced individual could carry the load. But what I found with projects like Raketlance, a freelance platform I helped build, is that a well-rounded team with a good lead who can facilitate communication and manage tasks is far more effective. A strong lead can bridge cultural gaps, ensure code quality, and keep everyone aligned, which is far more valuable than a single brilliant but isolated engineer.

What this looks like for your team

If you're a founder reading this, here are three concrete steps you can take this week:

Research the Exchange Rate: Look up the current CAD to PHP and USD to PHP exchange rates. Understand the raw purchasing power difference. It's likely more significant than you think.
Identify a Small, Defined Project: Think about a feature or a small internal tool that’s been on your backlog. Something that doesn't require deep, real-time collaboration with your core US/Canada team. This is your pilot.
Start Networking: Reach out to founders or engineering leads who have successfully hired in the Philippines. Ask for introductions to agencies or direct hires they trust. Don't just look at job boards; leverage connections.

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

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.