QA Lead

About the role 

Most QA teams test software. We want someone who builds a machine that gets better at testing software every time it encounters a bug. 

This is not a role for someone who "uses AI tools." This is a role for someone who thinks like an architect. You will design a QA system that is legible to machines — structured, documented, and self-improving — so that the knowledge of every bug ever found is permanently encoded, queryable, and feeds back into the next test cycle. The goal is simple: the longer you are here, the harder it should be for us to ship a bug. 

You will own quality for Cash, a digital lending app (short-term personal loans) on Android and web — and that ownership extends from the front end all the way through to the back end. 

You are the first QA hire. You will build this function from scratch. 

There is no existing QA process today. No tooling is chosen. No taxonomy exists. No team is in place. You are the founding hire for this function.

Your first 60 to 90 days will be spent laying the foundation: choosing the tools, defining the bug taxonomy, writing the first skills, and establishing what "done" means across the engineering org. Once that foundation is stable, you will define the team structure you need, propose it, and then lead the hiring yourself. The engineers who join QA after you will be hired because you decided you needed them. 

This is a founder-mode role inside an engineering team. It requires someone who is energised by a blank canvas, not someone who wants to inherit a mature process. 

If you have spent your career executing inside an established QA function and are looking for more of the same, this is not the right role. If you have wanted the mandate to build the system properly from day one and have never had it — this is that opportunity. 

What you will own 

The knowledge base 

Every bug you find — whether in QA or in production — gets documented in a structured, machine-readable format. Not just "what broke" but: what flow triggered it, what the borrower context was, what data state preceded it, what the expected behaviour was, what the actual behaviour was, and which class of error it belongs to. Over time, this becomes Cash's QA Wikipedia — a corpus that an LLM can read and use to generate new test cases, that a new engineer can query to understand failure patterns, and that you can analyse to find where the product keeps breaking. 

This is not documentation for its own sake. It is infrastructure. The test suite is only as good as the knowledge base behind it. 

Skills, not scripts 

For every recurring testing workflow — new feature regression, release smoke test, critical-path sanity check, payment flow validation — you will build a skill: a reusable,

prompt-able test protocol that is AI-executable. When a new engineer joins, they run the skill. When an AI agent is asked to help test a release, it reads the skill. The skill improves every time a bug gets through it. 

The feedback loop 

Every production issue must close the loop. When a bug is found in production, you trace back why the QA cycle did not catch it, update the relevant skill, and add the scenario to the knowledge base. No bug should be found in production twice for the same underlying reason. 

Coverage — front end and back end 

Front end (Android and web) 

● Onboarding and Know Your Customer — Aadhaar/PAN flows, video KYC, bureau pulls 

● Loan application and eligibility decisions — rule engine outcomes, edge cases across credit tiers 

● Disbursement — payment gateway integration, failure states, retry logic

● Repayment — in-app payments, auto-debit, partial payment handling

● Collections and dunning — overdue flows, notification logic, settlement scenarios

● Regulatory compliance — Reserve Bank of India guidelines on digital lending, fair practices code, key fact statement display 

● Cross-platform consistency — Android app and web admin panel 

Back end 

● API contract testing — request/response behaviour, error codes, edge-case inputs

● Rule engine validation — confirming that credit decisioning, eligibility, and pricing logic produces correct outputs for known borrower profiles, including boundary cases

● Data integrity checks — verifying that the right records are created, updated, or flagged after key events (disbursement, repayment, status transitions)

● Integration testing — bureau, KYC provider, payment gateway, and notification service behave correctly end-to-end 

● Regression on back-end changes — any service update, migration, or config change must pass a defined back-end test protocol before reaching production 

Failure-state and idempotency testing 

Disbursements and repayments involve real money. What happens if the payment gateway times out mid-disbursement? What happens if a repayment webhook is delivered twice? What happens when a bureau call fails mid-application? You will own failure-path and retry-logic testing explicitly — not as an edge case, but as a first-class part of every release cycle. 

Audit trail and logging validation 

