[Hiring] Staff Platform Engineer @Hupo

Role Description

We are an AI-native start-up building sales enablement products in the banking, financial services, and insurance industry; already trusted by dozens of enterprise customers (including Fortune 500 companies).

We build AI products for the people who sell insurance and banking products across Asia. An advisor can practise a hard client conversation against an AI persona, get a nudge during a live call, or have an AI agent make the first call for them. Our clients are big, regulated, and spread across markets and languages - which means the interesting problems are latency, reliability, testing things that are not deterministic, security that satisfies a bank, and making an AI sound natural in Thai or Cantonese, not just English.

Two years ago we had one product. Now we have nine surfaces across seven enterprise clients, and most of them were built by hand, one client at a time. That is how you win early deals, and it worked. It will not keep working. The same things - tenant configuration, identity, access to models, evaluation - now exist in several slightly different versions, and every new client costs more engineering than the last.

We want one platform underneath all of it: shared services, configuration per client instead of code per client, and eventually a builder that lets us assemble a new use case instead of engineering it from scratch. This role leads that. You would own the platform core, pull shared capabilities out of products that have to keep shipping while you do it, and set the technical bar for a team of about seventeen engineers across India and Southeast Asia. It is hands-on. You would write code every week. It is not a management job and it is not an architecture job that ends at a diagram.

What you would actually do:

• Build the shared pieces our products use - configuration, identity and permissions, tenant isolation, model and retrieval access, evaluation - once, properly.
• Extract them from the existing products without stopping delivery, and get more than one team to adopt what you build. The adoption part is the hard part.
• Make the architecture and migration calls across repositories, from design through to running in production.
• Set standards for ownership, review, testing, security and release, and hold them when a deadline makes it tempting not to - while helping the team find a way through.
• Give teams a safe way to vary behaviour per client, so nobody needs a fork or an if-statement with a client's name in it.
• Work with our infrastructure engineers on deployment, CI/CD and observability.
• Make sure every important system has a second owner. Including the ones you build.

First three months:

• Month one: get to know the codebase and the platform work already under way; agree the migration sequence with the working leads; become second owner of one critical system.
• Month two: first shared capability extracted and running in production for one product, with tests, an owner and an adoption plan for the next.
• Month three: a second product adopting it or migrating; the next two quarters of platform work written down and agreed; a named second owner for what you have built.

Qualifications

• 8 or more years building production backend systems, and real Staff-scope experience: architecture across several teams, migrations you led from start to finish, adoption you drove in teams that did not report to you.
• Deep production TypeScript and Node.js. Comfortable in Python, and comfortable reviewing code outside your main language.
• Multi-tenant SaaS for real: you have designed, tested and operated the controls that stop one client's data reaching another.
• You have taken a monolith apart, or pulled shared services out of one, while it stayed in production - and you can tell us what you did first, why, and what went wrong.
• Infrastructure judgment: Kubernetes, GCP or AWS, CI/CD, observability. You do not need to run it, but you design for it and you review it.
• Good security and data-handling instincts, ideally from somewhere regulated.
• You write clearly. This team spans three time zones and most decisions travel in writing.
• You can push back on an unsafe shortcut under pressure and still have the person's trust afterwards.

Nice if you have

• Time in banking, insurance or another regulated industry; security reviews, SOC 2, or Singapore's OSPAR.
• LLM application work - model gateways, retrieval, prompt versioning, evaluation harnesses, testing non-deterministic output.
• Internal developer platforms or self-service configuration systems.
• Real use of AI coding tools and an honest view of when they help and when they produce plausible code nobody has read.