Asynchronous Remote Jobs: Check the Role, Not the Label

Asynchronous communication lets people contribute without being online together. It does not remove required meetings, support coverage, deadlines or hiring restrictions. If you are a developer outside the US, check those conditions before spending time on an application: a role can suit your skills and still require hours you cannot work.
Asynchronous Remote Jobs: Check the Role, Not the Label

What async does and does not tell you

A vacancy says “async-first.” You could deliver the engineering work, but you cannot be available throughout a US workday. Is it worth applying?

The useful answer is not in that label alone. You need to know which work can happen on your schedule, which duties require simultaneous participation, and whether the employer can hire you where you live. Some agreed meetings may be manageable; a daily live window or recurring support shift may not be.

Keep four conditions separate:

  • Remote location: you do not need to work from the employer’s office. This does not establish which countries are permitted.
  • Async communication: people can contribute without participating at the same time or replying immediately.
  • Flexible scheduling: you have some control over when you work. How much depends on the role’s commitments.
  • Country eligibility: the employer permits and can arrange work from your country under the applicable employment or contracting arrangement.

“Async-first” describes an employer’s stated default, not a certification that every duty is asynchronous. This guide uses developer vacancies to show how to investigate that distinction. The roles require relevant engineering experience, and neither async work nor remote work promises unrestricted travel, high pay or a hiring process without calls.

Find leads, then read the employer’s vacancy

Start with your actual specialization. Try wording such as “async-first iOS engineer,” “asynchronous full-stack developer,” or “distributed backend team written communication.” These are practical search suggestions, not proof of flexibility. A result mentioning documentation is a lead to inspect, not an answer about its working hours.

A concrete discrepancy shows why this matters. On 12 October 2026, WorkingAsync’s directory labeled PostHog’s Product Engineer role “Worldwide” and “Fully Async.” The employer’s vacancy specified GMT +2 to GMT -8 and included customer conversations, a support rotation and some on-call time. Those directory labels did not settle the conditions a candidate would actually need to meet.

Use this evidence order:

  1. The current role description and application. Read location, timezone, duties, qualifications and application instructions together.
  2. The relevant employer handbook. Look for how meetings, responses, decisions and support work, not just a broad careers slogan.
  3. Role-specific written clarification. Ask about consequential gaps or conflicts. A company-wide policy may leave the team’s actual coverage requirements unresolved.

For continued role discovery, browse Remoote’s software-developer jobs. Inspect the requirements, responsibilities and location details, then investigate the employer’s working practices. This is a role search, not an async-qualified shortlist: results are not a guarantee of worldwide eligibility, compatible hours or a suitable opening.

Two vacancies, different constraints

The following examples use vacancy and handbook wording inspected on 12 October 2026. They are not a best-company ranking or a promise that either vacancy remains open. Follow the employer links to check what has changed.

Todoist: Apple Engineer

Todoist’s Apple Engineer vacancy described the team as fully remote and async-first. It explicitly advertised work from anywhere without location restrictions and the ability to design your schedule, with eight-hour days encouraged and no more than 40 hours per week.

Those are more specific schedule and location statements than “remote” alone. They still do not answer every practical question. The role included a Hero rotation supporting Customer Experience and twice-yearly in-person company retreats. Before relying on the advertised flexibility, ask what coverage the rotation requires and what attendance, travel, visa and expense arrangements apply to the retreats. Do not assume the rotation fits your normal hours or that travel is optional.

The technical requirements were also specific: professional production iOS experience in Swift, production SwiftUI experience, UIKit familiarity, Swift Concurrency, testing and clear written English. Schedule flexibility does not turn this into a no-experience route.

The advertised absence of location restrictions is useful evidence, but it does not independently settle your local legal or contracting requirements. Confirm the arrangement available in your country. Also ask for your applicable compensation: the vacancy said a location-based salary range would be shared with shortlisted candidates.

PostHog: Product Engineer

PostHog’s Product Engineer vacancy combined an async communication default with a stated GMT +2 to GMT -8 range. It advertised Tuesdays and Thursdays as meeting-free days, while also requiring frequent conversations with users, a rotating Support hero responsibility and some on-call time.

That is not a meeting-free role. The posting did not give a complete support or on-call timetable, so the label cannot tell you whether the live duties fit your availability. The timezone range is not a list of eligible countries, either. If you live outside it, offering to adopt different hours does not establish permission to work there; ask how the employer interprets the requirement rather than treating your proposed exception as agreed.

The vacancy asked for full-stack experience, experience taking a project from 0 to 1, strong writing and something built for agents to use. Side projects could count for that last requirement. A developer can meet those expectations and still fail the schedule or location conditions.

PostHog’s meetings handbook helps explain the async default. It retains regular calls and describes no more than two hours a week for whole-team touch points, alongside team-specific sprint planning. That is not a cap on every employee’s total meetings. The handbook also allows onboarding exceptions and greater flexibility around meeting-free days for customer-facing work.

PostHog’s salary calculator varies by location and experience. Its default San Francisco benchmark is not a pay promise to a developer elsewhere. Both examples use location-sensitive compensation, so compare the terms applicable to you, not an attractive number shown for another location.

