About Wander

Wander is revolutionizing the $100 B+ short‑term rental industry. We curate every aspect of the guest experience, from marketplace to wanderos offering. Our mission is to help people find their happy place, and our vision is to create the infrastructure for people to experience the world.

Backed by top‑tier investors and led by experienced startup veterans, we're a tight‑knit, remote‑first team united by our passion for travel, technology, and creating unforgettable experiences.

Level: Senior to Staff (IC). 7+ years required, 10+ preferred, in backend systems that have to work. Team: Sync — the integration and reconciliation layer between external property-management systems and Wander's internal services.Stack: TypeScript on Effect, PostgreSQL, REST/HTTP integrations against a long and growing list of third-party PMSes, with hotel systems coming next.

What Sync is

Sync is the layer that makes every external PMS look like one uniform PMS to the rest of Wander. Downstream services should never know or care whether the booking, rate, or availability behind a call came from one vendor's API or another's; Sync maintains that abstraction for the internal systems and makes it real by adapting the external ones.

The architecture is deliberately simple and you are expected to keep it that way. Connectors talk to each external system, adapters and transformers map vendor-specific shapes onto a canonical internal set of functions and structs, and Sync applies those canonical facts into the internal owner systems with observable freshness, retries, and recovery. Sync pulls authoritative PMS facts through PMS-specific adapters, translates them into Wander canonical forms, and lands them in the systems that own that state.

What Sync is not, and what you will be expected to actively resist turning it into: a workflow engine, a queue system, or a clever orchestration layer. The database owns accepted work and recovery state. Token buckets, timers, workers, and queues are execution controls, not the system of record. If a design starts growing a bespoke orchestration brain, that is a smell, and part of this job is having the judgment and the spine to keep the thing boring.

What you will do

• Build and own PMS adapters: connect to each vendor's REST/HTTP API, handle its auth, its rate limits, its pagination, its quirks and its lies, and map its data onto Wander's canonical model. Every vendor is different and several are badly behaved; the work is making them all look the same from the inside.
• Build the canonical model and the transformers that get vendors into and out of it, so the abstraction downstream services rely on stays clean even as the set of integrated systems grows.
• Make freshness, retries, and recovery observable and real. When a sync falls behind, fails, or partially applies, the system should make that visible and recover deterministically rather than silently drift. Reconciliation against the authoritative external source is core to the job, not an afterthought.
• Keep the database as the source of truth for accepted work and recovery state, and keep the execution controls (rate limiting, scheduling, workers) as controls rather than letting them accrete into a shadow workflow engine.
• Extend the same patterns to hotel systems as that work arrives, generalizing the canonical model where it should generalize without over-abstracting for cases that do not yet exist.
• Treat third-party data as something to validate and reconcile, not to trust blindly, because the external system is authoritative for its facts but not always correct in how it reports them.

What you bring

• 7+ years (10+ preferred) building backend systems that simply have to work, where correctness, recovery, and uptime are the job and "mostly works" is failure.
• Deep, real experience with REST and HTTP APIs, integration work against third-party systems, and the specific pain of making many inconsistent external APIs behave as one. You have integrated against APIs that were undocumented, inconsistent, rate-limited, and occasionally wrong, and you know how to build defensively against them.
• Strong relational database fundamentals: you reach for the database to own state and recovery, you understand idempotency and reconciliation, and you know why the DB, not a queue, should hold accepted work.
• Strong TypeScript, and either real Effect experience or a credible track record of picking up a functional-effects style quickly. We are on Effect and you will be productive in it; prior exposure is a plus, the ability to learn it fast is required.
• The temperament this team is actually hiring for: someone who will just figure it out. You take an ambiguous integration against a vendor whose docs are wrong and get it working, you keep the design simple under pressure, and you do not need a spec for every edge case to make forward progress.
• The judgment to resist over-engineering. You know the difference between an execution control and a workflow engine, and you keep Sync on the right side of that line.

Strongly preferred

• Direct experience integrating against property-management systems, booking/reservation systems, hotel systems (PMS/CRS/channel managers), or comparable multi-vendor integration domains.
• Experience building reconciliation or sync systems where an external system is authoritative and freshness, drift, and recovery are first-class concerns.
• A history of being the person who owns the gnarly integration nobody else wants and makes it reliable.

Level expectations

At Senior, you own adapters and the canonical mappings end to end, build reliable integrations against difficult external systems with minimal hand-holding, and make sound calls on freshness, retry, and recovery without needing them spelled out. At Staff, you additionally shape the canonical model and the integration patterns the rest of the team builds against, set the boundary that keeps Sync an integration-and-reconciliation layer rather than an orchestration engine, and raise the reliability bar across the team's integrations. Either way you are measured on integrations that work, recover, and stay observable under real-world vendor behavior, and on keeping the system simple as the number of integrated PMSes and hotel systems grows.