At Razorpay, the security review had a peculiar problem: it was good. Developers answered questionnaires, attached architecture diagrams to Jira epics, and received careful advice from application-security engineers. Then the volume rose. Hundreds of epics arrived each quarter. The people who knew how to ask the difficult questions were spending their days asking the familiar ones.
A queue formed between the idea and the code. This is the patch of software development Seezo has chosen to occupy: the interval when a feature still exists as a plan, and changing that plan is easier than repairing what it becomes.
- Read the plan: Seezo reviews documents and design artifacts before implementation.
- Return useful work: Threat models, requirements and unanswered questions go back into developer tools.
- Keep someone accountable: Security teams can inspect the reasoning and decide what deserves attention.
The queue was the vulnerability
Application security has a timing problem. A team can teach developers secure practices and scan the code they produce. Between those activities sits a more specific question: what does this particular feature need before anyone builds it? A training course cannot know the answer. A scanner arrives after the feature has begun to take shape.
Seezo SDR, its security design review platform, reads the material teams already produce. A Confluence page, a Google document, a diagram or a Jira ticket becomes input for architectural analysis. The output includes security requirements and threat models. The practical ambition is to give each feature a first pass without requiring a security specialist to attend every planning conversation.
Razorpay connected Seezo to its Jira pipeline. The published case study describes automated analysis for every new epic, with summaries, actionable requirements and open questions returned inside Jira. Missing information becomes something to ask about. Security engineers get a chance to spend their attention on consequential risks rather than routine preparation.
“Teams limit it to their crown jewels.”Ashwath Kumar, Head of Security, Razorpay
A founder learns to read the room
Co-founder Rakshitha Rao’s account of her career begins with penetration testing, the business of finding ways into systems before an attacker does. Her revealing discovery involved a spreadsheet. Taking over communication for a client account, she noticed that several assessments were underway without a consolidated update. She made a tracker and sent it every Friday.
The client later asked for her as its account manager. A small administrative improvement had made a complicated technical service comprehensible. Rao eventually worked in customer success at CloudSEK and PingSafe. At Seezo, she describes her responsibility in six words: “I’m the custodian of the customer.”
Her co-founder, CEO Sandesh Mysore Anand, supplies the security-operator perspective. He previously headed security at Razorpay and advised application-security programs at Cigital and Synopsys. He also writes Boring AppSec, a newsletter whose title suggests a healthy suspicion of theatrical cybersecurity. The pair founded Seezo in 2023.
RAKSHITHA RAO / CCO
SANDESH ANAND / CEOAccel led a $7 million seed round announced in October 2025. Transpose Platform, Trenches Capital, Ahead VC and MyAsiaVC participated alongside angels. The founders said they had served thousands of users worldwide, including paying customers. The distinction matters: a user count describes reach, while enterprise contracts describe a different business.
Which database, exactly?
In March 2026, Anand described rebuilding a stable product around components. Earlier results could identify an affected service or database, but inconsistently. The new approach first extracts components, assets and data flows, then analyzes them. Requirements can point to a particular part of the system.
He also reconsidered diagrams after roughly a hundred customer conversations. Models could work without the picture; people wanted something they could inspect and correct. Seezo began generating data-flow diagrams from its analysis. The map became a shared object for disagreement.
The naive implementation would multiply token use and processing time as components multiplied. The team spent months filtering relevant questions, parallelizing work and assigning different models to different tasks. Anand reports processing-time parity with the previous system. That is a company account of an engineering trade-off, rather than an independent benchmark.
Three customers, three kinds of friction
Ascot Group, the specialty insurer and reinsurer, wanted consistency across reviewers and regions. Its case study describes security teams spending hours assembling components, data flows and trust boundaries before evaluating risk. It briefly considered an internal tool, then weighed development time and maintenance. Seezo supplied a repeatable framework so more people could contribute to reviews.
Sidekick Security had another constraint: consulting engagements have clocks and budgets. Manual design reviews consumed assessment time; skipping them reduced the depth of the work. Sidekick added Seezo to relevant engagements, using the initial analysis to give assessors a head start and downloadable findings to simplify client reporting.
The published customer story reports three times faster reviews and design-review coverage across assessments. Coverage describes work reviewed; it does not establish that every possible vulnerability was found.
Together, these examples show where Seezo fits: enterprise application security and consulting, especially where a limited number of experienced reviewers serve many builders. The product is purchased as SaaS. There is a free starting point, while enterprise buyers go through a sales conversation. The economic question is how much expert time the first pass consumes.
The rule must know the company
Consider an illustrative requirement: encrypt sensitive data. Perfectly sensible, and still unfinished. Which library? Which standard? Has a shared platform already done the work? An instruction that ignores those answers can send a developer on a needless expedition.
Seezo’s July 2026 explanation of its custom-rules engine describes combining design documents, company terminology and individual security checks. Teams can supply their own standards and remediation guidance. A glossary explains internal services. Self-service controls let customers manage rules rather than waiting for Seezo engineers.
That creates a useful point of differentiation from a general chatbot: maintained security logic, local context and traceable decisions. Seezo describes testing prompts against synthetic documents with manually written expected answers. The important capability is being able to follow the path that produced a finding and correct the assumptions behind it.
- 01The existing planDocuments · diagrams · tickets
- 02The system behind itComponents · assets · data flows
- 03The relevant checksSecurity rules · company context
- 04The next decisionRequirements · questions · review
Security joins the coding session
By July 2026, Seezo’s product and engineering leaders were describing a further complication. Coding agents let developers move between design, implementation and testing in one session. A review process built around orderly handoffs can lose its opportunity to intervene.
The Seezo AI Plugin brings guidance, assessments and implementation validation into tools including Claude Code, Cursor and Codex through skills and MCP access. The company also advertises telemetry so security teams can see what ran, when and by whom. The appeal is continuity: requirements can remain part of the work after the original conversation ends.
Implementation validation asks whether code honors reviewed security requirements. Code scanning asks other questions about the implementation. Both remain useful. A design review cannot, by itself, certify an application’s behavior in production.
Borrow the sequence
Seezo’s own guide to scaling reviews offers a sensible place to begin: find where feature plans live, choose when to assess them, and start by identifying higher-risk changes. Then generate useful requirements and open questions, deliver them where developers read, and update the assessment when the plan changes. A team can copy that sequence before making a purchasing decision.
It depends on an honest input trail. If essential decisions remain on a whiteboard, if documents omit critical relationships, or if nobody answers clarification questions, an automated review has less to work with. Internal mitigations need to be described. Someone still has to judge the result.
The founders put their preference plainly: “Automate manual workflows, not humans.” For a security lead looking at another crowded sprint, that is the proposition to examine. How much of the queue can become routine preparation, and how much human attention can be reserved for the question nobody thought to ask?