How Do I Know If My App Is Built Well? The Six Things That Can Be Wrong

One owner building an app for their own business asked the room the question this page answers:

Any idea what I could be missing from not hiring an actual developer?

A working app is evidence about one path: the one you walk, on your account, with your data. Six kinds of wrong can sit under it. Five of the six you can settle yourself or with one other person. The sixth needs somebody who can read the code against what you promised customers.

Nobody gave that owner a sort. They got opinions about hiring. What follows is the sort, taken from a fixed set of applications that were actually read. Across the 26 AI-built applications in AxonBuild’s June to July 2026 study, all reviewed at the code level, with no finding counted until it was checked against the code itself, 22 of 26 carried at least one confirmed critical finding. The scores spread across a 29 to 81 band out of 100, mean 52.1, median 51, and the green band stayed empty. The 26 apps, every denominator, and how each number was produced are on one page.

The pages Google currently returns for this question answer a different one. Microsoft’s Power Apps topic page lists five qualities of a good app: a well-designed user interface, fast loading time, strong data protection, excellent user support, and built-in integrations. As of 25 August 2026, it is a definition with no way to test any of the five against an app you already have. Several more ranked answers are about whether an app idea is worth building at all (designli.co among them), one lists warning signs that an app has aged out, written for a business with a development team and a maintenance budget (yslingshot.com), and the one ranked page written about an AI-built app that already exists (variantsystems.io) runs to 7 categories and more than 30 checks whose own worked examples require reading the code. On both phrasings of this question the top organic result is a community thread asking it, which is a fair summary of the situation: the question has been found and nothing has been written for the person asking it.

Where these six come from: the same 26-app study, sorted by what settles each question rather than by how bad it is. The ranking pages were read on 25 August 2026. Nothing here came from looking at a reader’s app or from driving a tool.

Two neighbouring questions are deliberately left alone. How many of those problems a working app can hide, counted pattern by pattern across the same 26 apps, is a sort of its own and this page does not repeat it. What changes when the app was built for you by somebody using AI tools, and where that one fact moves the weak spots, is a different question from this one and it has its own answer.

What can be wrong under an app that works

Six kinds of wrong, sorted by what settles each one. They are neither a risk list nor a repair order, and both of those exist elsewhere doing different jobs. The order below starts with the one nobody outside your business can settle, because that is the ordering that helps when you are deciding who to ask. The 21 third-party apps in the study carried 958 confirmed findings between them, about 46 per app, of which 58 were critical, so the interesting question was never how many things a review finds. It is which ones you can answer without hiring anybody.

Two of the six rows carry no denominator on purpose. The study logged those two app by app instead of as a rate, so any percentage there would be invented, and an invented number is worse than an honest gap.

It gives the wrong answer and does not say so

This is the wrong that hides in plain sight: a total that is off, a figure that was never real, a button that says saved and changed nothing. In 10 of the 21 third-party apps the server accepted whatever the browser told it, which is the usual mechanism behind a number that is confidently wrong. One app in the study let the customer’s own browser decide the price of an order. Nothing about that screen looks broken from the inside.

The reason using the app rarely catches this is that catching it requires already knowing the right answer, and a known total you can check by hand does catch the cases it covers; reading the code is what covers the calculations nobody has worked by hand. You spot a wrong invoice total when you have added the invoice up yourself. You do not spot a wrong commission split on a plan you have never calculated by hand, and neither does a customer, until one of them does the sum and writes in.

A quieter version of the same wrong is the action that reports success and changes nothing underneath. When the app reports success and changed nothing covers the mechanism, and it is the reason a green screen is not a receipt.

It only holds up for one person

Every app in the study was a working application. What 7 of the 21 third-party apps could not do was keep one signed-in customer out of another customer’s records, and 9 of 21 had a gap in the database rules that are supposed to stop it. A separate 11 of 21 had an endpoint doing privileged work that never asked who was calling, which is the version where the stranger does not even sign up first.

Both are settled the same way: borrow a second pair of hands, make a second customer account, and go after the first account’s records through the paths the app itself uses. That exercise has its own page, written out one step at a time, including the part most owners skip, which is trying to change and delete the other account’s records rather than only read them.

