You Paid for Code You Cannot Read. Here Is How to Check You Were Not Ripped Off.

Somewhere on a server sits a folder of files your business runs on, and you could not read a line of it if you tried. You paid real money for it. You take its quality entirely on faith.

You would never accept this anywhere else. If your accountant handed you books you could not open, you would find a new accountant. Yet software gets a pass, because the subject feels technical and questioning it feels rude. The question is fair, though: did you get what you paid for, and how would you know?

Here is the part that should lower your shoulders. You do not need to learn to program to inspect what you bought. The code itself may be unreadable to you, but everything around the code leaves a trail, and the trail is both easy to read and hard to fake. An afternoon in the right places will tell you most of what a professional audit would.

One fairness note before the checks. Most disappointing builds are not theft. They are corners cut under a tight budget, by people doing their honest best at a price that did not allow better. The point of checking is not to catch a villain. It is to find out what you actually own, so your next decision comes from facts instead of fear.

Start with the locks, not the code

The first check has nothing to do with quality, and it is the one that matters most. Access.

Make a short list: the domain name, the hosting account, the code repository, the database, and the app store account if you have an app. For each one, ask a single question. Can you, personally, sign in today, with credentials that belong to you and not to your developer?

If the answer is no for any of them, stop reading and fix that first. Whoever holds the accounts holds the business. A developer who happily hands over access the day you ask is the normal case, and most will. One who stalls, deflects, or explains why it is simpler if everything stays with them has just told you something no audit could say more clearly.

Read the story of the work

You cannot judge what the code says. You can absolutely judge how it came to exist.

Ask for access to the repository, the place where the code lives, usually somewhere like GitHub. If you paid for custom software, this record should exist, and you are entitled to see it. What you find there is a diary of the entire project, and you do not need to understand a single line to read it.

Real work has rhythm. Weeks of dated changes, each with a short note about what was done, building on each other like entries in a builder's site log. That rhythm is very hard to fake after the fact. What you do not want to find is one giant deposit of files labeled final, dated the night before delivery. That is not proof of anything by itself, but it is an excellent reason to ask where the work happened.

While you are in there, look for a file called README. It is the note a developer leaves so the next developer can pick the project up and run it. Its absence suggests nobody ever expected anyone else to work on this.

You do not need to read the code. You need to know whether someone else could.

That is the whole test in one sentence. Every healthy project can change hands and survive. Software that only its original author can touch is not an asset. It is a dependency with your name on the invoices.

The five minute signals

A few signals need no technical knowledge at all, only attention to things you have probably already noticed.

Small changes cost big money. Updating a price or swapping a photo should not produce an invoice and a week of waiting. If every routine edit has to go through the original developer, the product was either built without any way for you to manage it, or arranged so that all roads lead back to one person.

The same bug keeps returning. A problem that was properly fixed stays fixed. A problem that comes back every few weeks was never really fixed, only pushed below the surface, and a product maintained that way gets more expensive every month it lives.

You have no window into your own product. No analytics, no error alerts, no admin view of what is happening. You should not have to ask your developer how your own business is doing.

Publishing depends on one computer. If changes can only go live from one person's laptop, ask what happens when that laptop, or that relationship, is gone. The answer should not involve starting over.

None of these alone means you were cheated. Each one means the product owes you an explanation.

Hire an inspector

For everything the outside cannot tell you, there is a cheap instrument: a short review by an independent developer.

You did not learn plumbing before you bought a house. You hired an inspector. The same service exists for software, and it costs about as much. An experienced developer can open a codebase and report back on three things: whether this is genuine custom work or assembled parts billed as bespoke, whether it is organized so another team could take it over, and whether anything risky is sitting in plain view.

If the report comes back clean, you have bought certainty, which almost nobody who hires a developer ever has. If it does not, you are still ahead. Secure your accounts, skip the accusations, and decide whether to repair or rebuild with real information in hand, because the most expensive option is usually discovering all of this two years later, mid growth, when the cost of fixing has tripled.

We do this kind of review often, for exactly this situation. If you have been wondering about your own build since the day it shipped, an independent look is the quickest way to stop wondering. We are at oddesys.com.