Case studyOur own product
We audited our own app before trusting it with more of our customers' money
15
sellers using it every day
₹8.76 lakh
of their ad spend in the last 30 days
357
changes already made on Amazon for them
As at 1 November 2026
When this kind of app breaks, nobody sees an error page
Every night SellerSaarthi reads each seller's Amazon ad results and suggests changes: lower this bid, block that search, add this keyword. The seller approves, and the change goes live on Amazon.
If something goes wrong here, the screen still looks fine. The cost shows up in the seller's ad bill. So we asked four questions:
- Can a change reach Amazon that the seller never approved?
- Can one seller ever see another seller's data?
- If the overnight update fails, who finds out first: us or the seller?
- When billing starts, will customers be charged the right amount, with a proper GST invoice?
How we checked it
- Asked the founder six questions: what it's built on, what runs unattended, what costs money if it breaks, how updates go live, the biggest fear, and what we may access.
- Ran every test, scanned all 1,350 code changes for leaked passwords, and checked every software library for known problems.
- Scored 12 areas by the money at risk, each finding backed by evidence we could point to.
- Tested the founder's own claims instead of trusting them. Five were wrong, including the belief that automated checks had stopped a day earlier. They had stopped 17 days earlier.
- Wrote a fix plan ordered by how much risk each hour of work removes.
Checklist-driven and AI-assisted, with every finding reviewed by a senior engineer. Read-only: nothing was changed while we looked.
What we found
| Area | 1 Nov | 2 Nov |
|---|---|---|
| Login and admin access | Medium | Medium |
| Keeping each seller's data separate | OK | OK |
| Safety of changes made on Amazon | Medium | Medium |
| Payments and GST | High | High |
| Recovering from failures | High | Medium |
| Speed and growth | High | High |
| Messages and notifications | Medium | Medium |
| Alerts when something breaks | High | Medium |
| Testing and releasing updates | High | High |
| Passwords and keys | Medium | Medium |
| Backups and recovery | Medium | High |
| Running the business day to day | High | High |
Serious findings: 16 on 1 November, 13 on 2 November. None critical.
One area got worse. While fixing the others, we found a new risk in how our servers would be rebuilt after a failure. We'd rather show you that than hide it.
What held up
- No seller can see another seller's data.
- Nothing in the code can pause a seller's campaign.
- A change can't be applied to Amazon twice by accident.
- No passwords or keys leaked anywhere in 1,350 code changes.
Where the risk was
- Silent failures. If the overnight update failed, nothing recorded it. Sellers saw "up to date" figures for up to 36 hours.
- Alarms that couldn't ring. 4 of 15 alarms could never go off. One had been showing a warning for 56 days, so everyone had learned to ignore it.
- Unchecked updates. Automatic checks hadn't run for 17 days, while 169 updates went live.
- Billing not ready. Nothing confirmed customers would be charged the price shown, and no proper GST invoice could be produced yet.
What we fixed in two days
A failed update is now visible.
It's recorded, the seller sees a clear warning, and no suggestions are made from out-of-date figures that night.
Alarms that actually ring.
Broken alarms were fixed, new ones watch every seller's account, and the app itself is now checked from outside.
Two risky edge cases closed.
A change Amazon may or may not have received can't be sent twice, and a bid increase that can't be checked against the budget is refused.
Safer releases.
An update can't go live unless it's the latest, fully saved version, and every release records exactly which version is running.
We also said no to one of our own fixes. The audit suggested switching off a seller's account after a failure. That would have stopped their nightly checks and their Undo button after a single Amazon hiccup. We kept the account running and recorded the problem instead.
Then we broke it on purpose
Times in IST
- 12:25Passed
The failure is recorded. The account keeps working.
- 12:26Passed
That night's suggestions are paused for the account, so nothing is based on stale figures.
- 12:33Passed
The seller sees the warning: "Last night's Amazon update didn't finish."
- 12:46Passed
The alarm goes off and the email arrives, 20 minutes 38 seconds after the failure.
- 13:48Passed
A normal update runs and clears the problem by itself.
- 14:01Passed
The all-clear email arrives.
Throughout: nothing was changed on Amazon, and the seller's connection was never touched.
One thing we hadn't planned to test: Amazon's access token expired mid-update and renewed itself. It passed too.
What's still open
- Tighten who and what can change the live systems
- Practise a full database restore
- Prepare for 50 sellers: faster overnight updates and Amazon's rate limits
- Proper GST invoices before billing starts in January
We'll update this page as each one closes.
Built your app with AI tools? Ask yourself three questions.
- If last night's job failed, would you know before your customer did?
- Has anyone actually restored your database, or just switched backups on?
- Does anything check what your payment provider will really charge?
If any answer is 'not sure', that's where we start.
Two-day triage: $349.
What blocks your launch and what can wait, in writing. Free if nothing blocks launch.
Production Readiness Audit: $1,500.
The same 12-area check you've just read about, in 5 working days, with a fix plan.
Fixed-price fix sprints.
We close what we find, with tests and a live drill to prove it.
Shreesoftic is a senior software engineering studio based in Surat, India, founded by Hiren Chheta. It makes AI-built applications production-ready, automates business workflows and integrates AI into existing software for clients worldwide, mostly in the UK, US and India, at fixed prices, with tests, monitoring and measurable outcomes.