At least 5 of the 21 third-party apps had personal or health data reachable by somebody who should not have reached it. That is the row where the consequence stops being a support ticket and starts being a letter to your customers, which is why it is worth the trouble of finding a second person.

Somebody else can spend your money

Everything metered in a modern app is a bill somebody can raise: model calls, emails and texts, file storage, the database plan. In 13 of the 21 third-party apps, nothing capped how often the most expensive operation could be run, so the cost of running the app was set by whoever felt like using it rather than by how many customers you have. In 8 of the 14 third-party apps with an AI feature, a stranger could also put text where the model would read it as an instruction, which is the same bill with a steering wheel attached.

The settling question is short and you can ask it alone: open the expensive part of the app while signed out, and see whether it still works. If it does, anybody can run it, and the amount they can run it is whatever your card tolerates.

Money leaves the same way at the other end, through a checkout that takes the money and a plan that does not check what it bought. The ways a working checkout still loses money and paid access that ends up free are the two shapes of that. Switching payments on has its own set of conditions, shorter than the six sorted here and ordered by what actually costs money rather than by what sounds serious.

Nothing tells you when it breaks

Of the 21 third-party apps, 17 left a real customer’s error with no record anywhere a person would look. Not in a place you could search, not in an email, not in a screen somebody checks on a Monday. The failure happened, the customer shrugged or left, and the app carried on reporting nothing.

Ask yourself where you would go to read about an error a customer hit an hour ago. If the honest answer is that you would wait for them to tell you, that is this row, and it costs you the one thing that makes every other row survivable: knowing.

Two separate things sit under it. Recording the errors a customer actually hits is one; being told when the app is down at all is the other, and an app can have the second without the first. The third piece is whether anything checks a change before customers meet it, which is where building tests for an app you cannot read comes in. A green test run is not the same evidence as a working app, and the distance between the two has its own explanation.

You cannot get it back

The study recorded this row app by app instead of as a rate, and what it recorded was consistent: changes made straight against the live data with no separate place to try them first, and leftover endpoints from the building phase that could empty or rewrite whole tables for anybody who found the address.

A backup you have never restored is a claim, not a backup, and the question that settles it is when somebody last restored one and how long it took them. Restoring a backup for real, and timing it is the exercise; the reason to run it before you need it is that the first hour after data goes missing is the worst possible time to discover the restore does not work.

You will usually need whoever holds the hosting account for this one, which is why it sits in the you-plus-one-other-person band rather than the you-alone band.

Every change costs more than the last

The last row is the one owners feel long before they can name it. Small changes stop being small, fixes come back with a friend attached, and the same rule turns out to be written into more than one place, so correcting it in one leaves the others still saying the old thing.

Nobody was careless here, and nothing about this row argues for starting again. Code accumulates faster than anybody reads it, which is what a generator is for, and the cost of a change tracks how much unread code the change has to survive. Why each change gets harder rather than easier explains the mechanism, and measuring how far the code has already drifted turns the feeling into numbers you can compare month to month.

The settling question is one you can answer from your own memory or your own messages: did the last five changes take longer than the five before them? If they did, the row is live, and the answer is not to change less. When the tool that wrote the code cannot correct its own output, what to do instead is a different job from any of the checks above.

The one nobody can settle from outside

Five of the six rows are settled by looking at the app from the outside. The first one is not, and pretending otherwise is how people end up paying for a check that could never have answered their question.

Nobody outside your business can tell you a number is wrong, because the right number lives in what you promised customers, not in the code.

A stranger reading your app can see that a total is computed. They cannot see that your refund policy gives a partial credit after thirty days, that your best client is on a rate nobody else gets, that the seat count should exclude deactivated users, or that the tax applies to one line and not the other. Those rules live in your head, your emails, and your invoices. The only way to find out whether the code agrees with them is for a person to read the code with those rules in hand and check them off one at a time.

