Sdet-1

A bit about axiTrust. And the moonshot we are chasing!

If "surety bond" did not ring an immediate bell, that is the problem and the opportunity.

Every year, thousands of crores of MSME working capital sits locked inside bank guarantees. It is the price businesses pay just to participate: to win a government tender, to bid for a corporate contract, to prove they will deliver. The bank guarantee is how Indian commerce builds trust. It is also slow, expensive and largely inaccessible to the small and mid-sized business that actually does most of the building.

A surety bond does the same job better. It is how a contractor proves to a project owner that they will deliver, without tying up their balance sheet to do it. It is the trust infrastructure that makes tendering work. And in a country running an infrastructure push of the scale India is, the category we are creating has the potential to move GDP, not just metrics.

We are building India's first full-stack surety bond platform for MSMEs, and we are only beginning to discover how far the use case goes. Every industry that runs on contracts, tenders and performance guarantees is a potential home for surety bonds. Every new use case is a new set of relationships to build: Insurers who underwrite the risk, Beneficiaries who accept the bond, Channel Partners who distribute it and MSMEs who finally have access to a tool their larger competitors have always had. This is not a market we are entering. It is a category we are creating.

We were founded in 2024 by serial entrepreneurs and industry veterans who have done this before (ex-founders of numberz, acquired by Chargebee), backed by global VCs and industry veterans, with platform partnerships already running across Government, leading Insurers, corporates and PSUs. We are digital-first and AI-savvy by design. We are also a company where a significant part of the growth happens in person: customer conversations, industry panels and rooms where the right people are making decisions about surety bonds for the first time. Marketing straddles both. The digital engine and the room where it is all being shaped.

We move at the pace of our change-the-world conviction.

Why this role even exists. And why now.

Today, quality is a group activity, which is a polite way of saying nobody owns it. Engineers test their own code. Product clicks through a flow the day before a release. And more often than we would like to admit, the first person to find a bug is a customer, or someone on Customer Success forwarding an angry email. That was survivable when we shipped one product to a handful of design partners. It stopped being survivable the moment we started running three surfaces at once, a B2B insurer product, a B2C customer product and a set of internal tools, all carrying regulated financial data across tenants who must never see each other's rows.

What we are missing is one person who owns quality end to end. Someone who tests the screen the way a real user would, hits the API directly instead of only through the UI, and writes automation so that "did we break anything" is a question the machine answers, not a person re-clicking forty screens every Friday night. We have no staging gate anyone owns, no regression suite worth trusting, and nothing automated. Every release is a small act of faith, and every bug that slips through costs us the one thing we cannot easily buy back from insurers and MSMEs, which is trust.

If this hire lands, releases stop being acts of faith. We ship behind a real gate, a regression suite runs on its own, and one person can say go or no-go and be believed. Customer Success goes back to serving customers instead of moonlighting as our QA team. Engineers get clean reproduction steps instead of vague complaints. And trust, the thing we literally sell, becomes something we can prove inside our own release process, not just promise in a deck.

What you will own. All 4 of them.

The Release Gate. You own staging and the go/no-go on production, across all three products. Code lands on stage, you run regression, you check it against what it was actually supposed to do, and you decide whether it ships. This is not a rubber stamp. You can block a release, and when quality is not there, we will back you.

By 90 days, every production release runs through a gate you own, with a written go/no-go on the record.

By 12 months, defects that escape to production (the ones staging should have caught) are down measurably quarter on quarter, and nothing ships without your sign-off.

Coverage across the whole stack, UI and API. You build and maintain the test plans and cases that cover both the flows a user sees and the APIs underneath them. You walk the happy path once, then you go looking for trouble, the edge cases, the malformed payloads, the broken auth, the cross-tenant access a real user or a genuine bad actor would try. And you test the API on its own terms with Postman or a REST client, checking contracts and status codes, not just whatever the screen happens to show.

By 90 days, a real test-case library exists for the core journeys of all three products, with API cases sitting right next to the UI ones.

By 12 months, no feature reaches production without its own UI and API cases, and the gaps are things you track on purpose, not things you discover mid-incident.

The Automation Suite. You build UI automation so regression becomes the machine's job, not yours. You decide what earns a place in the suite, you keep it green and honest, and you wire it toward the release pipeline. A flaky suite nobody trusts is worse than no suite at all, and you know the difference.

By 90 days, a working UI automation suite covers the highest-value regression paths on at least one product and runs reliably whenever you ask it to.

By 12 months, automated regression runs against every release candidate, and a green run is a condition of the gate, not a nice-to-have.

Triage and the bridge to Customer Success. You are the technical translator between the field and Engineering. When a user reports something, you reproduce it, you work out how much it actually matters, and you hand Engineering a clean, reproducible ticket instead of a screenshot and a shrug. You rank by business impact, not by who shouted loudest.

By 90 days, field issues flow through one triage path you own, and CS comes to you rather than pinging engineers at random.

By 12 months, time-to-reproduce and time-to-triage are tracked and falling, and CS treats you as their first and most reliable technical contact.

Your first 90 days. No nasty surprises.

The first 30 days. Context before change. You learn all three products cold, the insurer side, the customer side, the internal tools, both as a user and as someone trying to break them. You meet Product, Engineering and Customer Success. You watch how a release actually reaches production today, warts and all, and you read the recent bug history. By the end of the month you can explain, with no help, what each product does, where it is fragile, and how code gets shipped.

