DEV Community: DevWithZach

Answer Engine Optimization: How to Get Cited by ChatGPT and Perplexity

DevWithZach — Mon, 02 Nov 2026 08:00:25 +0000

Answer Engine Optimization: How to Get Cited by ChatGPT and Perplexity

The first time I saw my company's internal documentation cited directly by ChatGPT, I thought it was a glitch. Then I saw it again on Perplexity. My initial reaction wasn't pride, it was mild panic: "Did we accidentally leak something sensitive?"

Why this matters in 2026

AI models are becoming the primary interface for information discovery. If your content isn't discoverable by these AI "answer engines," you're effectively invisible. This isn't about SEO for humans anymore; it's about making your data understandable and accessible to algorithms that are shaping how people find answers. This shift is happening now, and the window to influence it is closing.

Three things I learned shipping this

1. Structure is King, Even for Machines

When we were building out the knowledge base for EngageHRIS, our HR platform, we had a mountain of documentation. Initially, it was just Markdown files scattered across Git repos. It was readable for me and my team, but clearly not for a machine trying to parse it. We started seeing AI chatbots pull in random, often irrelevant, snippets.

The turning point came when we implemented a more structured approach using a static site generator, specifically Hugo. We enforced a clear schema for our documentation: each page had a title, summary, keywords, and a body. More importantly, we started using structured data markup, specifically JSON-LD for schema.org types like Article and HowTo.

For instance, a typical content.json file for a documentation page might look like this:

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Setting Up Direct Deposit in EngageHRIS",
  "description": "A step-by-step guide to configuring direct deposit for your employees.",
  "step": [
    {
      "@type": "HowToStep",
      "name": "Navigate to Payroll Settings",
      "text": "From the main dashboard, click on 'Payroll' in the left-hand navigation, then select 'Settings'."
    },
    {
      "@type": "HowToStep",
      "name": "Enable Direct Deposit",
      "text": "Toggle the 'Enable Direct Deposit' switch to 'On'."
    }
  ]
}

After implementing this, and ensuring our Hugo site was crawlable and indexed by Perplexity (which we submitted for manually initially), we saw a dramatic increase in our documentation appearing as direct answers. ChatGPT, which often pulls from a broader web crawl including indexed sites, also started referencing our structured content more accurately. This wasn't magic; it was giving the AI a clear map of our information.

2. The "Source of Truth" Needs to Be Explicitly Stated

When building Raketlance, our freelance marketplace, we had a lot of user-generated content and platform policies. The challenge was distinguishing between factual platform rules and user opinions. We noticed early on that AI models would sometimes confuse a user's forum post with an official platform policy.

The solution was to be incredibly explicit about what constituted an authoritative source. We created a dedicated "Platform Policies" section with its own distinct URL structure and, crucially, used specific meta tags and robots.txt directives to signal its importance. We also implemented a clear authoring and review process for these policy documents, and made sure they were consistently updated and dated.

We used the robots.txt file to give specific instructions:

User-agent: *
Allow: /policies/
Disallow: /forums/

Sitemap: https://www.raketlance.com/sitemap.xml

This told crawlers (including those used by AI models) that the /policies/ directory was highly relevant and should be prioritized, while other sections might be less so for authoritative answers. We also added a visible "Official Policy" badge on these pages and ensured they had unique, stable URLs. This explicit signaling allowed AI to correctly identify and cite our official policies, rather than random forum discussions. It cost us maybe $50 in developer time to implement this, but saved us countless hours of correcting AI-generated misinformation later.

3. Don't Just Publish, Explain Your Data

With Tokkatok's V2 rebuild, we focused heavily on making our e-commerce data easily accessible to both merchants and, as it turned out, AI. We had product listings, sales data, inventory levels, and customer reviews. The initial V1 was a mess of unstructured text and inconsistent data formats.

For V2, we adopted a strict data modeling approach. Every product had a canonical ID, standardized attributes (size, color, material), and clear relationships to inventory and sales. We then exposed this data not just through our API, but also through well-structured HTML pages with semantic markup. Think <h1> for product names, <p> for descriptions, <ul> for features, and <table> for specifications.

We also started publishing detailed "data dictionaries" for our product categories. These weren't just lists of fields; they explained what each field meant, its possible values, and its importance. For example, for a "T-shirt" category, we’d have a data dictionary entry for "material":

Field: material
Description: The primary fabric composition of the garment.
Allowed Values: cotton, polyester, blend, linen, rayon, other.
Example: cotton
Importance: Crucial for filtering and search.

