Remote-First Software Development: How Our Cebu Studio Works Globally

We are a four-person software development studio based in Cebu, Philippines. Our clients are in the United States, Latin America, Europe, and Southeast Asia. We have never missed a deadline because of timezone differences.

That is not luck. It is process.

Remote-first is not the same as “we also do remote.” Remote-first means every system, every tool, every habit is designed around the assumption that people are not in the same room. We have been working this way since we started Threshline five years ago, and we have shipped over 12 products across multiple timezones without a single in-person client meeting.

Here is how it works.

Async by Default, Sync by Exception

The foundation of our remote process is a simple rule: default to async communication. Meetings are the exception, not the norm.

This sounds obvious, but most teams get it backwards. They schedule daily standups, weekly syncs, bi-weekly planning sessions, and monthly reviews. Before you know it, half the week is meetings and the other half is recovering from meetings.

We do things differently. Our primary communication channel is written. Every decision, every question, every update is written down in a place where anyone can find it later. We use Slack for quick questions and updates, but with a strict expectation: you do not need to respond immediately. If something is truly urgent, we say so explicitly. Everything else can wait until the recipient’s next working block.

This works because we hire senior engineers who do not need to be supervised. Our team of four has a combined 20+ years of experience. We do not need to check in every morning to make sure work is happening. We trust each other to do the work, and we verify through deliverables, not attendance.

Timezone Strategy

Cebu is UTC+8. Most of our clients are in US timezones (UTC-5 to UTC-8). That is a 13-16 hour difference, which sounds brutal on paper. In practice, it gives us a superpower.

Here is our typical day mapped against a US Pacific client:

Cebu (UTC+8)          US Pacific (UTC-8)
─────────────────────────────────────────
09:00 — Start work     17:00 (previous day)
09:00-12:00 — Deep work, build
12:00-13:00 — Lunch
13:00-17:00 — More deep work
17:00-18:00 — Overlap window (01:00-02:00 PT... too early)

That does not look like it overlaps at all. So how do we make it work?

We shift the overlap to the edges. Our team works flexible hours. When a project needs regular sync communication, one or two of us will shift to a 12:00-20:00 or 13:00-21:00 schedule. That creates a 2-3 hour overlap with US morning hours (05:00-08:00 our time maps to 13:00-16:00 Pacific… but more practically, our 19:00-21:00 maps to their 03:00-05:00 PT or 06:00-08:00 ET).

For European clients (UTC+0 to UTC+2), we have natural overlap in our mornings. Cebu 9:00 AM is London 1:00 AM… but Cebu 14:00 is London 6:00 AM, and by our late afternoon their morning is fully underway. European clients are the easiest timezone fit for us.

But here is the real point: we minimize the need for overlap in the first place. The less we depend on synchronous communication, the less timezones matter.

Our Tooling Stack

Tools matter in remote work. Not because any single tool is magic, but because the right combination creates a system where information flows without friction.

Here is what we use and why:

Linear for project management. We moved from Jira to Linear three years ago and never looked back. Linear is fast, opinionated, and keyboard-driven. Every feature, bug, and task lives here. Clients get read access so they can see progress without asking for status updates.

GitHub for code. Pull requests are our primary code review mechanism. Every PR has a description that explains what changed and why. We link PRs to Linear issues so there is a clear trail from task to code to deployment.

Slack for communication. We maintain one channel per project. We keep conversations in threads. We use Slack’s “later” feature for messages that land outside someone’s working hours.

Loom for async video. This is the tool that changed everything for us. When a written explanation would take 500 words and still be confusing, a 3-minute Loom video with screen recording communicates perfectly. We use Loom for:

• Demo recordings after completing a feature
• Bug explanations (showing the exact reproduction steps)
• Architecture walkthroughs for new team members
• Client onboarding for staging environments

Figma for design collaboration. When we need to discuss UI, we do it in Figma comments, not in meetings. Clients can leave feedback directly on the design, and we respond in context.

Vercel / Cloudflare for deployment. Every pull request gets a preview deployment. Clients can see and test changes before they merge. This eliminates the “can you show me what it looks like” meeting entirely.

The Weekly Demo

We do have one recurring synchronous meeting per active project: the weekly demo. It is 30 minutes, no more.

The format is simple:

1. Show what shipped this week. Live demo on the staging environment. No slides, no status reports. We show the working software.
2. Discuss what is next. Review the upcoming week’s planned work. Client can reprioritize if needed.
3. Surface blockers. Anything we need from the client (content, decisions, access) gets called out explicitly with a deadline.

That is it. Thirty minutes. The demo replaces status update meetings, progress report emails, and “quick sync” calls. Everything that needs to be communicated gets communicated by showing working software.

