Creditbooster.ai

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

About the role

We're hiring for a mindset more than for a stack: the engineer who treats a piece of the product as theirs and holds themselves to whether it actually works for the person using it.

That means ownership that follows the experience wherever it lives. A flow starts on a mobile screen, continues on the web, and runs through the API behind both, and we want someone who goes all the way down rather than stopping at a repo boundary. That's usually where the quality of an experience is won or lost.

AI is not a slogan here, it's how we build. Our designer shipped the referral page that's live in production today working with an agent. Our CPO built one of our web apps the same way. The standard we hold ourselves to 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.

Fully remote. We hire across Europe and Ukraine and across the Americas, including Canada, Mexico and Brazil, with morning Chicago overlap for standups and demos. Our working overlap is only about four hours a day, so being genuinely effective asynchronously matters here. We'd rather say that plainly than have you discover it in month two.
 

Responsibilities

• Own a product surface end to end: the mobile screen, the web equivalent, and the API behind both, with accountability for whether it works and not just for whether it shipped
• Ship across React Native (Expo) on iOS and Android, our web app, and our Astro landing site
• Cross the boundary rather than filing a ticket at it: Node.js, Fastify, TypeScript, and PostgreSQL are within reach when the surface you own needs them
• Hold the quality bar on what you own, from symptom to root cause to a fix you can prove held
• 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
• Manage releases across App Store and Google Play: EAS builds, rollouts, OTA updates
   

The kind of work you'll see in your first sprint

• Taking one user-facing flow end to end and coming back with your own read on where it should be better, across mobile, web, and API
• A recurring production bug traced to root cause rather than patched at the symptom
• A view on the React Native versus native question, argued from the codebase rather than from preference
   

What we're looking for

• You've owned something, not just contributed to it. You can point at a surface in a product 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 have real native experience, and this one is not negotiable. Swift or Kotlin, native modules, and apps you have shipped through App Store and Play Store review. If your mobile work is entirely inside JavaScript, we will not be able to move forward.
• You work across mobile and web. React Native is where most of the product lives, but a surface that stops at the repo boundary isn't owned. You're comfortable in a web codebase and not helpless behind an API
• 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. You see agents as your primary collaborator, and you can also tell us about a time one was confidently wrong and how you caught it
• You debug for real. You go symptom to root cause to verification, and you know the difference between a bug that stopped reproducing and a bug that got fixed
• You're not attached to a framework as an identity. We may move to Swift. We may not. Either way we want someone who argues it from the codebase and then commits
• 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

• 4+ years building product software, with native Swift or Kotlin and apps you have shipped through App Store and Google Play review
• A product 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
• Real web experience alongside mobile: React or a modern web framework, in production
• TypeScript strict-mode discipline
• Enough Node.js and SQL fluency to fix the endpoint behind your own screen
• Effective written communication in English (B2 or higher). Our team works in Russian and Ukrainian internally, but Linear, code, and customer-facing copy are English
   

Bonus

React Native (Expo) in production. Most of the product lives there today, so it helps, but we would rather hire a strong native engineer who picks up React Native than a React Native engineer who cannot go native. Fintech, lending, KYC, or other regulated-domain work. Expo EAS pipeline ownership and store release experience. Astro or comparable modern web frameworks. 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.

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 and Europe. Our users work on improving their credit, learn how credit actually works, and find credit products matched to their profile. We grew 2,211% in six months.
 

The problem you’d own

Credit improvement has the slowest feedback loop in consumer fintech.

Improving a credit score is a long journey, and it moves in long cycles. Reports refresh once a month. Real change takes many months more. Between those moments a user’s score does not move and nothing visible happens. Every product in this category inherits that silence. Most of them fill it with noise, or with numbers they cannot stand behind. We would rather fill it with something true, and that is the design problem you would own.

The second half of it is comprehension. Credit is genuinely confusing, and most people arrive without a clear model of how it works or what to do first. Building that understanding, and making it feel like real movement long before the outcome arrives, is as much of this role as the mechanics are.

Your job is to design the system that fills that gap: a motivation and education layer that makes a 30-day wait feel like forward movement, without ever lying to the user about their score.

That last clause is the hard part, and it’s why this role needs a specialist. We operate under CROA and app-store rules. We cannot promise a score outcome, we cannot imply a guaranteed result, and we cannot reward users for taking on debt. Every mechanic you design has to create genuine momentum inside those constraints. If you’ve only ever gamified things where you could dangle the outcome, this will be a harder and more interesting problem than you’re used to.
 

Where you might come from

We’re as interested in game designers as in product people. If you’ve built progression systems, quest structures, meta systems, or in-game economies, and you want to point that craft at something that changes a person’s financial life rather than their score in a match, this is that job. The discipline transfers. The subject matter is what changes.