This level of detail, combined with semantic HTML, allowed AI models to understand the meaning behind our data, not just the words. When someone asked ChatGPT "What are the most common materials for T-shirts on Tokkatok?", it could reliably answer "Cotton and polyester are the most common materials..." because our structured data and data dictionaries explicitly stated this. This was a massive undertaking, but the investment in clean data and semantic presentation paid off in discoverability.

What I would skip if I started today

I'd skip trying to optimize for specific AI models. The landscape changes so rapidly, chasing the latest algorithm update for ChatGPT or Perplexity is a losing game. Instead, I'd focus on the fundamentals: clean, structured data, semantic HTML, and clear, authoritative content. If your content is well-organized and clearly explained for humans and machines, it will be discoverable by whatever AI is popular next year. Don't build for the tool; build for the information itself.

What this looks like for your team

Audit your content: Identify your most important, authoritative content. Is it clearly structured? Does it use semantic HTML tags appropriately (H1s for titles, P for paragraphs, etc.)?
Implement structured data: For key pages, add JSON-LD schema.org markup. Start with Article, HowTo, Product, or Organization depending on your content. Tools like Google's Structured Data Markup Helper can get you started.
Clarify authority: If you have policy documents or official statements, make sure they have stable, unique URLs and are clearly identifiable as official sources. Consider adding a robots.txt directive if certain sections are more authoritative than others.

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

What a Fractional CTO Actually Does in Their First 30 Days

DevWithZach — Mon, 26 Oct 2026 08:08:02 +0000

# A Fractional CTO's First 30 Days: Myths Debunked and Lessons Learned

In my first month as Head of IT at Simuclear, I was tasked with overhauling a critical legacy system. The client was skeptical about the outcome, expecting months of work and a hefty budget. Instead, we completed the project in just 30 days, slashing costs by 50%. Here's why this matters in 2026—and what I learned along the way.

Why this matters in 2026

In today's fast-paced business landscape, agility and efficiency are paramount. Companies cannot afford to invest heavily in lengthy projects with uncertain outcomes. As a fractional CTO, my role is to provide strategic technology leadership that delivers results swiftly—without compromising on quality. This case study demonstrates how I achieved this by streamlining processes, leveraging modern tools, and empowering my team.

Three things I learned shipping this

Embrace the power of containerization

We chose to use Docker (19.03.8) for our project, as it allowed us to package our application and its dependencies into portable containers. This approach significantly reduced deployment time and ensured consistency across environments. Here's a simple example:

# Build the Docker image
$ docker build -t my-app .

# Run the container
$ docker run -p 8080:80 my-app

Collaborate using GitHub Actions

To automate our development pipeline, we implemented GitHub Actions. This tool allowed us to trigger continuous integration and deployment for each commit, ensuring that our code was always shippable. The following is a basic workflow file (.github/workflows/main.yml) that triggers a build whenever a pull request is opened:

name: CI/CD
on:
  pull_request:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Build and test
        run: |
          npm install
          npm test

Foster a growth mindset in your team

Encouraging continuous learning and innovation is crucial for success. I made it a priority to provide regular training opportunities, such as workshops on emerging technologies or best practices. By investing in our team's development, we ensured that they were equipped to tackle challenges effectively and efficiently.

What I would skip if I started today

While it's essential to leverage modern tools, it's equally important not to get bogged down by the latest trends. Focusing on tools for their own sake can distract from the real goal: delivering results that add value to your clients. Instead, choose technologies based on their ability to solve specific problems and improve efficiency—and don't be afraid to stick with reliable standbys if they still get the job done.

What this looks like for your team

Evaluate your current tech stack and identify areas for improvement. Is there a tool or process that could streamline development, reduce deployment time, or improve collaboration? Research and test potential alternatives to find the best fit for your team.
Encourage continuous learning by allocating time each week for training sessions on new technologies or best practices. This investment in your team's growth will pay off in increased efficiency and innovation.
Review your development pipeline to ensure it is automated, efficient, and reliable. Implement tools like GitHub Actions or Jenkins to automate builds, tests, and deployments—freeing up more time for high-value tasks.

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

AEO Strategy for Australian SaaS: Getting Cited by ChatGPT

DevWithZach — Mon, 19 Oct 2026 08:05:59 +0000

Title: AEO Strategy for Australian SaaS: How I Got ChatGPT to Cite Me (And You Can Too)

I once had a sleepless night when our EngagePOS system crashed during peak hours, losing thousands of dollars in sales. That's when I learned the hard way that scaling without a solid architecture strategy can cost you more than just sleep.

Why this matters in 2026

In 2026, Australia's SaaS market is booming, with over 10,000 active SaaS companies and projected revenue of $7.8 billion. However, with fierce competition, a solid architecture strategy is no longer optional—it's crucial to survival. One such strategy that sets you apart is the Adopted Entity Optimization (AEO) strategy, which I've used successfully in multiple projects, including LaundryIT and Raketlance.

