Senior Backend / Platform Engineer (Americas time zone)

CreditBooster.ai’s mission is to help every American understand, build, and own their credit. We’re an AI-native credit platform, live on the App Store and Google Play, with real paying customers and a small remote team across the US, Europe, and now the Americas.

About the role

This is the seat that anchors our engineering day in the Americas.

Our backend runs on European hours today. We want the product covered across a much longer working day, so that a production issue at 3pm Chicago has an owner who is awake, and so that work moves while the other half of the team sleeps. You’d own that side of the clock.

That means real autonomy, not a night shift. For most of your day you’ll be the senior backend engineer on duty: you’ll make the call, ship it, and hand off cleanly. We’re looking for someone comfortable being the most senior person online for a stretch of the day, who writes things down well enough that the handoff actually works.

It also means a platform flavor, not just feature work. Centralized logging, monitoring, alerting, and notification infrastructure are part of this seat. We are past the point where a small team can run on hope and a message in chat.

AI is not a slogan here, it’s how we build. Our designer shipped the referral page that’s live in production working with an agent. Our CPO built one of our web apps the same way. The standard is not handing a ticket to an agent and approving the result: you plan with it, read the plan properly, push back, iterate, and stay responsible for what ships.

We move fast and we’re deliberately not over-gated, even in fintech. Freedom to move, judged on results.

The kind of problems this seat owns

Long-running processes that have to survive. Significant parts of our backend are not request and response. They are processes that run for weeks, depend on outside parties answering on their own schedule, and where the outcome of one step determines the next. They have to be resumable, idempotent, and survive a deploy in the middle. We orchestrate this on AWS Step Functions. If your instinct for “this takes three weeks and can fail at any step” is a cron job and a status column, this role will be uncomfortable.

Third-party integrations where the vendor is the unreliable part. We depend on external providers for regulated data and for delivery into the physical world. Payloads are messy, contracts change under you, and failures are quiet rather than loud. Building the layer that makes an unreliable dependency safe to build on is a large and permanent part of this seat: error taxonomies you can act on, reconciliation between our state and theirs, and detection when something silently never completed. This is the thing we talk about most.

Centralized logging, monitoring, and alerting. We’re consolidating observability onto PostHog, with Sentry on errors, and building out alerting properly: service outages, volume anomalies, and the silent failures that today only surface when a customer writes in. Making those loud is part of the job.

Notification infrastructure. A real event model with types, priorities, batching, and dedup, across push, email, and in-app. This is infrastructure, not a feature.

LLM work with an actual job to do. We run on AWS Bedrock, replacing deterministic logic with model-backed logic where it earns its place. This is not chat: it’s structured output, validation, and evaluation on data that has to be right, in a regulated domain where a fabricated claim is a compliance problem rather than a polish bug.

Payments and subscriptions. RevenueCat across the App Store and Google Play, entitlement webhooks, and the reconciliation nobody enjoys. Billing bugs are the ones users notice first and forgive least.

Email that actually arrives. Resend, with deliverability treated as an engineering problem: bounce rates, sender warm-up, segmentation.

Our stack

• Core: Node.js 22, Fastify, TypeScript, PostgreSQL 17
• AWS: Step Functions, Bedrock, EC2, RDS, S3, ECR, ALB
• Payments: RevenueCat, App Store and Google Play server-side
• Observability and analytics: PostHog, Sentry
• Email: Resend
• Voice: LiveKit
• CI/CD: GitLab

We would rather you know a few of these deeply than list all of them.

Responsibilities

