We test your software, check that it stays fast when many people use it, review its security and set up privacy for the data laws that apply to you. You get a report in plain language, fixes with you, and a re-check before you release.
FindingFinds what breaks before your customers do.
What it is
We use your app the way your customers do: signing up, searching, paying, on different phones and browsers. People find what a script would not think of, and automated tests repeat the checks on every release. Every step we try, and what happened, is written down.
What you get
A test plan in plain words: what we will try, and on which phones and browsers
Manual testing by a person, the way a customer would use the app
Automated tests that run on every release, so old problems do not come back
A report for each round: what passed, what failed, and how serious each problem is
A re-check after fixes, and a short note you can sign off to release
Good fit if…you release often, or one broken screen would cost you orders or trust.
FindingShows how fast your app stays when many people use it at once.
What it is
We send realistic traffic to your app, such as many shoppers browsing and paying at the same time, and measure how quickly pages and actions respond. We find the point where it slows down or fails, and what causes it. You learn your limit before a sale, a launch or a month-end rush finds it for you.
What you get
A plan for your busy days, agreed with you: a sale, a campaign, month-end
Tests run against a copy of your system, unless we agree otherwise in writing
Response times for the pages and actions that matter, shown in simple charts
The slowest points named, with what we recommend to fix them
A second test after the fixes, to show the difference
Good fit if…you expect a sale, a launch or many more users soon, or customers say the app feels slow.
FindingFinds the weak spots in your code and setup, ranked by how serious they are.
What it is
We read your code and look at how your app, servers and logins are set up, and check them against well-known weak points. Each finding is explained in plain words, with how serious it is and what to do. Penetration tests, where a trained tester tries to break in, are done through certified partners.
What you get
A review of your code and settings: logins, permissions, stored keys, and how data is sent and kept
Every finding ranked Critical, Important or Minor, with how to reproduce it and what we recommend
A fix list in priority order, so your team knows where to start
A re-check of the fixes
If you want a penetration test: help to scope it with a certified partner, agreed in writing
Good fit if…you are about to launch, hold customer or payment data, or a customer or investor asks whether your app has been checked.
Good to knowA penetration test is done by a certified partner, not by our own team. See who does what.
FindingGets consent, notices and data requests ready for the data laws that apply to you.
What it is
Data protection laws, such as India's DPDP Act or the GDPR, set rules for how you ask for, use, keep and protect people's personal data. We do the practical setup in your product and your processes: consent, privacy notices and a way to answer data requests. Certified partners review the legal work. This is general information, not legal advice.
What you get
A map of the personal data you hold, where it sits and who can see it
Consent screens and privacy notices in plain language, built into your product
A way to receive and answer data requests: to see, correct or delete data
Rules for who can see personal data and how long you keep it, and a written plan for when something goes wrong
Legal review of notices and policies by certified partners
Good fit if…you collect names, phone numbers or other personal details from customers or staff, and consent and notices are not set up yet.
How we treat your dataWe follow India's data protection law (DPDP) ourselves, sign a data processing agreement with you, and can keep your data in the country or region we agree in writing, such as India. If other rules apply to you, we set out in writing what we do for each. Try spotting the gaps on a sign-up form.
A report is only useful if you can act on it. Every finding we write answers the same six questions, without jargon. Filter these three examples by how serious they are, then open one.
Showing all 3 example findings, most serious first.
3 findings
EX-01CriticalExampleFound in: Security review
A shopper can open someone else’s order
What you saw
A logged-in shopper changed the order number in the page address, and the page showed another shopper’s order, with their name, phone number and delivery address.
Why it matters
Any customer could read other customers’ personal details. That can harm those customers and your name with them. It is a privacy problem as well as a security one.
How serious
Critical Real harm is possible. We recommend fixing it before release.
How to reproduce
1Log in as a test shopper and open “My orders”.
2Open one order and note the number in the page address.
3Change the number to a different one and press Enter.
4Another shopper’s order opens.
What we recommend
Make the server check that an order belongs to the person asking for it, every time. Then check the other pages that use a number in the address. We can show your developers the exact place.
Who decides
You decide whether to release. We advise holding the release until this is fixed and re-checked.
Try it yourself
Spot the gaps on a sign-up form
This form looks normal, and it has six gaps that a careful reviewer would mark under data protection laws such as India's DPDP Act or the GDPR. Tap each numbered spot to see what we look for, what a fix looks like and how we would test it.
General information, not legal advice. Certified partners review legal work. This is a way to see the usual checks. It is not a verdict on any real form.
ExampleA sign-up form from a small business
The form asks for full name, mobile number, email, date of birth, address and a free-text note. It has a ticked box for offers, a line above the Sign up button, a line about a shared sheet, and a tiny Privacy link at the bottom.
Join Sample Studio
Classes, offers and news from your neighbourhood studio.
Full name
Your full name
Mobile number
10-digit mobile number
Email
name@example.com
Date of birth
DD / MM / YYYY
Address
House, street, city, PIN
Tell us about your need
Write anything here
Send me offers and updates on WhatsApp and email
By tapping Sign up you agree to our terms, our offers and sharing your details with partners.
Sign up
Your details are saved in our shared sheet.
PrivacyQuestions? Call the studio.
Example. A made-up form for this page, not a real business.
0 of 6 spotted
Start with any spot
Tap a numbered circle on the form. Each one opens a short note here: what we look for, what a fix looks like and how we would test it.
Your gaps
1Not spotted yet
2Not spotted yet
3Not spotted yet
4Not spotted yet
5Not spotted yet
6Not spotted yet
Three sets of hands
A good check needs three roles. Here is who does what, so nothing falls between us.
1 · Test
Our testing team
We test, review and report.
Plan and run manual and automated tests
Run speed tests with realistic traffic
Review your code and setup for weak points
Set up consent, notices and data requests
Write every finding in plain language, then re-check the fixes
2 · Accept
You, at acceptance
You try it, decide and sign off.
Say which flows matter most to your customers
Try the release yourself, against what you asked for
Decide what to fix now and what can wait
Approve the release, or ask for another round
3 · Certify
Certified partners
They do the work that needs a certificate.
Carry out penetration tests, with a written scope agreed before we start
Review legal work: privacy notices, policies and data protection questions
Give you their report, and we help you read it in plain language
Legal points are general information, not legal advice. Which partner does what, and what is tested, is agreed in writing before we start.
From scope to re-check, in five steps
The same five steps for every check. Your written proposal gives the timeline before any work starts.
1
Agree the scope
We agree what to check: which parts of the app, which devices, which risks, and what “done” means. We write it down before we start.
You receive
A one-page check plan: what we will test, what we will not, and how we will report.
2
Test or review
We run the tests, speed checks, code review or privacy review we agreed. You see progress in a weekly demo.
You receive
A short update each week, so nothing urgent waits for the end of the check.
3
Get a report in plain language
Every finding is written as in the example above: what we saw, why it matters, how serious, how to reproduce it, what we recommend and who decides.
You receive
The report, with findings ranked Critical, Important or Minor, and a call to go through it with you.
4
Fix with you
You decide what to fix first. Where we built the software, our engineers fix it. Where someone else did, we work with your developers.
You receive
A fix list in priority order, with the fixes shown to you as they are made.
5
Re-check
We test again, the same way, to confirm that each fix works and that nothing else broke.
You receive
A re-check note: what is closed, what is still open, and what you need to decide before you release.
Did a fix not hold? The check goes back to step 4 and runs again. A finding stays open until it has been re-checked.
What you keep, and what we need from you
Yours to keep
Every report and finding, as documents you can keep and share with your own developers
The test plans and automated tests we write for you, with documentation
Your code, your accounts and your data. They stay yours
The consent screens, privacy notices and request process we set up, with their documentation
What we need from you
1One person who knows the product and can answer our questions, for a short time each week while we work.
2A test copy of your app, with test logins. We use test data, not real customer data, unless we agree otherwise in writing.
3A short list of what matters most to your customers, such as signing up, paying or booking.
4For a security review: read access to your code and settings, shared safely. We sign an NDA first if you ask.
5For privacy setup: someone who knows what personal data you collect, from whom and why, and any policy you already have.
6Someone who can decide what to fix first and when to release.
Ways to work: once, every release, or a review only
Your quote comes in the written proposal, after we understand what you want checked. It costs nothing until you agree.
Project
A one-time check, from plan to re-check
A fixed scope with a written proposal first: scope, timeline and quote, at no cost until you agree.
Weekly demos while we work
A plain-language report and a re-check
Reports, tests and documentation handed over to you
Questions about testing, security and data protection
Did not find your answer? Ask us in the box below.
Do you test manually or with automated tests?
Both. A person tests the way a customer would use your product and finds what a script would not think of. Automated tests then repeat the same checks on every release, in minutes, so a fix today does not break something tomorrow. The written proposal says which parts we test by hand and which we automate.
How often should we test?
Before every release, at the least. Speed and security checks matter most before a launch, before a busy season and after big changes. On a monthly care plan, we test each release before it goes out.
What is a penetration test, and who does it?
A penetration test is when a trained security tester, with your written permission, tries to break into your system the way an attacker would, then reports how far they got. It is done by certified partners, not by our own team. Our security review comes first, so the test is not spent on easy problems. Before we start, we agree in writing which partner does what, and what is tested.
Do you fix what you find?
Yes, with you. Each finding comes with a recommendation, and you decide what to fix first. If we built the software, our engineers fix it, and 30 days of free fixes after go-live cover problems in our own work. If someone else built it, we work with your developers. Either way, a finding stays open until it has been re-checked.
Which data protection laws apply to us, and from when?
What applies to you, such as India's DPDP Act or the GDPR, and from when, depends on what personal data you handle, why, and about whom. That is a legal question for certified partners, and we do not give legal advice. We do the practical setup: consent, notices, data requests, limited access, deletion and a plan for when something goes wrong.
Will you test our AI agent?
Yes. We try it with real questions from your business, with tricky and off-topic ones, and with questions it should refuse. We check that it hands over to a person when it should, because every AI agent we build has rules for that. If someone else built your agent, we test it from the outside, the way your customers use it. For ongoing care, see AI care and governance.
Tell us in a sentence. A senior engineer replies with which checks fit, then a written proposal with scope, timeline and quote. No cost until you agree.
Quick ideas
Reply within 1 working day · NDA on requestContinue