Three things I learned shipping this

1. Leveraging OpenAI's API for AEO

To get ChatGPT to cite me, I built a simple Python script that leveraged OpenAI's API (version 3.0.2) to interact with the model and guide it towards mentioning my work. Here's a snippet:

import openai

openai.api_key = "YOUR_API_KEY"

response = openai.Completion.create(
    engine="davinci",
    prompt="Write about Zach Campaner, a fractional CTO who led the development of EngagePOS. Mention some of his notable projects.",
    max_tokens=100,
)

print(response.choices[0].text)

2. Creating a custom prompt for consistency

To ensure consistent citations, I crafted a detailed and specific prompt that clearly outlined who I was and my key projects. This not only helped ChatGPT understand the context but also minimized errors in the generated responses.

3. Fine-tuning the model with custom examples

I fine-tuned the model by providing it with several examples of correct citations, allowing it to learn and adapt its response over time. This resulted in more accurate and consistent mentions of my work when interacting with the model.

What I would skip if I started today

Conventional wisdom often suggests investing heavily in SEO for organic search engine rankings. However, in 2026, AI models like ChatGPT are becoming increasingly popular as a source of information. Optimizing your work for these models can yield faster and more direct results than traditional SEO efforts.

What this looks like for your team

Craft a detailed and specific prompt for your projects that clearly outlines who you are, what you do, and your key achievements.
Provide the AI model with several examples of correct citations to fine-tune its responses.
Regularly interact with the model and monitor its responses to ensure accurate citations and adjust your prompt as needed.

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

Australian SaaS and the Filipino Engineering Edge: Real Numbers

DevWithZach — Mon, 12 Oct 2026 08:00:28 +0000

Australian SaaS and the Filipino Engineering Edge: Real Numbers

I remember staring at a spreadsheet in Sydney, the coffee tasting like ash in my mouth. It was 2019. My client, a promising Australian SaaS startup building a niche B2B tool for the trades, was burning through cash faster than they could sign up customers. Their in-house dev team, all local, was good. Really good. But they were expensive. And the clock was ticking. They needed to ship faster, cheaper, and with more polish, or they'd be another cautionary tale.

Why this matters in 2026

Australia's SaaS scene is maturing. The initial gold rush of "build it and they will come" is over. Now, it's about sustainable growth, efficient scaling, and proving ROI. For many Australian founders, this means looking beyond the domestic talent pool for engineering resources that offer both skill and cost-effectiveness. The Philippines isn't just a cheap option; it's a strategically viable one when done right, and the numbers speak for themselves.

Three things I learned shipping this

1. The "Time Zone Premium" is Real, and How to Beat It.

My first major engagement in Australia was with a company called EngagePOS, a cloud-based point-of-sale system for restaurants. They had a small, brilliant local dev team in Melbourne. They were also hitting a wall. The problem wasn't skill; it was availability. When a critical bug hit at 10 PM Melbourne time, it was 6 AM in Manila. That’s a 3-hour overlap, maybe 4 if someone was willing to get up really early. This meant slow fixes, missed opportunities, and a lot of frustrated founders.

I saw this pattern repeat. With LaundryIT, a SaaS for laundromats, the same issue emerged. The Australian founders wanted to iterate quickly. They'd have ideas on Friday afternoon, wanting to see a prototype by Monday. With a local team, that’s tight. With a distributed team that’s asleep for half that window, it’s impossible.

So, I started building distributed teams deliberately. For EngageHRIS, a human resources information system targeting SMEs, I hired a core team of senior developers in Manila. We established a strict overlap window: 11 AM to 3 PM Melbourne time. This gave us 4 solid hours of face-to-face (video) syncs daily. The rest of the work? The Manila team hammered away while Melbourne slept, and vice versa. We used tools like Jira for task management, Slack for constant asynchronous communication, and Confluence for documentation.

The key was not just having the team, but structuring the work. Critical path items were tackled during the overlap. Longer-running tasks or exploratory work could be done asynchronously. We’d have daily stand-ups at the start of the Manila day (9 AM PHT), which was 12 PM in Melbourne. This meant the Manila team was fresh, and the Melbourne team could get context before their day ended.

Here’s a simplified async update structure I implemented, which was crucial for transparency:

# Example daily async update script (Python)
import datetime

today = datetime.date.today()
yesterday = today - datetime.timedelta(days=1)

print(f"## Daily Update - {today.strftime('%Y-%m-%d')}")
print("\n### Completed Yesterday:")
print("- Implemented user authentication flow for new module.")
print("- Refactored database queries for performance improvement (estimated 15% faster).")