• Own backend services end to end: Node.js, Fastify, TypeScript, and PostgreSQL, from schema design to the endpoint to whether it holds up in production
• Design and own long-running workflows: transitions, retries, idempotency, and what happens when a step fails on day nineteen of thirty
• Build out centralized logging, monitoring, and alerting so failures are loud instead of quiet
• Own the notification infrastructure: event model, priorities, batching, dedup, across push, email, and in-app
• Own our integrations with external data and delivery providers, including the resilience layer around them
• Own subscription and entitlement flows through RevenueCat, including reconciliation
• Work on LLM-backed features where the output has to be structured, validated, and defensible
• Anchor the Americas working day. Diagnose and fix a production problem during US business hours without waiting for Europe to wake up
• Cross the boundary rather than filing a ticket at it. Our web app, landing site, and internal admin are within reach when the surface you own needs them
• Use Claude Code, MCP servers, and your own agents to compress engineering work that used to take days into hours, while staying responsible for everything that merges
• Write the handoff. Async is not a nice-to-have on a team split across nine time zones, it’s the job

What we’re looking for

• You’ve owned something, not just contributed to it. You can point at a service and say it was yours, describe what would have gone wrong without you, and separate what you owned from what your team delivered. This is the single thing we’re screening hardest for
• You’ve built something that had to survive time. A long-running, resumable process: a state machine, a durable workflow engine, a saga, an orchestrator, or a job pipeline with real retry and idempotency semantics. Step Functions specifically is a bonus, the thinking is the requirement
• You have a platform instinct. You’ve owned logging, monitoring, or alerting somewhere and you have opinions about what deserves a page and what deserves a dashboard. You treat an outage nobody noticed as the worse outage
• You’ve made an unreliable dependency safe to build on. Retries, backoff, idempotency, reconciliation, and knowing which failures are recoverable and which are not
• You’re comfortable outside the backend. Node.js and PostgreSQL are the centre of gravity, but you can work in a web codebase and ship something a user can touch without a handoff
• You’re effective alone. For much of your day nobody senior will be online with you. You need to unblock yourself, make a defensible call, and write down enough that the next person picks it up cleanly
• You’re AI-native in how you build. Claude Code or an equivalent agentic CLI is part of your daily workflow. You’ve built your own skills, agents, or MCP servers that automate real engineering work, and you can tell us about a time one was confidently wrong and how you caught it
• You debug for real. Symptom to root cause to verification, and you know the difference between a bug that stopped reproducing and a bug that got fixed
• You ship without waiting for a spec. Often there’s a problem and an owner, not a written specification

You may be a good fit if you have

• 5+ years building product software, with deep Node.js and TypeScript in production
• A backend area you owned in production. Be ready to walk us through it: what it was supposed to do, what broke, what you changed, and how you knew things got better. This is the most important part of your application
• Strong PostgreSQL and API fundamentals: schema design, migrations, async flows, and a feel for what gets slow
• Real experience with long-running or event-driven systems: queues, workflows, webhooks, retries, idempotency
• Enough DevOps to own your own observability: you can set up the logging and the alert, not just read the dashboard
• TypeScript strict-mode discipline (no any)
• Working English at B2 or above, written and spoken. Our team works in Russian and Ukrainian internally, but Linear, code, and customer-facing copy are English
• A working day on Americas hours that overlaps Chicago business hours

Bonus

AWS Step Functions in production, or an equivalent durable workflow engine (Temporal, Airflow, Camunda, or one you built). AWS Bedrock, or serious LLM work in a regulated context. Payments and subscription billing: RevenueCat, Stripe, App Store and Google Play server-side receipts, and the reconciliation that comes with them. Email deliverability as an engineering problem. Fintech, lending, KYC, or other regulated-domain work. Experience being the on-call owner for a service that mattered. A public Claude Code skill, MCP server, or contribution to an open-source agent harness. Founding engineer or first-few-hires experience at a small company, where owning the whole thing was the default.

Logistics

Fully remote, contractor or self-employed. Open to anyone working on Americas hours: Mexico, Colombia, Brazil, Argentina, Chile, or elsewhere in a compatible time zone. Equipment provided.

How to apply

Tell us about one bug you fixed in production: what the symptom was, what the cause actually turned out to be, and how you knew it was really fixed. Short is fine. This is the part we read first. First step is a 30-minute conversation where we’ll ask you to walk us through how you work with an agent, live.