Claude Code app review & optimisation
Your app was written with Claude Code. Now make it an architecture.
Agentic coding tools write a lot of correct code very fast, and none of it has a shape. Three months in, the repository has four ways of doing the same thing, tests that test the mocks, a database schema nobody chose, and a bill for tokens and compute that grows faster than usage. We review AI-written codebases, fix the architecture, and set the guardrails — CLAUDE.md, specs, tests, CI — so the tool keeps helping instead of digging.
We build with Claude Code ourselves, every day. This site and its API are maintained that way — with the guardrails this page describes.
What we see in AI-written codebases
The problems are not bugs. They are the absence of decisions.
Each of these is the tool doing exactly what it was asked, in a codebase where nobody wrote down what the rules were.
Four ways to do one thing
Every session starts from a fresh context, so every session invents its own helper, its own error handling, its own way to call the API. The codebase is consistent only within a file.
Tests that pass and prove nothing
Generated tests mock the thing they should test and assert the mock. Coverage is high; confidence is zero. The first real regression walks straight through.
A schema that grew by accretion
Columns added per feature, no migrations you would trust, money as a float, state on the user row. The data model was never designed; it accumulated.
No boundaries, so every change touches everything
UI, business rules and database calls in one component. The tool's fix for a bug in one place is a copy in another. Velocity falls a little every week.
Cost with no ceiling
N+1 queries, unindexed foreign keys, LLM calls in loops with no cache and no cap. Infrastructure and API bills grow faster than users, and nobody can say why.
Security by assumption
Auth checked in the UI but not the API, secrets in the client bundle, inputs trusted because the model trusted them. The audit finds the first layer of this from outside; the review finds the rest.
What the review delivers
An architecture, written down, with the tool taught to respect it
The point is not to stop using Claude Code. It is to give it — and every human on the team — the same rules.
Architecture review and decision record
Module boundaries, data ownership, the API contract, what is allowed to call what. Two pages of decisions, each with the reason, that survive the next thousand sessions.
Data model repair
The schema you should have: normalised where it matters, indexed where it is queried, money as integers, tenants scoped, migrations reproducible. Moved to without downtime.
Tests that would catch the bug
A thin set of integration tests on the paths that make money, replacing the mocked ones; a policy test for every access rule; CI that runs them on every push.
Performance and cost pass
Query plans read, N+1s removed, caches placed, LLM calls batched and capped, the three biggest infrastructure line items explained and cut.
Guardrails for the tool
A CLAUDE.md that says how the codebase works and what must not change; spec-before-code conventions; lint and type rules the agent cannot argue with; a review checklist for AI-written pull requests.
A team that can keep going
One walkthrough with your engineers, or with you if you are the engineer. Optionally we stay on as the reviewers of the tool's output — a senior pair, not a rewrite.
How the review runs
Two weeks to a written architecture, then optional hands-on
Read first, change second. Nothing gets rewritten before the decision that makes the rewrite unnecessary is on paper.
- Week 1
Read and measure
The repository, the schema, the deploy, the bills. We run the app, trace the slow paths, count the ways each thing is done, and read every test to see what it actually proves.
- Week 2
Decide and write
The architecture decisions, the target data model, the test strategy, the cost plan, the CLAUDE.md and conventions — presented, argued, agreed. You get the documents whether or not we continue.
- Then
Fix the core (optional)
Two to six weeks, in slices: schema migration, boundaries, the real tests, the performance pass. Claude Code does the typing under the new rules; a senior engineer reviews every diff.
- Ongoing
Review the tool's work (optional)
A standing arrangement where every AI-written pull request gets a senior human review before merge. Cheaper than the rewrite it prevents.
How we work with the tool
This site is built and maintained with Claude Code — under rules
goluxgroup.com, its Rails API and the client portal are developed with Claude Code every day. A CLAUDE.md carries the architecture decisions and everything that has bitten us; every non-trivial change starts as a written proposal; the authorisation layer has a test for every rule; nothing merges without a human reading the diff. That is what we set up for clients.
- 312
- API tests, most written by the tool, all reviewed by a person
- 1
- CLAUDE.md that every session reads before touching code
- 0
- policies changed without a test proving the old rule still holds
- 10
- 'things that bit us' recorded so they are never rediscovered
Is this the right page?
For teams who own the repository and want it to hold
This is for you when
- You built with Claude Code, Cursor, Codex or Windsurf and the app is real — users, revenue, a team
- Velocity has fallen and nobody can say exactly why
- The bill — infrastructure, tokens or both — is growing faster than usage
- A hire, an investor or a customer will read the code soon
- You want to keep using the tool, with someone senior checking its work
Not this page, when
- The app was built on Lovable, Bolt or v0 and lives on their hosting — start with the free audit and the migration page
- You need a product built from scratch — that is a different conversation; book a call
- You want a rubber stamp on what exists — the review says what it finds
Questions
Reviewing and optimising a Claude Code app
- Is the answer always a rewrite?
- Almost never. AI-written code is usually locally fine; what is missing is structure. Most reviews end with a data model migration, boundaries drawn around three or four modules, real tests on the paths that matter, and conventions. The code stays.
- Which tools do you cover?
- Claude Code first — it is what we use. Cursor, Codex CLI, Windsurf, Copilot agent mode and Aider produce the same patterns, and the fixes are the same. The guardrails file is named for whichever tool you use.
- What is in a CLAUDE.md that makes a difference?
- Not a style guide. The architecture decisions and why; the commands that must pass; the things that went wrong once and must not again; what must never be touched without asking. Ours is the file we read before every change on this site. The one we write for you is specific to your codebase.
- Can you review without access to production?
- Yes for the architecture, the tests and most of the performance work — a read-only repository and a staging environment are enough. The cost pass needs the bills or read access to the cloud console.
- How is this different from the free audit?
- The audit looks at the app from outside in sixty seconds: secrets, open tables, headers, hosting. The review reads the code, the schema, the tests and the bills over two weeks. Run the audit first; it is free and it sometimes changes the priority.
- What does it cost?
- The two-week review is a fixed price, quoted on the call once we know the size of the repository. The optional hands-on work is scoped and priced in the review itself, so you decide with the numbers in front of you.
Other paths from here
- The free production-readiness auditThe outside view in sixty seconds. Start here even if the code is yours.
- Backend, APIs & cloudWhen the review turns into building: the engineering practice behind it.
- AI engineeringAdding AI features to the app once its foundation holds.
- Lovable migrationIf the app started on Lovable and should leave.
- MVP hardening sprintThe two-week fixed offer for apps with users and risks.
- How we run projectsEvery review runs in Golux Club: findings as tickets, decisions as approvals.
Next step
Send us the repository. We will tell you what shape it needs.
A read-only invite is enough to start. Two weeks later you have an architecture on paper and a tool that follows it.