To be direct about one thing: this is not an iGaming or casino retention role, and that experience is not what we’re looking for. Bonus mechanics, lootboxes, and win-back offers are the opposite of the playbook here.
 

What you’d own

You’d work alongside our product manager.

• The engagement model. Define the progression system end to end: what counts as progress between report pulls, how it’s earned, how it’s shown, what it unlocks. We have an internal brainstorm covering XP, credit-health levels, streaks, and quest-framed progress. Treat it as raw material to argue with, not a spec to implement.
• Notifications and lifecycle messaging. Our push and email today are functional and forgettable. We want a messaging system built on a metaphor a user can hold in their head, delivered on a cadence that earns attention instead of burning it.
• First-run and education. Design what a new user sees in their first ten minutes and their first month. This is the single biggest lever we have on how a new user starts.
• The retention instrument panel. Decide what we measure, instrument it with our PM and engineers, and hold yourself to it. You should be able to say which mechanic moved which cohort, and kill the ones that didn’t.
• Experiment design. Set up the tests, call them honestly, and write down what we learned. We have PostHog, Amplitude, and RevenueCat in place.
   

What we’re looking for

• You’ve shipped a real system that survived contact with users. Progression, levels, quests, missions, streaks, meta systems, in-game economies, habit loops. In a game or in a product, it doesn’t matter which, as long as it went live and you can talk about what it changed using numbers. Not a case study, not a concept deck.
• You can write the document. A GDD, a systems spec, an engagement model, whatever your discipline calls it. You define the rules, the balance, and what the system refuses to do, clearly enough that designers and engineers can build from it.
• You reason from behavioral science, not from a pattern library. Self-determination theory, the Fogg behavior model, variable reward, loss aversion, the difference between a habit and a compulsion. You can explain why a mechanic works, and you can tell when the honest version of it is weaker than the manipulative version and choose the honest one anyway.
• You are comfortable being the person who says no. Half of good gamification is deleting mechanics. Points for their own sake, leaderboards that shame people, streaks that punish a missed day during a hard month. You’ve killed features like these before and you can explain why.
• You work in the constraint, not around it. Regulated, compliance-bound, or safety-critical product experience is a strong signal. Health, education, finance, insurance.
• You’re hands-on. We’re a small team. You will write the specs, sit with the designers in Figma, brief the engineers, read the dashboards, and argue with the CEO. There is no team under you and no one to delegate to.
   

You may be a good fit if you have

• 4+ years in game design, product design, behavioral design, or learning design, with at least 2 owning a progression, economy, or engagement system end to end
• Evidence a system you built changed how people behaved, and the honesty to also describe something you shipped that didn’t work
• Fluency with analytics and experimentation tooling, and the confidence to design a test that can actually fail
• A plus, not a requirement: experience at a company known for doing this well, such as Duolingo, SoFi, Noom, Headspace, Chime, Credit Karma, Peloton, Babbel, or Strava, or on a live game with real progression and economy systems
• Working English at C1 or above. Our team speaks Russian and Ukrainian internally, but all product artifacts, tickets, and customer-facing copy are in English
   

Nice to have

Consumer subscription experience, especially where the value takes weeks to arrive. Formal background in psychology, behavioral economics, or instructional design. Game design or live-ops experience. Experience in credit, lending, or another product where the user’s outcome is partly out of the product’s control.
 

How we work

Fully remote. You’ll need overlap with Chicago mornings, roughly 8 to 11am CT, for standups and demos. We’re open to full-time and to a focused fractional engagement if that’s how you work best. Tell us which you want and we’ll talk.
 

How to apply

Send us one system you shipped. Tell us what it was supposed to change, what it actually changed, and one mechanic you removed and why. First step is a 30-minute conversation. No take-home before that.

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 and Europe. Our users work on improving their credit, learn how credit actually works, and find credit products matched to their profile. We grew 2,211% in six months.
 

The problem you’d own

Credit improvement has the slowest feedback loop in consumer fintech.

Improving a credit score is a long journey, and it moves in long cycles. Reports refresh once a month. Real change takes many months more. Between those moments a user’s score does not move and nothing visible happens. Every product in this category inherits that silence. Most of them fill it with noise, or with numbers they cannot stand behind. We would rather fill it with something true, and that is the design problem you would own.

The second half of it is comprehension. Credit is genuinely confusing, and most people arrive without a clear model of how it works or what to do first. Building that understanding, and making it feel like real movement long before the outcome arrives, is as much of this role as the mechanics are.

Your job is to design the system that fills that gap: a motivation and education layer that makes a 30-day wait feel like forward movement, without ever lying to the user about their score.

That last clause is the hard part, and it’s why this role needs a specialist. We operate under CROA and app-store rules. We cannot promise a score outcome, we cannot imply a guaranteed result, and we cannot reward users for taking on debt. Every mechanic you design has to create genuine momentum inside those constraints. If you’ve only ever gamified things where you could dangle the outcome, this will be a harder and more interesting problem than you’re used to.
 

