Location: Remote in India, on our India payroll. You need about four hours of overlap with US Pacific.

Level: Engineer II on our engineering ladder. Roughly 3 to 5 years of backend work. There's a section below on what that means.

Pay: Competitive for the level. We discuss numbers after the take-home.

Apply: [email protected]. Instructions at the bottom. We only read applications that answer the questions.

Recruiters and agencies: we're hiring directly for this one. Anything you send gets the same six questions.

What we do

SimpleTherapy is a digital physical therapy company. Members get personalized exercise programs designed by clinicians that they can do at home, which relieves pain and costs a fraction of in-person care. We reach people through their health plans and employers, so we handle protected health data and work under the rules that come with it.

We run two other businesses alongside it. 3MotionAI does workplace injury-risk monitoring for large industrial employers. ProPlayAI does biomechanics for sports organizations. Three companies, three completely different buyers, one small team.

The job

We're building the system that finds and reaches those buyers, on our own infrastructure rather than renting it. A self-hosted CRM on Postgres, a workflow engine, a language model running on our own hardware, and the integrations that hold it together. Every record and every prompt stays inside our boundary.

You'd build it and then run it. The architecture is written down; the decisions inside it are not.

This is a backend engineering job that happens to serve marketing. You'd work alongside someone who owns the commercial side and decides what the system should do. You decide how it works.

How we work

We're not sentimental about tools. We use what gets the work done and we change our minds when the evidence changes. Being loyal to a framework isn't a virtue here.

We build with Claude Code and similar tools, as standard. That raises the bar on judgment rather than lowering it. The scarce thing becomes noticing when generated output is subtly wrong — which on this system means noticing that everything ran green and produced nothing useful.

We push hard on cost. Self-hosting this instead of buying it is largely a cost decision, and keeping it cheap is part of the job.

The team is small, so the surface is wide. You'd be in schema design, workflow code and infrastructure in the same week.

What you'd build

● TWENTY CRM AS OUR SYSTEM OF RECORD — including migrating our existing CRM into it in your first seven weeks, without inbound ever going dark. After that the schema lives as code in git, pinned to a release tag, deployed rather than clicked.

● The data model that lets three businesses share one CRM without contaminating each other.

● A CONTROL PLANE every workflow has to go through: brand configuration, suppression and consent state, territory rules, API budgets and cost caps, alerting, backups with a restore you actually rehearse, and a staging path.

● A separate reporting database and its nightly loads, so analytics never reads the CRM's own tables.

● Integrations against four external data providers, each with its own auth, rate limits and idea of what a verified result means.

● A local language model in the loop, drafting text that reaches real people — and the checks that sit between it and them.

● The observability that tells us the difference between the system running and the system working.

● The operational layer: Postgres you back up and have actually restored, secrets that aren't in a wiki page, alerting that reaches a human the same day rather than a dashboard nobody opens.

What Core Skills are required

TypeScript / JavaScript (our workflow engine, CRM and CMS are all Node) · Python and FastAPI · SQL and Postgres — you'd design and operate the schema · REST APIs: auth, pagination, rate limits, webhooks, retries · Docker and Docker Compose · Linux · Git

Expected, or a close equivalent

AWS: EC2, S3, IAM, security groups, networking · n8n, or Make / Zapier at real complexity · Serving a model locally — Ollama,



vLLM or similar · Node / Express for small services

Helpful, not required

React and Next.js — our product frontend, and occasional internal tooling on this stack · MCP servers — we're exposing internal systems to AI agents and this will land in your lap · Nginx or Caddy, WireGuard

This is a coding role. The workflow engine is the glue, not the job. You'd be writing code in its function nodes, building small services around it, and reading the source of the open-source tools we self-host. If your automation experience is entirely drag-and-drop with no code in it, this will be harder than it looks — and we'd rather you knew that now.

What we need from you

● Three to five years of backend engineering. Schema design, API work, SQL, and the instincts you only get from debugging things in production. This half isn't negotiable.

● A data model you designed that someone else had to live with. You have opinions about lifecycle state and normalization, and you've been wrong about one of them.

● A migration you ran on live data. Something moved from one system to another while people were still using it, and you were the one watching the cutover.

● Integration work against systems you didn't control. Rate limits, partial responses, and the day an upstream silently changed its response shape.

● Something you built and then operated. Not handed over — ran. Alerting, backups, an incident you handled.

● The instinct to ask where data ends up, not just whether the call succeeded.

● You treat model output as input to be validated, not as a result. You've caught a tool being confidently wrong.

Useful but not required

● Marketing or RevOps experience. You'd work alongside someone who owns that side.

● Email sending infrastructure. It's technical, it's well documented, and you'd be expected to learn it quickly.

