You can trust it as far as you can verify it. Most agencies and freelancers do honest work, but you're not in a position to confirm that from the outside, and neither is anyone who works for them. Some of the checks need no technical skill at all, and a few need someone independent.
Start with the ones you can do yourself, because they matter most and they're quick.
Who owns what
Ask three plain questions and get the answers in writing.
Who owns the code? Check your contract. Many supplier agreements assign ownership only on final payment, or keep it with the supplier and license it to you. If you're not sure what yours says, a solicitor can read it in minutes. I'm not one, and this isn't legal advice, but it's a check worth making before anything goes wrong.
Where does the code live? It should be in a repository account that you own, with the supplier added as a collaborator. If it sits in the agency's account, you're a tenant. Ask for the name of the account and who the administrators are.
Who controls the hosting? The same goes for the servers or cloud account, the domain name, the app store listings and any third-party services the product depends on, such as payments, email or analytics. If every login belongs to the supplier, you can't switch supplier without their cooperation.
None of this suggests bad faith. Suppliers set things up in their own accounts because it's quicker, and it often never gets moved. The problem only appears when the relationship ends, and by then the leverage is on the wrong side.
What you can check yourself
You don't need to read code to learn quite a lot.
Ask whether there's a staging copy you can see and test before changes go to your live product. If the answer is "we just deploy", that tells you something.
Ask what happens when it breaks at night. Who gets notified, and how would anyone know? Silence here usually means nobody would know until a customer complained.
Ask how a new developer would get started, and how long it would take. A system a stranger can't set up from written instructions depends on the memory of the people who built it.
Ask to see the last few releases. Regular, small releases are a good sign. Long gaps followed by large drops that break things aren't.
Ask for a plain-English description of how customer data is stored and who can see it. You don't need to follow every detail. You're listening for whether they answer clearly or get defensive.
What needs an independent view
Some questions can't be settled by asking the people who did the work, because they have a stake in the answer.
Whether the security holds up. Login and permission handling look finished on the surface and still let one customer reach another's data. The builder has usually tested that it works and rarely tested that it can't be abused.
Whether it will cope with growth. A system that's fine with fifty users can fall over at five thousand, and nothing in the demo will show you.
Whether it's maintainable. The code may run perfectly well and still be arranged so that every change is slow and risky. That's a cost you pay every month for as long as you own it.
Whether the work matches what you paid for. Sometimes a feature exists in the interface and does nothing behind it.
An independent reviewer isn't there to accuse anyone. The point is that somebody with no stake in the outcome reads the code and tells you what's there. Where the answer is good, it's useful to your supplier as well, and a good supplier will welcome it.
If something does look wrong
Don't escalate before you've got facts. A short written report with specific, checkable findings gives you a better conversation than a general sense of unease, and it gives the supplier something to fix.
If the problem is ownership, resolve that first, because it determines your options for everything else.
If you're about to take delivery of a build, or you've been running one for a while and never had it looked at, the code and architecture review is what I offer for that situation: a fixed fee and a written answer. If you're unsure where to start, contact me with what you know so far and I'll tell you what I'd check first.