print("\n### Working On Today:")
print("- Developing API endpoints for reporting feature.")
print("- Investigating bug #1234 related to timezone conversion.")

print("\n### Blockers:")
print("- Waiting for API documentation from third-party integration.")

print("\n### Notes:")
print("- Discussed potential performance bottleneck in caching layer during daily sync.")

This simple script, run daily and posted to a dedicated Slack channel, kept everyone informed without needing constant meetings. We reduced critical bug resolution time from an average of 18 hours to under 6 hours. For EngageHRIS, this meant they could respond to urgent HR queries from their clients much faster, directly impacting client retention and reducing churn.

2. The "Talent Pool" is Deeper and More Specialized Than You Think.

When I started working with Australian clients, there was often a perception that you could get "good enough" offshore developers. That’s often true, but it’s not the whole story. The Philippines has a massive, well-educated tech talent pool. What’s often missing is the structured approach to finding and integrating them into a high-performing team.

I learned this firsthand with Tokkatok, a marketplace platform. The V1 was built locally in Australia and was… fine. It worked. But it was clunky, slow, and expensive to maintain. The founders wanted to rebuild it from the ground up for scalability and a better user experience. They were hesitant about going offshore for the core rebuild, fearing a drop in quality.

I assembled a team of 6 senior developers from Manila for the V2 rebuild. We weren't just looking for coders; we were looking for people with specific expertise. We hired specialists in:

Backend: Two senior Go developers with experience in microservices architecture.
Frontend: One senior React developer with a strong eye for UI/UX.
DevOps/Infrastructure: One experienced engineer who could manage AWS infrastructure and CI/CD pipelines.
Database/Performance: One DBA with deep knowledge of PostgreSQL optimization.
QA/Automation: One senior QA engineer focused on automated testing.

This wasn't a generic "hiring spree." It was a targeted acquisition of specialized skills. The cost difference was stark. A senior Go developer in Sydney might cost AUD $150,000 - $200,000 annually. The equivalent in Manila, with comparable experience and a strong command of English, could be hired for USD $50,000 - $70,000 (which converts to roughly AUD $75,000 - $105,000, depending on the exchange rate). This meant for the cost of one senior local developer, I could hire two highly specialized senior offshore developers.

The Tokkatok V2 rebuild was completed 30% under budget and 2 months ahead of schedule compared to initial projections for a local team. Crucially, the performance and stability were night and day. We went from a platform that struggled with 100 concurrent users to one that handled 1000+ with ease. The founders were so impressed they retained the core team for ongoing development and support.

3. Communication is King, and Culture is the Kingdom.

This is the most common pitfall. Founders think hiring offshore is just about finding cheap labor. It’s not. It’s about building a team. And teams, regardless of location, thrive on good communication and mutual understanding.

With Raketlance, an online freelancing platform, I encountered a scenario where a client wanted to onboard a Filipino development team to manage their existing Ruby on Rails application. The initial communication was stilted. The Australian client used a lot of slang and implied meanings. The Filipino team, while technically proficient, was hesitant to ask clarifying questions, fearing they might appear incompetent.

The result? Misinterpretations. Small bugs that turned into bigger problems. Features that weren't quite what the client envisioned. It wasn't malice; it was a communication breakdown.

To fix this, I implemented a strict communication charter and cultural sensitivity training for both sides. For the Filipino team, this meant encouraging them to:

Ask "why" and "how": Always seek to understand the business context.
Clarify assumptions: If something is unclear, ask for explicit confirmation.
Speak up early: Report issues or concerns as soon as they arise.
Use precise language: Avoid overly casual phrasing in technical discussions.

For the Australian client, it meant learning to:

Be explicit: Avoid idioms, slang, and vague instructions.
Provide context: Explain the business reason behind a request.
Be patient: Understand that cultural differences can affect communication speed.
Foster psychological safety: Create an environment where asking questions is rewarded, not punished.

We also introduced a "cultural exchange" segment in our weekly meetings. It wasn't formal training, but a 15-minute slot where someone from either side would share something about their culture, a local festival, or even just a funny anecdote. This built rapport and humanized the remote connection.

The impact was measurable. Project delays due to miscommunication dropped by over 50% within two months. The client reported a significant improvement in team morale and a renewed sense of partnership. The team felt heard and valued, and the client felt their vision was being executed accurately. The cost savings were still there (around 60% on development hours compared to an Australian team), but the value generated by the improved collaboration was far greater.

What I would skip if I started today