Days 30 to 60. First coverage, first gate. You put your first test plans on paper for the core journeys and start writing cases, UI and API both. You take staging, run your first regression passes by hand, and write down what a go/no-go actually means here so it becomes a standard, not a mood.

Days 60 to 90. Automation and rhythm. The gate is running and you are the one running it. Your first UI automation is live on the paths that matter most and holding steady. You bring the founders a 12-month quality plan, coverage targets, automation scope, escaped-defect goals, with numbers you are willing to be judged on.

At 12 months. What actually matters. We have a release process we trust, not one we cross our fingers over. A regression suite runs itself, a gate stands between code and production, and escaped defects are down and staying down. Customer Success has stopped moonlighting as QA. Quality has an owner, and it is you.

What a week actually looks like.

40% Feature and regression testing, manual UI and API. The heart of it. You test new features end to end through the UI, and you test the APIs beneath them directly, contracts, status codes, auth, the ugly edge cases. You run regression before releases and you check the whole journey, not just the one screen someone handed you.

20% Building and keeping up the automation. You write the suite, keep it green, decide what deserves to be automated, and push it toward the pipeline. This is real engineering time, not something you squeeze in on a Friday afternoon.

15% Triage and Customer Success support. Reproducing field issues, ranking them by impact, and turning them into reproduction steps an engineer can act on the same day.

15% Requirements and working across teams. Sitting with Product to understand what a feature is meant to do before you test it, and with Engineering to pin down and kill defects once you find them.

10% Gatekeeping. Owning staging, running the final regression pass, and making the call, including writing the sign-off and, when it comes to it, blocking the release.

The people you will work with.

You report to Subham Pathy in Engineering. This starts as an individual-contributor role. You own quality yourself rather than managing a team, with the authority that real ownership needs. As the function grows, so does your remit.

You sit where three teams meet. Product is where you learn what a feature is supposed to do, and where you push back when a flow is confusing or fragile. Engineering is who you work with to isolate defects and confirm the fix, and whose code you stand between and production. Customer Success is who you serve as the technical contact for field issues. You are their way into Engineering and the person who turns a vague complaint into a bug someone can actually fix. You will not manage external partners, but the insurers and MSMEs on the far side of the platform are exactly why the quality bar sits where it does.

Requirements

What we hope you bring.

You have spent one to three years testing real, complicated web applications, ideally in B2B SaaS or a two-sided B2B and B2C setup, and you have done more than walk the happy path. You have written and kept up real test plans and cases. You have gone at APIs directly with Postman or a REST client, checking contracts, status codes, payloads and auth rather than trusting the screen. And you have written UI automation with something like Cypress, Playwright or Selenium, which means you already know the difference between a suite people rely on and one they quietly ignore.

The way you think matters as much as the tools. We want the kind of curiosity that needs to know why something broke, not just that it did. Someone who instinctively plays both the user having their worst day and the bad actor probing for another tenant's data. You can turn a messy failure into clean steps an engineer can follow, and explain a product's behaviour to Customer Success without drowning them in jargon. And you can work on your own, manage your time, rank bugs by what they actually cost the business, and hold a release when it is not ready even while everyone is leaning on you to ship.

You do not need a formal SDET title already, or a framework you built from scratch, to raise your hand here. If you have tested seriously by hand, gone at the API layer directly, and written enough automation to know how it should behave, we can grow the rest together.

What good looks like at six months.

• Every release across the three products goes through a gate you own, with a go/no-go on the record.
  
• A real test-case library covers the core journeys, UI and API side by side.
  
• A UI automation suite runs reliably on the paths that matter and is trusted enough that a green run means something.
  
• Bugs escaping to production are visibly fewer than they were the day you walked in.
  
• Field issues run through one triage path you own and reach Engineering as clean, reproducible tickets rather than forwarded complaints.
  
• Product, Engineering and Customer Success trust your call on quality. Your no-go is respected and your go is believed.
  

The values we actually live by.

I.C.G.R.I.T. is how we work. These values were not written on a retreat and filed away. They have evolved with us over many months. We strive hard that they show up in every interaction, review, every offer letter and more importantly, in every Tuesday afternoon when the easy choice and the right choice are different.

Integrity.

Honestly? This might not be for you if...

• You think working in a regulated, technical, slightly unsexy industry is beneath you.
  
• You want a logo your friends recognise at parties.
  
• You think Friday team socials are a waste of time.
  
• "We have always done it this way" sits comfortably in your vocabulary.
  
• You think QA means clicking through the UI once and calling it done, and that API testing and automation are somebody else's problem.
  
• You want a script handed to you and would rather not wonder why something might break.
  
• Saying no-go to an engineer, or a founder, when quality is not there sounds harder than it is worth.
  

Benefits

What's on the table. Comp and the rest.

• Competitive fixed and variable pay combo calibrated to your experience. The specific range is shared with shortlisted candidates after the first conversation. ESOPs are part of the package, not a footnote.
  
• Health cover for you and immediate family.
  
• Annual learning budget for courses, conferences or that automation certification you have been eyeing.
  
• This is an in-office role based in Gurgaon, working shoulder to shoulder with Engineering and Product day to day. Travel expectations are minimal.
  
• A founders' office that talks to quality constantly, not every quarter.