Ask what the working week requires

Before investing in a substantial application or assessment, write a short screening note. Put confirmed terms beside unresolved questions so “probably flexible” does not quietly become a commitment:

  • Country and arrangement: permitted residence; employee or contractor arrangement; any location approval still needed.
  • Live windows: required overlap or shifts, governing timezone, local workdays and the seasonal clock rule.
  • Meetings: recurring calls, required attendance, recordings or written alternatives, and team-specific planning.
  • Responses and escalation: expected reply times during planned hours, urgent exceptions and who handles them.
  • Customer and support duties: rotation frequency, coverage hours, on-call obligations and notice of changes.
  • Written decisions and handoffs: where decisions are recorded, who owns the next step and how blocked work moves forward.
  • Exceptions: onboarding sessions, retreats, travel and temporary changes to normal availability.

A list of tools is not enough. Slack, issues and documents can support asynchronous work, but their presence does not tell you whether a team expects instant replies or makes decisions in calls you must attend.

Look for observable practices instead. PostHog’s communication handbook prefers discoverable issues and pull requests, says people need not respond outside planned working hours, and asks responses to requests to include a deadline or report completion rather than merely saying the work will be done. Those practices give colleagues something to act on without waiting for everyone to be online. They do not, by themselves, erase a role’s urgent support duties.

Ask only about unknowns that could change your decision. Here is an adaptable message for a role with PostHog-like terms; replace the brackets and remove questions already answered:

I’m based in [country], and my proposed working window is [local days and hours, timezone]. I’ve read the role’s stated timezone range, async default and support/on-call responsibilities. Is hiring from my country under [proposed arrangement] possible, and is this working window acceptable for this team?

Which recurring calls require attendance, and what support or on-call coverage is mandatory? For those commitments, please specify the governing timezone, days and how seasonal clock changes affect them. How quickly should I respond to routine requests during my planned hours, and what urgent exceptions apply? Does onboarding temporarily require different availability?

If you can make a weekly planning call but cannot take overnight incident coverage, say so. “I’m flexible” hides the very boundary you need the employer to evaluate. For a live commitment, establish the governing clock and local days before deciding it fits. If you specifically need a Philippines schedule conversion, use Working US Hours From the Philippines rather than guessing from a timezone abbreviation.

The screening note should lead to one of three actions:

  • Pursue: the confirmed country, duties and schedule conditions fit your availability.
  • Ask before committing: an unanswered coverage, hiring or travel question could rule the role out.
  • Move on: a confirmed requirement conflicts with what you can offer, unless the employer explicitly agrees to different terms.

A technically appealing role can make it tempting to postpone the uncomfortable question. Clarifying a possible conflict early is more useful than completing a long task and hoping the condition will change later.

Follow this vacancy’s application instructions

Company profiles can help you discover an employer, but the present vacancy should govern your application. In the inspected examples, Todoist’s Apple Engineer application said no cover letter was needed. PostHog’s Product Engineer application requested a short cover letter and information about work built for agents. One company’s instructions are not a general rule for async employers, and older advice may no longer apply.

Show truthful evidence that matches the duties: a written technical decision, a reviewable change you delivered independently, or a clear handoff explaining what is finished and what remains. Use public work or material you have permission to share; do not expose a previous employer’s confidential documents. Strong writing is useful here because colleagues need to understand and continue your work without a live explanation.

Keep working practices separate from hiring format. Todoist listed a recruiter call, interviews and a paid task. An async-first job can still have scheduled interviews. Before substantial assessment work, clarify its scope, expected time commitment, payment terms and deadline. Todoist’s paid-task wording does not establish what another employer offers.

Todoist also explicitly warned applicants to use todoist.com/careers. Verify the official application route before sending information, especially if a recruiter contacts you elsewhere. Do not pay for access to a job or send sensitive identity or financial documents through an unconfirmed recruitment channel.

Confirm the arrangement before starting

Before accepting, seek written confirmation of the permitted work location and engagement arrangement; applicable pay currency and basis; normal availability and response expectations; required meetings; support or on-call commitments; and onboarding or travel requirements. This is practical decision support, not legal advice or a universal contract clause.

Compare that confirmation with your screening note. “We’re async-first” does not answer an unresolved question about weekend coverage. If an exception matters to your acceptance, make sure the employer has actually agreed to it rather than merely received your request.

In the first weeks, establish where decisions are recorded, who owns handoffs and how to escalate blockers. Ask whether extra live onboarding sessions are temporary and when normal availability begins. PostHog’s handbook explicitly permits onboarding exceptions to meeting-free days, so even a documented policy needs to be read with its exceptions.

Revisit the arrangement when your team, customer assignment, support rotation, residence or governing clock changes. The original async-first label cannot settle new obligations.

If you are still looking, return to Remoote’s software-developer search and use Set alerts for new role-search leads. Each lead still needs the same country and working-practice checks. Alerts do not filter for confirmed async culture, certify employers or guarantee a vacancy that fits your schedule.