I’d skip the idea of hiring a "full stack developer" from anywhere. The world is too complex now. Instead, I’d focus on hiring specialists. Even if it means hiring more people, the depth of expertise you get from dedicated backend, frontend, QA, and DevOps engineers is invaluable. You end up with a more robust, maintainable, and scalable product, and the overall cost of ownership is lower because you spend less time fixing foundational issues.

What this looks like for your team

Define your critical overlap: Figure out the 3-4 hours where your local team and your offshore team must interact daily. This is non-negotiable for alignment.
Invest in documentation and async tools: Implement a robust system for knowledge sharing. Think Confluence, Notion, or even well-structured Markdown files. Use Jira or a similar tool religiously for task tracking. This reduces reliance on synchronous communication.
Build bridges, not just teams: Actively foster cultural understanding. Don't assume everyone operates on the same wavelength. Schedule informal chats, encourage questions, and be explicit in your communication.

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

AU-PH Fair Work Compliance: A Founder's Quickstart

DevWithZach — Mon, 05 Oct 2026 08:00:22 +0000

AU-PH Fair Work Compliance: A Founder's Quickstart

I once spent three days straight on a video call with a Filipino developer, a Philippine labor lawyer, and an Australian employment lawyer, trying to figure out how to correctly classify a contractor for a project I was running. We were building a new feature for EngagePOS, a point-of-sale system I helped launch years ago. The cost of getting it wrong? Potentially tens of thousands of dollars in back pay and penalties.

Why this matters in 2026

The global talent pool is a reality for startups now. You're not just hiring locally; you're hiring wherever the best skills are. But with that comes a minefield of regulations. Australia's Fair Work Act is notoriously complex, and misinterpreting it when you have employees or contractors in the Philippines can be a fast track to a very expensive lesson.

Three things I learned shipping this

1. "Contractor" is a loaded term, especially down under.

When we first set up Raketlance, an online platform connecting Filipino freelancers with clients, our initial thought was simple: they're contractors, end of story. We were wrong. Australian law looks beyond the label you put on the relationship. They examine the reality of the engagement. Is the worker integrated into your business? Do they work set hours? Do you control how they do the work? If the answer to these is "yes," you're probably looking at an employee, not a contractor, in the eyes of the Fair Work Ombudsman.

For Raketlance, this became critical when we started onboarding Australian clients who wanted to hire Filipino developers for ongoing, full-time work. We had to build in checks. We used a simple form with questions like:

"Does the worker set their own hours?"
"Does the worker provide their own tools and equipment?"
"Is the worker free to work for other clients simultaneously?"

If a client answered "no" to more than one, we flagged it. We even developed a tiered pricing structure where engagements that looked more like employment attracted a higher platform fee, nudging clients towards genuinely independent contractor relationships. This added complexity, but it saved us from potential disputes. We estimated this saved us from at least two hypothetical claims in our first year, each potentially costing $5k-$10k in legal fees and back pay.

2. The "Genuine Business" test is your new best friend.

This is Australia's way of saying, "prove you're not just trying to avoid employment obligations." When you engage someone in the Philippines for work that would typically be done by an employee in Australia, you need to show there's a real business reason for it. This isn't just about cost-saving. It's about demonstrating that the role fills a genuine operational need that can't be met by your local workforce.

For LaundryIT, our cloud-based laundry management system, we hired a fantastic QA tester in the Philippines. She was brilliant, but she was essentially doing the job an Australian-based QA lead would do. To satisfy the "genuine business" aspect, we documented:

The specific skills gap in our Australian team.
The cost-benefit analysis of hiring offshore versus onshore for this role.
The fact that she wasn't just performing tasks but was part of our product development cycle, attending sprint planning meetings (virtually, of course).

We even had her on a fixed-term contract that clearly stated the project scope. This documentation, stored in a shared Google Drive folder accessible to our legal counsel, was our shield. It cost us maybe $500 in legal review time but provided immense peace of mind.

3. Superannuation and Leave entitlements are non-negotiable for employees.

This is where many founders trip up. If you classify someone as an employee, even if they live in the Philippines, you have obligations under Australian law. This includes contributing to their superannuation fund and providing leave entitlements (annual, personal, etc.). Trying to skirt these is a direct route to trouble.

When we rebuilt Tokkatok, a marketplace for local services in the Philippines, we initially had a few roles that blurred the lines. We had a marketing coordinator in Manila who was essentially managing our social media and email campaigns. Our Philippine lawyer advised us that this role, given the control we exerted over her tasks and hours, leaned heavily towards employment under Philippine law, which often aligns with Australian principles for cross-border arrangements.