Between demos, the client can check Linear for progress, view preview deployments for in-progress work, and post questions in Slack. Most weeks, the demo is the only meeting.

Always-On Staging Environments

One practice that has reduced our communication overhead dramatically is maintaining always-on staging environments for every active project.

When we built MindHyv, the staging environment was live from week one. The client could log in at any time, see the latest state of the product, and leave feedback. No scheduling a demo. No waiting for a build. Just open the URL and use it.

We deploy to staging automatically on every merge to the main branch. Our typical CI/CD pipeline looks like this:

# .github/workflows/deploy-staging.yml
name: Deploy Staging
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build
      - run: npm run test
      - uses: cloudflare/wrangler-action@v3
        with:
          command: pages deploy dist --project-name=${{ vars.PROJECT_NAME }}
          apiToken: ${{ secrets.CF_API_TOKEN }}

The staging environment uses a separate database with seed data, so the client can interact with it freely without worrying about breaking anything. We reset seed data weekly.

This practice single-handedly eliminates the most common remote work problem: the feeling that you do not know what is happening. When the client can see progress in real time, trust builds naturally.

How We Handle Handoffs

In a four-person team, context switching between projects is a real cost. We handle it through deliberate handoff practices.

Every project has a primary engineer and a secondary. The primary does most of the work. The secondary reviews all PRs and stays informed enough to step in if needed. We rotate these roles quarterly so everyone builds familiarity across the codebase.

When an engineer finishes a work block and hands off to the next day’s work (or to another engineer), they leave a written handoff note in the project’s Slack channel:

## Handoff — Jan 26

### Completed today:
- Invoice PDF generation (PR #142, merged)
- Fixed timezone bug in scheduling (PR #143, in review)

### In progress:
- Stripe webhook handler for subscription changes
- Branch: feat/stripe-webhooks
- Blocked on: need to confirm webhook events with client

### Tomorrow's priorities:
1. Finish webhook handler once client confirms events
2. Start on email notification templates

This takes five minutes to write and saves hours of context-building. When we were building LancerSpace, which had complex invoicing and payment flows, these handoff notes were essential for keeping two engineers aligned on shared modules.

Documentation as Communication

We treat documentation as a core communication tool, not an afterthought.

Every project gets a README that covers:

• How to set up the development environment
• How to run tests
• Architecture overview (which services talk to which)
• Environment variables and their purpose
• Deployment process

This documentation serves multiple purposes. It onboards new team members (including our future selves when we return to a project after a break). It answers the questions that would otherwise require a Slack message and a wait for a response.

We also document architectural decisions using lightweight ADRs (Architecture Decision Records). When we chose Supabase over a custom backend for SpotsMemico, we wrote a one-page ADR explaining the tradeoff. Six months later, when someone asked “why did we not use a custom API here,” the answer was already written down.

What Does Not Work Remotely

We would be dishonest if we said everything about remote work is better. There are real tradeoffs.

Whiteboarding is harder. When we need to sketch out a complex system design, being in the same room with a whiteboard is faster than any digital tool. We compensate with Excalidraw and Loom recordings, but it is not the same.

Relationship building is slower. It takes longer to build trust and rapport over text and video than in person. We invest in this deliberately. We have a non-work Slack channel. We do occasional video calls that are purely social. But it requires conscious effort.

Urgent bugs require clear escalation. When something is on fire in production, you cannot tap someone on the shoulder. We have a clear escalation path: Slack message with “@urgent” tag, followed by a phone call if no response in 15 minutes. In five years, we have used the phone call option fewer than ten times.

Why Cebu

People sometimes ask why we are based in Cebu specifically. The practical answer is that the Philippines has strong English proficiency, a large and growing tech talent pool, and a culture that is naturally service-oriented and collaborative. Cebu specifically has a lower cost of living than Manila, a growing startup ecosystem, and direct flights to most major Asian cities.

But the honest answer is simpler: this is where we live, and we have proven that where you sit does not determine how well you build software. What matters is your process, your communication discipline, and the quality of your work.

We have shipped Vincelio for the Latin American market, Trackelio for product teams worldwide, and JustTheRip for the global trading card community. All from Cebu. All on time.

Making Remote Work Actually Work

If we had to distill our remote practice into three principles, they would be:

1. Write everything down. If it was not written, it did not happen. Decisions, context, handoffs, architecture rationale. Write it down.
2. Show, do not tell. Working software on a staging environment beats any status report. Loom videos beat long email threads. Figma prototypes beat description documents.
3. Minimize synchronous dependencies. Design your process so that work can flow without waiting for anyone to be online at the same time.

These principles work whether you are a four-person studio like us or a hundred-person engineering organization. The tools might differ, but the discipline is the same.

If you are looking for a development team that ships reliably across timezones, reach out at hello@threshline.com. We will show you our process in action.