● Healthcare, or our particular buyers.

● The specific tools we run. Our CRM is self-hosted open source, so nobody has experience with it.

On the level, before you rule yourself out

We run a published engineering ladder with six IC levels, and this role sits at Engineer II. On our ladder both Engineer II and Engineer III are mid-level: II is developing and owns features within an area, III is established, fully independent, and owns a component or service outright.

The level here describes the scope at hire, not a judgment about you. You'd be building what's specified and owning the decisions inside it. That's II. You move to III when you're setting the architecture rather than implementing ours.

If you're currently titled Senior Software Engineer, which is common at three to five years in India, this isn't a step down. We level on scope. Years served and the title on your last offer letter don't come into it.

We'll show you the ladder during the process, including what moves someone from II to III. Promotions here need written evidence against published criteria and get calibrated across the team.

If you've owned a domain's architecture and technical direction end to end, you may be above this posting. Say so in your application rather than assuming — it's a different level and a different conversation, and one worth having.

Why you might want this

- You'd build a complete system from nothing, on infrastructure you control, with a local model in the loop, serving three real businesses with live deals. There's no legacy to inherit and no committee to convince.
- You'd also report directly to the CEO, which means short arguments and fast answers. The trade is that there's nobody between you and the consequences of your design decisions.
- The remote arrangement is real — four hours of overlap with US Pacific, the rest of your day is yours, and there's no office for anyone to be called back to.




- If moving fast and protecting data feel like they're in tension, this will be a frustrating job.

How we hire - Steps 2-3 Weeks listed below

What happens

- Application — CV, a link to something you've built, six questions. Twenty to thirty minutes.
- Take-home, a time-boxed task that mirrors real work. Four hours, capped — there is more in it than fits, and choosing what to leave is part of it.
- Technical conversation — Seventy-five minutes on your take-home and your answers.
- Offer — References and background checks alongside.

We aim to respond within two business days at every stage. If we slip, chase us.

How to apply

Email [email protected], subject line: GTM Engineer — [Your Name].

1. Your CV.

2. At least one link to something you've built. A repo, a deployed project, a write-up, a demo. Side projects count. If none of it is public, which is common when everything you've done was proprietary, say so in a line and tell us what you'd show us if you could.

3. Answers to the six questions below, in the email or attached.

4. Your notice period, expected annual CTC, your city, and confirmation that the Pacific overlap works for you.

We don't review applications without the answers. It takes twenty to thirty minutes and we read every one that includes them.

About using AI to write your answers

Go ahead. We build with these tools every day and banning them here would be strange. What matters is that the substance is yours. We ask follow-up questions on every answer in the interview, and generic answers don't survive one. A rough answer about something you actually did beats a polished one about something general.

Don't send us

● Code, documents or screenshots belonging to a current or former employer.

● Real customer or personal data of any kind, in any example.

The six questions

1. Describe a CRM data model you built and something you got wrong about it. What did living with that mistake cost, and what did you change?

2. Tell us about a migration you ran — data moving from one system to another while people were still using it. What went wrong with the data on the day you cut over, and how did you find out?

3. Describe a time an automation you built spent money or sent messages it shouldn't have. How did you find out, and what did you put in place afterward?

4. How would you tell that a data pipeline is producing garbage while every run shows green? Give us an example from something you actually ran.

5. Describe something you changed in a system you couldn't easily test. How did you get confident it was right before it went live?

6. How do you use AI tools when you build? Tell us specifically about a time one was confidently wrong, how you noticed, and what you do differently now.

A few short paragraphs each is plenty. If you can't answer one of them, say so and say why — that's a real answer and we'd rather have it than a manufactured one.

Benefits:

- Flexible schedule
- Health insurance
- Life insurance
- Paid time off
- Provident Fund
- Work from home

Application Question(s):

- Describe a CRM data model you built and something you got wrong about it. What did living with that mistake cost, and what did you change?
- Tell us about a migration you ran — data moving from one system to another while people were still using it. What went wrong with the data on the day you cut over, and how did you find out?
- Describe a time an automation you built spent money or sent messages it shouldn't have. How did you find out, and what did you put in place afterwards?
- How would you tell that a data pipeline is producing garbage while every run shows green? Give us an example from something you actually ran.
- Describe something you changed in a system you couldn't easily test. How did you get confident it was right before it went live?
- How do you use AI tools when you build? Tell us specifically about a time one was confidently wrong, how you noticed, and what you do differently now.
- Your notice period
- Expected annual CTC
- Your city, and confirmation that the Pacific TimeZone overlap works for you

Shift availability:

- Night Shift (Preferred)

Work Location: Remote

📌 GTM Engineer III (India)
🏢 SimpleTherapy
📍 India