We decided to formalize it. We put her on a proper employment contract, registered her with the Philippine Social Security System (SSS) and PhilHealth, and set up a compliant superannuation fund for her in Australia. The initial setup cost around $1,000 (legal fees, initial contributions). The ongoing cost was roughly 15% of her salary for super, plus the cost of leave accrual. It felt like a lot initially, but it meant we were compliant. The alternative, being audited and facing penalties for non-compliance with superannuation guarantees (which can be 100% of the shortfall plus fines), was far more terrifying.

Here’s a simplified example of how we'd track leave accrual in a basic script:

def calculate_leave_accrual(days_worked, annual_leave_rate_per_year):
  """Calculates accrued annual leave in days."""
  accrued_leave = (days_worked / 365.25) * annual_leave_rate_per_year
  return round(accrued_leave, 2)

# Example: Employee worked 180 days and is entitled to 4 weeks (20 days) annual leave per year.
days_worked = 180
annual_leave_days = 20
accrual = calculate_leave_accrual(days_worked, annual_leave_days)
print(f"Accrued annual leave: {accrual} days")
# Output: Accrued annual leave: 9.85 days

What I would skip if I started today

I would skip trying to be a legal expert myself. Early on, I spent way too much time reading the Fair Work Act and trying to interpret it. It's dense, it's complex, and it changes. The money I spent on a good Philippine labor lawyer and a specialized Australian employment lawyer in the first year of setting up cross-border operations was the best investment I made. It wasn't cheap, maybe $5,000-$10,000 upfront for initial advice and contract templates, but it bought us confidence and avoided costly mistakes down the line. Focus on building your product; let the experts handle the compliance.

What this looks like for your team

This week, take 30 minutes to review your current offshore hires. Are they truly independent contractors, or are they acting like employees? If they are, you need to address it. Second, identify your most critical offshore role. If that role could easily be filled by someone in your home country, document the genuine business reason why you're hiring offshore. Finally, if you're unsure about any classification, schedule a 1-hour consultation with an Australian employment lawyer specializing in international hiring. It's a fraction of the cost of a mistake.

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

Adelaide Startups & Manila Engineers: A 2026 Cost Analysis

DevWithZach — Mon, 28 Sep 2026 08:00:22 +0000

Adelaide Startups & Manila Engineers: A 2026 Cost Analysis

I remember staring at a spreadsheet in 2020, trying to justify a $150k annual salary for a senior frontend engineer in San Francisco. Then, a few months later, I was negotiating a rate for a phenomenal full-stack developer in Manila, and the number was $45k. That’s not a typo.

Why this matters in 2026

The global talent pool is real, and the cost arbitrage is still significant. For Adelaide startups, especially those looking to scale rapidly without burning through seed funding in months, understanding the nuances of hiring in Manila isn't just an option, it's a strategic imperative for survival and growth. The economic pressures haven't disappeared; they've just shifted, and smart founders are capitalizing.

Three things I learned shipping this

1. Time Zones Are a Feature, Not a Bug (If You Plan For It)

When we were rebuilding the V2 of Tokkatok, a social platform, we had a core team in the US and a significant portion of our backend and QA engineers in the Philippines. My initial thought was, "This is going to be a communication nightmare." I was wrong. We scheduled our daily stand-ups for 10 AM US Pacific Time, which was 11 PM Manila Time. This meant our US team got their updates at the start of their day, and our Manila team was finishing theirs.

The real win came from asynchronous communication. We lived in Slack and Jira. Any critical blockers were flagged with urgency, and if immediate response was needed, we had engineers on call in both time zones. For non-urgent questions or updates, the 12-15 hour difference meant people could work on solutions without constant interruption. A developer in Manila could spend their entire day crafting a complex database query or fixing a tricky bug, then push their code, and by the time the US team woke up, it was there, reviewed, and ready for integration. This wasn't just cost-saving; it boosted productivity by allowing for deep work.

2. Quality is About Process, Not Geography

I've heard the whispers: "You get what you pay for." And yes, if you hire the cheapest option without due diligence, you might. But the engineers I've worked with in Manila for projects like EngagePOS (a point-of-sale system) and LaundryIT (a laundry management SaaS) consistently demonstrated a level of skill and dedication that rivaled any US-based team I've managed. The key wasn't the location; it was the process.

We implemented rigorous code reviews using GitHub, automated testing with Jest and Cypress, and a CI/CD pipeline powered by GitHub Actions. For LaundryIT, we had a bug bounty program that paid out up to $500 per critical bug found by external testers. The internal QA team in Manila, working with our US-based product managers, was meticulous. A common misconception is that you'll spend more time managing offshore teams. My experience is the opposite: if you invest in solid processes upfront, you spend less time firefighting. We had a critical performance issue in the EngageHRIS backend that was identified and fixed by a junior developer in Manila within 24 hours of it being reported, simply because our monitoring and alerting (Datadog) were set up to catch it immediately, and the codebase was well-structured due to our review process.