Where you might come from

We’re as interested in game designers as in product people. If you’ve built progression systems, quest structures, meta systems, or in-game economies, and you want to point that craft at something that changes a person’s financial life rather than their score in a match, this is that job. The discipline transfers. The subject matter is what changes.

To be direct about one thing: this is not an iGaming or casino retention role, and that experience is not what we’re looking for. Bonus mechanics, lootboxes, and win-back offers are the opposite of the playbook here.
 

What you’d own

You’d work alongside our product manager.

• The engagement model. Define the progression system end to end: what counts as progress between report pulls, how it’s earned, how it’s shown, what it unlocks. We have an internal brainstorm covering XP, credit-health levels, streaks, and quest-framed progress. Treat it as raw material to argue with, not a spec to implement.
• Notifications and lifecycle messaging. Our push and email today are functional and forgettable. We want a messaging system built on a metaphor a user can hold in their head, delivered on a cadence that earns attention instead of burning it.
• First-run and education. Design what a new user sees in their first ten minutes and their first month. This is the single biggest lever we have on how a new user starts.
• The retention instrument panel. Decide what we measure, instrument it with our PM and engineers, and hold yourself to it. You should be able to say which mechanic moved which cohort, and kill the ones that didn’t.
• Experiment design. Set up the tests, call them honestly, and write down what we learned. We have PostHog, Amplitude, and RevenueCat in place.
   

What we’re looking for

• You’ve shipped a real system that survived contact with users. Progression, levels, quests, missions, streaks, meta systems, in-game economies, habit loops. In a game or in a product, it doesn’t matter which, as long as it went live and you can talk about what it changed using numbers. Not a case study, not a concept deck.
• You can write the document. A GDD, a systems spec, an engagement model, whatever your discipline calls it. You define the rules, the balance, and what the system refuses to do, clearly enough that designers and engineers can build from it.
• You reason from behavioral science, not from a pattern library. Self-determination theory, the Fogg behavior model, variable reward, loss aversion, the difference between a habit and a compulsion. You can explain why a mechanic works, and you can tell when the honest version of it is weaker than the manipulative version and choose the honest one anyway.
• You are comfortable being the person who says no. Half of good gamification is deleting mechanics. Points for their own sake, leaderboards that shame people, streaks that punish a missed day during a hard month. You’ve killed features like these before and you can explain why.
• You work in the constraint, not around it. Regulated, compliance-bound, or safety-critical product experience is a strong signal. Health, education, finance, insurance.
• You’re hands-on. We’re a small team. You will write the specs, sit with the designers in Figma, brief the engineers, read the dashboards, and argue with the CEO. There is no team under you and no one to delegate to.
   

You may be a good fit if you have

• 4+ years in game design, product design, behavioral design, or learning design, with at least 2 owning a progression, economy, or engagement system end to end
• Evidence a system you built changed how people behaved, and the honesty to also describe something you shipped that didn’t work
• Fluency with analytics and experimentation tooling, and the confidence to design a test that can actually fail
• A plus, not a requirement: experience at a company known for doing this well, such as Duolingo, SoFi, Noom, Headspace, Chime, Credit Karma, Peloton, Babbel, or Strava, or on a live game with real progression and economy systems
• Working English at C1 or above. Our team speaks Russian and Ukrainian internally, but all product artifacts, tickets, and customer-facing copy are in English
   

Nice to have

Consumer subscription experience, especially where the value takes weeks to arrive. Formal background in psychology, behavioral economics, or instructional design. Game design or live-ops experience. Experience in credit, lending, or another product where the user’s outcome is partly out of the product’s control.
 

How we work

Fully remote. You’ll need overlap with Chicago mornings, roughly 8 to 11am CT, for standups and demos. We’re open to full-time and to a focused fractional engagement if that’s how you work best. Tell us which you want and we’ll talk.
 

How to apply

Send us one system you shipped. Tell us what it was supposed to change, what it actually changed, and one mechanic you removed and why. First step is a 30-minute conversation. No take-home before that.

READ THIS FIRST: you must physically LIVE in the Americas. Mexico, Colombia, Brazil, Argentina, Chile, or another country in North, Central, or South America. This is a location requirement, not a schedule preference. If you live in Ukraine, Poland, or anywhere else in Europe and are simply willing to work American hours, this role is not for you and we will not be able to consider your application. Please do not apply.

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
• You physically live in the Americas and your local working day overlaps Chicago business hours. Living in Europe and being willing to work American hours does not qualify

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. You must be resident in the Americas: Mexico, Colombia, Brazil, Argentina, Chile, or another country in North, Central, or South America. We are not able to consider candidates based in Europe, including Ukraine, however flexible their hours. 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.