That is also why the settling question in the table is phrased around your rules rather than around the code. Asking whether the maths is right has no answer in the abstract. Asking whether the screen matches what your own rules say has one, as soon as you supply the rules. You supply the rules. Somebody else supplies the reading.

Plenty of owners can open a file and follow roughly what it is doing, and still have no way to judge whether it is doing the right thing. That gap is normal and it does not close by staring harder. What a person actually does when they read the code, step by step, is worth knowing before you pay anyone to do it. What a code review even is when you cannot read code, what comes out of it, and where it stops being useful, is worth reading before you pay for one.

If you want to know who sells this and what changes hands at the end, who does this, what they charge, and what you get back compares the sellers. Ask any of them how they intend to learn your business rules. An answer that does not include asking you is an answer about the code, not about whether your app is right.

What you can settle this week, and in what order

Order the five settleable rows by what they cost you to answer, not by how frightening they sound. The order below runs cheapest first, and each act proves one narrow thing.

1. Open the expensive part of the app while signed out. If it runs, anybody can run it. This proves nothing about who can read your data, and it is the fastest of the five.
2. Ask where an error from an hour ago would be readable. If the answer is a customer email, nothing is recording failures. This proves nothing about whether errors are happening, only about whether you would hear.
3. Make a second customer account and go after the first account’s records. A denial on one path is evidence for that path only. Repeat it for reading, for editing and for deleting, because an app that refuses one of those three will often allow the other two.
4. Restore a backup and time it. A successful restore proves you can recover the data you tested, on the day you tested it. It says nothing about a table you did not check.
5. Compare how long your last five changes took against the five before them. This is the only row where your own memory is the instrument.

None of the five tells you whether the app calculates your business correctly, which is the whole point of the row above. The ones you can settle yourself are a short procedure run from a browser and an email address, with the exact thing you open and the exact thing you should not see written out in order.

Asked as a decision rather than as a list, the same question becomes whether a working app has earned your trust yet, and that is worth answering on its own. Deciding whether to launch is a narrower job than this one: it asks what evidence the app has to clear before real customers arrive, and it has the gates written out.

If you cannot read the code, what can you honestly say about safety?

An owner who cannot read code can still settle five of the six rows on this page: the second account, the signed-out stranger, the metered bill, the restore, and the cost of the last five changes. What no page or tool can hand you is the sentence that nothing else is wrong.

That is the honest version, and it is worth saying because the phrasing people type here belongs to a different room. Search for whether an app is safe and almost everything that comes back is about installing somebody else’s app on your phone: whether that banking app is trustworthy, whether that game is safe for a child. Those pages are written for a person choosing what to download. You are the person who owns the thing, and the questions are not the same one in different words.

For an owner, the answerable version of the question is narrower and much more useful: which of the six rows above have you actually settled, and which are still open? A row you have tested is evidence. A row you have not tested is only an unknown, and treating unknowns as emergencies is how people end up rebuilding working apps for no reason. Whether an app is safe enough for the business it is carrying is a verdict, and that verdict has its own page with the two-account test on it.

There is a point where the open rows are worth handing to somebody else, and it depends on what the app is carrying rather than on how it was built. Whether an app like yours needs an outside review at all is the route for that decision, and treating it as a default is how people buy the wrong thing.

How do you make an app safer without reading the code?

Safety improves by closing one boundary at a time, in an order, with a way of telling whether each one closed. Before any of that, work out which of the six rows is actually open in your app, because a repair aimed at the wrong row costs money and changes nothing.

The trap in the question is the word make. There is no setting, plan or purchase that makes an app safer as a whole, and anything sold that way is selling you the feeling. What exists is a sequence: find the open row, close that one boundary, then prove it is closed by rerunning the same check that found it. Repairing a boundary once you know which one is wrong runs in an order of its own, and doing it out of order costs you the evidence, which is why the repair order, one boundary at a time is written as a sequence rather than as a list of things to have.

One thing worth saying plainly: no sequence, no setting and no purchase produces the sentence that the app is safe. What a sequence produces is a shorter list of open rows, which is a real result and a duller one than most people expect to buy.

Where each of the six is answered in depth