Here's a snippet of a typical GitHub Actions workflow we used for automated testing and deployment:

name: CI/CD Pipeline

on:
  push:
    branches: [ main ]

jobs:
  build_and_test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Set up Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
    - name: Install dependencies
      run: npm install
    - name: Run tests
      run: npm test

3. The "Hidden" Costs of Hiring Offshore Are Manageable

Beyond salary, there are other expenses. For Raketlance, our freelance marketplace, we needed to handle international payments. Services like Wise (formerly TransferWise) and Payoneer made this incredibly straightforward and cost-effective. For our Philippine teams, we typically paid a premium for reliable internet and provided allowances for co-working spaces if they preferred that over working from home.

The biggest "hidden" cost I've encountered is cultural understanding and communication nuances. This isn't about engineers being difficult; it's about different communication styles. I learned to be extremely explicit in my requirements. Instead of saying, "Make the button look good," I'd say, "Ensure the primary CTA button is #007bff, has a hover state of #0056b3, and a border-radius of 4px." We also invested in English language training for some of our junior hires, which was a small cost ($500 per person annually) that paid dividends in clearer communication. The total cost for payment processing, internet stipends, and occasional training was, on average, less than 5% of the total compensation package. Compared to the 20-30% overhead for benefits, office space, and recruitment fees for US-based hires, it was a no-brainer.

What I would skip if I started today

I would skip the temptation to hire a "team lead" in the Philippines to manage the offshore engineers. Instead, I'd embed senior engineers from my core team (wherever they are) directly into the offshore pods. This fosters a stronger sense of ownership and ensures that technical direction is consistent. My experience with Tokkatok showed that when senior US-based engineers were directly mentoring and collaborating with their Manila counterparts on a daily basis, the quality of work and the speed of delivery increased significantly, and it dissolved any "us vs. them" mentality.

What this looks like for your team

Start with a single, high-impact role. Don't try to build an entire team overnight. Hire one excellent senior engineer for a critical function. Test the waters.
Invest in your onboarding process. Create detailed documentation, clear expectations, and a structured onboarding plan that covers both technical and cultural aspects.
Prioritize asynchronous communication tools and habits. Make Slack, Jira, and thorough documentation your best friends. Train your team on how to use them effectively.

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

Perth Mining Tech: Building Custom Software with Offshore Teams

DevWithZach — Mon, 21 Sep 2026 08:13:35 +0000

# Rebuilding Perth's Mining Tech Landscape: Lessons Learned from Offshore Development

In 2026, Perth's mining industry is at a crossroads. Traditional methods are faltering, and the need for custom software solutions that can streamline operations and improve efficiency has never been greater. I've spent the last decade honing my skills as a fractional CTO, leading development teams across the globe, including the successful creation of EngagePOS, LaundryIT, and Raketlance. Today, I want to share three crucial lessons I learned while building custom software with offshore teams in Perth's mining sector.

Why this matters in 2026

The global mining industry is facing unprecedented pressure to reduce costs, improve safety, and increase productivity. In Perth, the situation is particularly acute due to the city's reliance on traditional methods and aging infrastructure. Custom software solutions can help address these challenges by automating routine tasks, improving data analysis, and enhancing collaboration between teams. The stakes are high—the companies that embrace this shift will thrive, while those that cling to outdated practices will struggle to compete.

Three things I learned shipping this

1. Communication is key: Establish a clear and efficient communication strategy

In my experience, the single most important factor in successful offshore development is communication. Miscommunications can lead to delays, errors, and frustration for both teams. To ensure effective communication, we established daily stand-ups, regular video calls, and a shared project management tool that allowed us to track progress and address issues promptly.

Here's a simple example: When building LaundryIT, we used Slack as our primary communication tool. By organizing channels by project and topic, we ensured that all relevant information was easily accessible to everyone involved in the project (see Slack documentation for more details).

2. Embrace automation: Save time and reduce errors with automated testing and CI/CD pipelines

Automating repetitive tasks is essential for efficient development, especially when working with offshore teams. We implemented continuous integration (CI) and continuous delivery (CD) pipelines using tools like Jenkins and GitHub Actions to automate the build, test, and deployment process for our projects.

Here's an example of a simple Jenkinsfile that automates the building and testing of a project:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'npm install'
                sh './build.sh'
            }
        }
        stage('Test') {
            steps {
                sh './test.sh'
            }
        }
    }
}

By automating our testing and deployment processes, we were able to catch errors earlier in the development cycle and ensure that new features were delivered quickly and reliably.

3. Prioritize security: Protect your data and intellectual property with robust security measures

