1. Find your ten slowest requests
Use your monitoring tool or the database’s slow-query log. A handful of requests usually cause most of the waiting. Note which customers and data sizes trigger them.
Home / Guides / Find problems early
How to find problems in your SaaS before customers do.
Five checks you can run this week, what your own team cannot see, and when an independent architecture review is worth it.
Rajesh Ayyavu, TenlyrUpdated 2026-11-03Your five checks this weekTick as you run them
0 of 5 ticked
The short answer
Look for problems where they hide, before customers do. Check your slowest requests, whether one customer can reach another's data, jobs that fail silently, your cloud limits and cost trend, and whether your backups really restore. Then ask someone who did not build the product to review it, because your own team cannot easily see the shortcuts it took.
Five checks, one week
Slow requests, data access, silent failures, bill, backup.
Your team cannot see it
Insiders stop noticing shortcuts.
Rank what you find
Fix now, plan next, keep an eye on.
Five checks you can run this week
Each one takes hours, not weeks.
2. Try to reach another customer’s data
Sign in as customer A and change an identifier in a page address or API call to one belonging to B. The product must refuse. This single test catches a very expensive class of bug.
3. Look for silent failures
Failed background jobs, email delivery, error logs. An invoice that never sends or an import that stops half-way is what customers notice first.
4. Read your cloud bill and limits
Find which line item grew fastest. Check how close the database is to its limits for storage, connections and CPU at busy hours.
5. Restore a backup
Restore one to a separate place and check that the data is complete and how long it took.
What your own team cannot see
The people who built a product stop noticing its shortcuts.
From the inside
- You know the history, so shortcuts feel normal
- A slow page is just the way that page is
- Rules in someone’s memory feel like documentation
From the outside
- A new customer reads the product fresh
- A security questionnaire asks what you stopped asking
- A large buyer wants it in writing
An independent reviewer asks the questions you have stopped asking.And the written report gives you something to show your team, your board or a customer.
Warning signs from customers
“It was faster before”
Usually means: Speed is degrading as data grows.
“Can you confirm our data is separate from others?”
Usually means: A bigger customer is about to ask for evidence you may not have.
“Sometimes it just doesn’t save”
Usually means: Intermittent failures usually point to timeouts, limits or jobs that fail quietly.
“Why did our bill go up?”
Usually means: Your own costs or usage are not measured per customer.
What to do with what you find
That keeps the team from polishing small things while a serious risk waits.
Rank every problem. Tap a label to see what it means.
A Tenlyr architecture review does this for the whole product and gives you a written report in plain words. See the sample report or start with the free checklist.
Keep reading
Why does every update break something in my app?Five causes of risky releases, and what stops them without a rewrite.Why are customers leaving my SaaS?Six technical reasons customers quietly leave, and how to tell if yours is one.What is a SaaS architecture review?What a review checks, when to get one and what you receive.
Written by Rajesh Ayyavu, founder and software architect at Tenlyr. He reviews SaaS products and fixes backend, database and AI problems. Last updated 2026-11-03. LinkedIn
Common questions
How do I find problems in my SaaS before customers do?
Look where problems hide: your slowest requests and queries, access to other customers' data, background jobs that fail silently, cloud limits and the cost trend, and whether your backups actually restore. Then get an independent review for the things your own team cannot see.
What is an architecture review and how is it different from testing?
Testing checks that features work. An architecture review checks the foundations: data separation, access rules, performance under growth, cloud setup and code health. It finds problems that tests written by the same team usually miss.
Can I test whether one customer can see another's data?
Yes, on your own product. Sign in as customer A, find a page or API call that uses an identifier, change it to one belonging to customer B, and check that the request is refused. If it is not, fix it immediately and review how access is enforced everywhere.
How often should I run these checks?
Run the quick checks monthly and before any large customer or release. Get an independent review once a year, or before a major change such as a big customer, a new product area or a funding round.
What should I do with the problems I find?
Rank them. Fix now: risk to customer data or an outage. Plan next: problems that will hurt as you grow. Keep an eye on: things that are fine today. This stops the team from fixing small things while a serious risk waits.
Want someone to look before customers do?
Take the free 30-question SaaS health checklist to see where the risk is, or request an Architecture Review. Rajesh replies personally within 2 business days.