Build the AI platform other people build their platforms on.
Supero is an AI-native platform for building software. Describe the system you want and it produces the whole thing — typed relational data model, REST and CRUD APIs, SDKs, admin panels, a React front end, transactional services, workflows — running at a real URL. Point your own AI editor at it over MCP and an agent does the building. The applications people ship on it have no upper bound; we are hiring the engineers who raise the ceiling underneath them.
6 open roles
All remote for now — we hire across SF Bay Area and Bengaluru.
Senior Backend Engineer (Python)
When our state machine is wrong, somebody’s money is wrong. That is the entire job description.
Full Stack Developer (React, Python)
Fix a component here and you fix it in every application on the platform — which is exactly as powerful and as dangerous as it sounds.
Cloud / Platform Engineer (Kubernetes, GCP, AWS)
We deploy other people’s applications on demand — a generated app becomes a live URL. That is an infrastructure product hiding inside an application platform, and you would own it.
Forward Deployed Engineer (Applications)
Model a new business domain about once a month, build the whole application on Supero, then break it on purpose and tell the platform team exactly what gave way.
Technical Support Engineer — Developer Platform
Our users are engineers building production systems. “Have you tried logging out and in again” is an insult. This is a support role with root access to the truth.
Software Engineer Intern (Backend / AI)
Most internships hand you a sandbox. We do not have one to hand you — the parts of the platform that are missing are genuinely missing, and one of them would be yours.
None of these quite you?
Build something on Supero instead. It replaces our screening call and our take-home, and it works even if your CV would not otherwise get past us.
If you are reading that list and counting what you are missing: apply anyway, and do the build challenge. It outranks the list.
What you would actually work on
Six areas. Whichever one you join, the work is the same shape: somebody else’s production system depends on it being right.
AI, four different ways
Turning a description into a running system. The MCP surface an outside agent drives. The assistant that ships inside every generated app and answers questions about its data as the signed-in user. And apps calling a model directly for one feature. Four different hard problems.
The builders
App Studio, Schema Studio, the MCP endpoint, and the plain API underneath them. Four ways in, one governed result — keeping them honest with each other is the work.
Platform core
Data, storage, APIs, auth, code generation, SDKs, roles and multi-tenancy. Tenancy is the record’s address rather than a column someone remembered to filter on. This is where most of the platform lives.
Transactional services
Orders, payments, two-phase inventory, subscriptions with dunning, a double-entry ledger, e-signature, approval chains. State machines that have to hold under concurrency, and sagas that have to walk back cleanly when a step fails.
Connectors
Reading and writing a customer’s own Postgres, MySQL, Oracle, Mongo, Snowflake, BigQuery and the rest — live, per table, with cost guards so a bad query cannot run up someone’s warehouse bill.
Deployment
Turning a generated application into a real URL — on our infrastructure or inside the customer’s own AWS or GCP account, without ever holding their keys. There is more shell script in this than any of us like.
You can check us before you talk to us. Our MCP descriptor answers with no account and no key — curl https://api.supero.dev/mcp/v1/info. Almost nobody in this category lets a stranger do that. Then go build something on it; the challenge below is the fastest way to find out whether this is the problem you want.
Where we are
We are an early-stage startup, growing fast, working at the front of where AI meets production software infrastructure. We are a small team across San Francisco and Bengaluru, and this is a deliberate hiring wave rather than a slow trickle — which is why 6 roles are open at once.
Why we think this position gets stronger, not weaker, as models improve: the hard part of a production backend was never generating the code. It was the invariants underneath it — tenancy carried at the record’s address, saga compensation that survives its own failure, field-level access enforced on every read path. A model can write a handler. It cannot hand itself a platform that makes the handler safe. That is what we build, and it is why we exposed it over MCP so any agent can drive it.
Build something on Supero and skip our take-home entirely
The most reliable signal we have ever had about a candidate is an application they built. So we made it the front door. Build a small system on Supero — over MCP from your own AI editor — and send us the link: it shows us you understand the platform far better than a résumé line can. Aim for 90 minutes, and note there are two equally valid ways to satisfy this, listed below.
Bring your own idea, and scope it small.
We build tooling that generates full-stack apps — it would be strange to ask you to interview without it. So bring your own idea, use whatever gets you there, and be ready to explain every decision inside it. Model something you actually know: a domain you have worked in, or a system that annoyed you. Three to five entities, two roles, one thing that can go wrong. Aim for 90 minutes; four hours is the hard cap.
Turn multi-tenancy on when you generate — and notice that you had to.
It is a generation-time flag, it defaults to off, and it is expensive to retrofit. We think that default is wrong. It is the same shape of problem we criticise elsewhere — opt-in per thing, someone has to remember, painful to add later — and it is on the list to change. We are telling you because you will hit it, because we would rather you hit it knowingly, and because what you would do about it is a question we would genuinely like your answer to. Meanwhile: switch it on, because we do look at whether your model survives a second tenant.
Send a screenshot, the link, and your read on us.
A screenshot of your application’s landing page is the one thing we always want — a running app can go down, and the screenshot survives. Send the live URL too, and optionally push the source to your own GitHub and send that link. Then a few paragraphs: what you were modelling, one decision you reversed, and two things about Supero itself — what you liked most, and what you would improve. That last one is not a courtesy question. What you notice tells us how you think, and we act on it.
What you get back.
A person reads every submission — not an auto-responder, and not a keyword screen. If it moves forward, an engineer writes back with what they saw in your model. And a completed build replaces our screening call and our take-home entirely: you go straight to a technical conversation with the people you would work with.
What we actually score. Not visual polish. Whether the data model survives a second tenant, whether you handled the state that has no happy path, and whether you noticed something wrong with our platform and said so. A three-entity app with a defensible model and a sharp bug report beats a twenty-screen app that only works if you click in the right order. It works even if your CV would not otherwise get past us — a live URL beats a line on a page.
Two ways to satisfy this. Pick one — they are scored the same.
Build it over MCP — the one we prefer
Point Claude Code, Cursor or Copilot at Supero’s MCP server and drive the whole build from your own editor. This is the route we would rather you took: it is how the platform is meant to be used, it is the closest thing to the actual job, and it tells us the most about how you think. App Studio exists and works, but MCP is what we are looking for here.
Send something you already built
Any stack, any age, any domain — plus one page on the data model and the decision you would now reverse. Scored exactly the same way. Nothing about this route is a lesser option.
How we work
Whole problems, not ticket queues
You own a service or a surface end to end — the design doc, the code, the migration, the tests and the incident. Nobody here is handed a ticket with the thinking already done.
We deploy daily, and safely
Changes go out behind flags and every change is reviewed. A fix you write on Tuesday is usually live on Tuesday. Nobody here is on a heroic release schedule, and the surface being large is a reason we are deliberate about what we pick up — not a reason to work weekends.
Correctness is the culture
Our end-to-end suite asserts on the specific error a call should return, not just that it failed. We have a standing rule that a test whose name claims more than its body proves is worse than no test at all.
Written first
Design docs and RCAs before code, because the argument is the expensive part — and because writing is how a team split across twelve and a half hours of time difference stays coherent without living in meetings.
Remote, with one bounded overlap
Everyone is remote right now, across India and the US. That only works if the overlap is deliberate: we hold one defined window rather than a handoff wall, it is bounded, and it rotates — it is not a standing 9pm call that always lands on the same person. Everything else is written down, which is why we care so much about the writing.
We publish our own gaps
Ask us in the interview what is broken. You will get a straight answer and probably a link. We would rather tell you before you join than after.
How this goes
Every step, stated up front, so you can decide whether to start it. No fixed timeline — we go as fast or as slow as it takes to be sure, in both directions.
You apply
A person reads it. No keyword screen. If you did the build challenge, that is what we read first.
30-minute conversation
With the person who would be your manager, about what you have built. Skipped entirely if you submitted a build.
90-minute technical session
A real problem from our backlog, or a walkthrough of your build. No algorithm puzzles and no whiteboard trivia.
Two 45-minute conversations
With people you would work with. One is a design-review simulation, which is the closest thing to the actual job.
Founder conversation, then offer
We tell you where you stand after every stage, including when the answer is no.
Find us
Have a look before you apply, or after — both are public.
Equal opportunity
Supero is an equal opportunity employer. We consider all applicants based on their qualifications, skills, and experience, without regard to race, color, religion, caste, sex, pregnancy, sexual orientation, gender identity or expression, national origin, citizenship or immigration status, age, disability, medical condition, marital or family status, veteran status, or any other characteristic protected by applicable law.
We maintain an Equal Opportunity Policy and designate a Liaison Officer in accordance with the Rights of Persons with Disabilities Act, 2016. We also maintain an Internal Committee in accordance with the Sexual Harassment of Women at Workplace (Prevention, Prohibition and Redressal) Act, 2013.