None of these is a bug, so no tool flags them. All of them are visible to a customer, an investor, or a hire looking at your product for the first time.
Twelve pixels here, eighteen there, a card that touches its neighbour on one page and floats on the next. Nothing is wrong, and everything looks slightly off. Polished products use one spacing scale — a short list of allowed gaps — and every screen uses only those.
Each screen was generated separately, so each one invented its own sizes. The dashboard title is bigger than the settings title; the same label is bold on one form and not on another. One type scale, applied everywhere, is the single biggest jump in perceived quality.
The left edge of the heading is two pixels off the left edge of the content below it. Buttons in a row sit at slightly different heights. Icons are not centred in their circles. Users cannot name it, but they feel it, and they trust the product a little less.
Generated code hard-codes colour values inline, so every screen picks its own shade. Text contrast is often below the level people with ordinary eyesight need in daylight. A small palette, defined once and reused, fixes both at the same time.
On a phone the table overflows, the sidebar covers the content, and the primary button is under the fold. On a wide monitor the text runs 200 characters per line. Breakpoints were never designed; they were whatever the generator emitted.
A new user with no data sees a blank white page. A slow request shows nothing, so they click again. An error shows raw JSON. Hover and disabled states are missing. These are the screens real users see first, and nobody wrote them.
Press Tab and nothing shows where you are. Icons have no labels, so a screen reader announces “button, button, button”. Headings skip from one to four, so the page has no structure to a reader. Form errors appear as colour only. Every one of these is a component-level fix, and accessibility law now reaches most of the markets you sell into.
A button that fits “Save” overflows on “Speichern”. Dates print in the wrong order for the locale, numbers use the wrong separators, and a dozen strings were never translated because they were typed straight into the component. Real localisation is a layout and code question, not a spreadsheet, and it shows up the moment you sell outside your first market.
We keep your layouts, your flows and your brand. What changes is consistency — and consistency is what reads as professional. Everything lands in your repository as code, not as a Figma file you then have to get built.
People come to us for fonts and alignment. To fix those properly we have to open the components, and that is where the real condition of the codebase shows. The same four things appear in almost every app we polish, AI-built or not:
Whoever built it wrote a fresh button, card or form for every screen instead of one component used everywhere. That is why the spacing drifts — there is no single place to fix it. It is also why every new feature takes longer than the last: there is nothing to build on, only things to copy.
Margins, widths and colours live as literal values inside each file. Change the brand colour and you change it in ninety places, and miss six. A codebase like this cannot be handed to a new engineer without a week of archaeology first.
Data fetching, business rules and presentation sit in the same file. Adding a feature means touching everything, which means breaking something unrelated. The app is not slow yet; it is stuck, and the polish sprint is often the first time anyone has looked at why.
A role check that exists only in the interface. An endpoint that returns another user’s record if you change one number in the URL. A secret committed to the repository. We are not auditing when we polish — but if we see it, you hear about it the same day, in writing, whether or not you buy anything else.
Because whoever built it — an AI tool or a developer without the years to know better — was optimising for “does it run”, not “does it read as a product”. Each screen was produced on its own, so spacing, type sizes, colours and component shapes drift from page to page. None of that is a bug, so nothing flags it — but a user sees the drift in the first two seconds and reads it as unfinished. It is fixable without redesigning anything: the fix is a consistent set of rules, applied everywhere.
No. The same symptoms appear in apps built quickly by a junior developer or an agency that shipped without a design system: hand-typed spacing, copied components, screens that were never checked on a phone. The cause is the same — no shared rules in the code — and so is the fix. If you have a design file, we match it to the pixel; if you do not, we derive the rules from your best screen and apply them to the rest.
Yes, because they are the same job seen from the user’s side. Consistent components are what make keyboard navigation, focus states and screen readers work: one accessible button used everywhere beats twelve inaccessible ones. We check heading order, labels, contrast and focus on every screen. If the app is translated, we check that longer strings — German, French — do not break layouts, that dates and numbers format per locale, and that nothing user-facing is still hard-coded in the source.
No. A redesign starts from a blank canvas; polish starts from what you have and makes it consistent. We keep your layouts, your flows and your brand. What changes is the rhythm: one spacing scale, one type scale, one set of colours, one shape for each kind of button, and every screen aligned to the same grid. If we think you genuinely need a redesign we will say so, and it is not what we sell.
We usually do, and we tell you in writing before touching them. To fix spacing properly we have to open the components — and that is where we see the same button copied twelve times, the layout numbers typed by hand on every page, and sometimes an authentication check that only exists in the interface. You get a short list of what we saw and its severity. Then you decide: polish only, or a code audit first. Nothing expands without your yes.
Fixed quote, sent within one business day of seeing the app, and you pay when you approve the result. There is no hourly rate. The quote depends on the number of distinct screens and components, which we count before we quote, so the number does not move once you have it.
Want to check your own app first? Read why your AI-built app looks unfinished — six tells and a self-check, no email required.