Every significant event in the borrower lifecycle — application submitted, bureau pulled, decision made, loan disbursed, repayment received — must produce a correct, complete, and tamper-evident audit log. You will test that these logs are accurate. In a regulatory inquiry or a borrower dispute, the audit trail is the evidence. 

Security testing (functional) 

You will own a security testing checklist covering: whether borrower data is exposed in API responses or logs, whether sessions expire correctly, whether API responses are correctly scoped to the authenticated user, and whether error messages leak sensitive information. This is not a penetration testing mandate — that is a separate engagement — but functional security hygiene is part of every release. 

Notification and communication testing 

sends SMS, push notifications, and WhatsApp messages at specific borrower lifecycle triggers. You will test correct trigger conditions, correct content, correct recipient,

and correct timing — including the case where the same event should not produce duplicate messages. 

Performance and load testing 

You will own a baseline load test that runs before major releases — simulating concurrent loan applications, concurrent repayments, and peak traffic scenarios. A lending app that degrades under campaign load is a trust problem, not just a technical one. 

Feature flag and staged rollout validation 

Cash introduces features to specific segments (by tier, cohort, or geography), you will verify that flags work correctly — users outside the target segment do not see the feature, and partial rollouts do not produce inconsistent back-end states. 

What good looks like in 90 days 

● Tooling chosen and set up: test management, bug tracking, and at least basic CI/CD integration 

● A structured bug taxonomy with at least five top-level failure classes, each with sub-types and historical examples 

● A skills library covering the five highest-risk flows (loan application, disbursement, repayment, KYC, collections) 

● Every production bug from the past three months documented in the knowledge base with root cause and skill update 

● A release checklist — covering both front end and back end — that an AI agent can execute the first 80% of independently 

What good looks like in 12 months 

● The knowledge base has enough signal to answer: which part of the product produces the most bugs per sprint, which bug class most often escapes to

production, and whether the front end or back end is the higher source of production risk 

● New features ship with skills pre-written as part of acceptance criteria, not as an afterthought 

● Back-end engineers treat you as a partner in the definition of done, not a gatekeeper at the end of the cycle 

● You have hired at least one QA engineer and defined the roadmap for the rest of the team 

● A measurable reduction in production escape rate compared to the baseline when you joined 

What we are looking for 

Non-negotiable: 

● 3+ years in QA for a fintech or digital lending product — loan origination, payments, or collections 

● Experience testing both front-end and back-end services — API testing, database state validation, and integration testing must be in your toolkit, not stretch goals ● Comfort with failure-path and edge-case thinking — happy-path testers need not apply 

● Proven habit of writing documentation that others actually use — not as a compliance exercise but as a tool 

● Hands-on experience using LLMs (Claude, GPT-4, Gemini) to generate test cases, analyse logs, or review coverage gaps 

● Ability to write basic automation scripts in Python or JavaScript — you do not need to be a developer, but you need to be able to build and maintain simple automated checks 

Strong signal:

● You have built something like a bug knowledge base before — even informally — and can show us what it looks like 

● You have thought about the difference between documentation as a record and documentation as infrastructure 

● You have worked in an environment where a decision made by a system had a direct financial consequence for an end user, and you understood the stakes that came with that 

● You have hired or mentored QA engineers before 

Why this role is different 

Most QA roles are reactive. A bug is found, a ticket is filed, the developer fixes it, QA closes it. The institutional knowledge of why that bug happened lives in someone's head or in a comment nobody will read again. 

We want the opposite: a QA function that compounds. Every bug makes the next release safer. Every production incident makes the test suite smarter. The person who builds that system is not a tester. They are an engineer of quality infrastructure.

Why Join Us? 

● Work directly with Founders: Mikhil Innani, former co-founder of PharmEasy and ex-Product Head at Hotstar, and Diksha Nangia, a former banker and CFA Charterholder 

● Best of both worlds: startup speed + listed company stability 

● High ownership, strong learning curve, and direct business impact ● A fast-paced, collaborative culture that values innovation, ownership, and bold thinking

Learn More About Us 

● Annual Report 2024–25 

● Vision Video