This page sorts. Each row has somewhere it gets answered properly, and a few of those answers live in pages of their own rather than in a longer section here.

Two questions sit alongside the six rather than inside them. Where the line sits between normal for a young product and a foundation that is wrong is a question about counts, and the numbers behind it are worth seeing before you panic about a bug list. If somebody else built the app and you would rather ask them than check it yourself, what to ask for, what a good answer sounds like and what a stalling answer sounds like is the other half of this.

Common questions about knowing whether your app was built well

Can I tell whether my app was built properly just by using it?

No. Using the app exercises one path, on one account, with data you already trust, and that is the exact path the app was built to survive. Of the six kinds of wrong on this page, none of them announces itself to a single signed-in owner doing normal work. They surface when a second person, a stranger, real traffic or a real failure arrives.

The one partial exception is a wrong number, and even that needs you to know the right answer first.

Is what I am looking for called an app audit?

Sometimes, and the word is doing more work than it should. People searching app audit or vibe code audit usually mean one of two different things: somebody reading the code to find what is wrong, or a security review specifically. The second meaning is the common one, and when an outside review becomes reasonable takes that decision on its own terms.

If what you actually want is an answer to the six rows above, say that instead of the word. Five of them do not need anybody, and naming them gets you a better conversation than naming a service.

Does it matter which AI tool built the app?

Barely, for this question. The six rows come from what nobody asked the generator for rather than from which generator was asked, so the same kinds of wrong turn up whichever tool typed the code. Lovable, Base44, Bolt, Replit, v0, Cursor and Claude Code all produce feature code well and none of them volunteer limits, records or restores.

Where the tool does matter is in where the settings live when you go to fix something, which is a question for the repair, not for the sort.

Can I ask the AI that built it whether it was built well?

You can ask, and the answer is worth about as much as the question is precise. Ask an assistant whether the app is good and it will find something agreeable to say. Ask it whether a specific route checks that the caller owns the record, and it can go and look. The difference is whether the question can be checked against the code, or only agreed with.

Whether the AI that wrote the code can be trusted to judge it turns on whether it can see the failure it caused, which is a question with its own answer.

How long does it take to find out?

Each of the five settleable rows is a single sitting rather than a project, and none of them needs the app taken offline. The one that needs a second person needs their availability more than their time. The sixth row is the one with a real duration attached, because reading code against your business rules is proportional to how many rules you have.

What takes longer than any of this is deciding to look, which is usually the actual delay.

What if I built the app myself and there is nobody to ask?

Then you are the majority case and the sort still applies unchanged. The 26 applications in the study include 5 production apps of AxonBuild’s own, put through the same review as the rest, and none of the 26 reached the green band. Building it yourself does not put you at a disadvantage against somebody who paid, because both of you are missing the same thing, which is a second reader.

The five settleable rows are all things you can do alone or with one friend who will make an account.

Is a working app with paying customers proof that it was built well?

It is proof that the product is worth something, which is the harder half and the half most people never reach. It is not evidence about any of the six rows. Paying customers walk the same narrow path you do, and they will not tell you about a limit that does not exist, a record nobody keeps, or a restore nobody has tried.

Customers do eventually surface one row, the wrong-answer row, and they surface it as a complaint you cannot immediately explain.

If one of the six is wrong, does that mean rebuilding?

Almost never. Five of the six get added to an app that already works; none of them is an argument for throwing it away: a limit, a record, a rule in the database, a tested restore. Even the sixth usually ends in corrections to specific calculations rather than a new app.

Rebuilding is a real option in a narrow set of cases, and it deserves arithmetic rather than a mood. Running the numbers on fixing against rebuilding sets out both sides.

What is the first thing to check if I only do one?

Open the expensive part of your app in a browser where you are not signed in. If it works, a stranger can run your bill up, and that is the row with the largest consequence for the least effort on your part. It is first here because in 13 of the 21 third-party apps in the study nothing capped the most expensive operation, and because you need nobody’s help to check it.

If the app has no expensive part, do the second-account check instead, and get somebody to help you make the second account.