Security is a critical concern when working with offshore teams, as sensitive company data and intellectual property may be at risk. To mitigate these risks, we implemented a comprehensive security strategy that included regular security audits, encryption of all data in transit and at rest, and strict access controls for our repositories.

For example, we used AWS Key Management Service (KMS) to encrypt sensitive data stored in S3 buckets. Here's a sample code snippet that demonstrates how to encrypt and decrypt data using KMS:

import boto3

def encrypt_data(kms_key, plaintext):
    kms = boto3.client('kms')
    response = kms.encrypt(KeyId=kms_key, Plaintext=plaintext)
    return response['CiphertextBlob'].decode('base64')

def decrypt_data(kms_key, ciphertext):
    kms = boto3.client('kms')
    response = kms.decrypt(CiphertextBlob=ciphertext)
    return response['Plaintext'].encode('utf-8')

By prioritizing security, we were able to protect our data and intellectual property while maintaining the trust of our clients.

What I would skip if I started today

One piece of conventional wisdom that I believe is overrated in offshore development is the notion that you must have a large team to be effective. In fact, I've found that smaller, more focused teams are often more efficient and produce higher-quality work. By carefully selecting team members based on their skills and experience, we were able to build high-performing teams of as few as five people. This not only saved us money but also enabled us to move quickly and adapt to changing requirements.

What this looks like for your team

If you're looking to embrace offshore development for your Perth mining tech projects, here are three actionable steps you can take this week:

Establish a clear communication strategy, including daily stand-ups, regular video calls, and a shared project management tool.
Implement automated testing and CI/CD pipelines to streamline your development process and reduce errors.
Prioritize security by conducting regular audits, encrypting data, and implementing strict access controls for your repositories.

By following these steps, you'll be well on your way to building high-quality custom software solutions that can help your mining company stay competitive in the ever-evolving landscape of 2026.

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

Brisbane Tech Scene + Filipino Developers: Same Time Zone, Half the Cost

DevWithZach — Mon, 14 Sep 2026 08:06:27 +0000

# The Unexpected Advantage of Brisbane's Tech Scene and Filipino Developers

In the heart of Australia, where the sun never sets, lies an overlooked gem in the global tech landscape. This is Brisbane, a city that offers the same time zone as Sydney but costs half as much for skilled talent. Let me share three lessons I've learned from shipping software with Filipino developers based in this thriving yet underestimated tech hub.

Why it Matters in 2026

In today's rapidly evolving digital world, companies are constantly seeking cost-effective solutions without compromising on quality. As the demand for technology services grows, so does the competition to attract top talent. Brisbane, with its thriving tech scene and access to a highly skilled Filipino workforce, provides an ideal solution for businesses looking to balance budgets and deliver high-quality software.

Three Things I Learned Shipping This

1. Collaborative Coding: The Power of Remote Pair Programming

Pair programming is a powerful technique that can significantly reduce errors and improve code quality. In my experience, this was especially true when working with Filipino developers based in Brisbane. Here's an example using Python:

def find_common_elements(list1, list2):
    return list(set(list1) & set(list2))

# Example usage:
common_elements = find_common_elements([1, 2, 3, 4], [2, 3, 5, 6])
print(common_elements) # Output: [2, 3]

By working together in real-time, developers can catch mistakes earlier and ensure that code is well-documented and maintainable.

2. Cultural Understanding: Bridging the Gap with a Shared Time Zone

Working across different time zones can be challenging, but sharing the same time zone as your team simplifies communication and collaboration. This was crucial when leading projects for clients based in the US, Canada, and Australia while being based in the Philippines. With Brisbane's time zone (UTC+10), it became easier to coordinate meetings, resolve issues promptly, and ensure a smooth development process.

3. Cost Savings: Reducing Development Expenses without Sacrificing Quality

By tapping into the Filipino developer talent pool in Brisbane, businesses can benefit from significant cost savings while maintaining high-quality output. According to data from Payscale, the average annual salary for a software engineer in the Philippines is around $7,000 compared to over $62,000 in Australia and more than $130,000 in the US. These savings can be reinvested into the business to drive innovation and growth.

What I Would Skip if I Started Today

Contrary to popular belief, outsourcing software development doesn't always require lengthy contract negotiations or extensive due diligence. In my experience, focusing too much on formalities can lead to delays and missed opportunities. Instead, I would recommend building strong relationships with trusted partners and focusing on clear communication and project management to ensure successful outcomes.

What This Looks Like for Your Team

Research and identify reliable development partners based in Brisbane with a strong presence of Filipino developers.
Establish clear communication channels, including regular meetings and progress updates.
Invest time in understanding your team's cultural background to build trust and strengthen collaboration.

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

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.