Claude Code developer help · Your repository, any stack
Fix your Claude Code app.
Claude wrote most of the code, across many sessions, and now changes are slow and risky. A senior engineer reads the repository, fixes what holds it back, and sets it up so Claude Code keeps working well in it.
Photography is illustrative.
- Code
- Your own Git repository, worked on locally or in a cloud environment
- Stack
- Whatever you chose: often TypeScript and React or Next.js, Node or Python, Postgres
- Hosting
- Your own: Vercel, Railway, AWS or similar
- Project memory
- CLAUDE.md files, .claude/rules, settings and hooks
Who this is for
For founders and teams whose app Claude wrote, and who now need it to hold up.
Claude Code works in your repository, in whatever stack you chose, from the terminal, an editor, the desktop app or the web. The result is ordinary code that you already own, which is the best starting point there is. The same goes for apps assembled from code copied out of Claude conversations; they have the same strengths and most of the same problems.
What goes wrong is usually not any single change but the sum of them. Each session starts with a fresh context window, long sessions are summarised as they fill, and instructions that live only in the conversation fade. The codebase drifts: several patterns for the same job, tests that pass whatever the code does, and settings opened up to move faster. We bring it back to one design and set the project up so Claude keeps to it.
Failure modes
The ways Claude Code apps go wrong.
These are what we look for first in a repository written mostly with Claude Code. Each comes from how agent sessions work, and each is fixable without starting over.
-
A CLAUDE.md that grew until it stopped working
- What you see
- Claude follows some of the project's instructions and quietly ignores others.
- What is actually wrong
- Anthropic's guidance is to keep each CLAUDE.md under about 200 lines, and its documentation is plain that memory is context, not enforced configuration. A long file of rules gets partly followed, and nothing in it can block an action.
- How we fix it
- A short CLAUDE.md, path-scoped rules in
.claude/rulesfor the details, and hooks, linting and tests for anything that must never happen.
-
Every session starts from scratch
- What you see
- Each new feature comes with its own way of loading data, handling errors or checking permissions.
- What is actually wrong
- Each new session starts with a fresh context window, and when a long session fills it, older detail is summarised away. Claude reads the files it searches for, not the whole repository, so a decision it cannot see is a decision it may remake differently.
- How we fix it
- We map the architecture, choose one pattern for each concern, consolidate onto it with tests in place, and write it where every session will read it.
-
Changes that rewind cannot undo
- What you see
- You rewound to a checkpoint, and the database, the deploy or some files are still in the broken state.
- What is actually wrong
- Checkpoints do not track files changed only by shell commands, most subagent edits, or changes made outside Claude Code, and nothing done to a remote database, API or deployment can be rewound.
- How we fix it
- Development credentials that cannot reach production, database changes as reviewed migrations run from CI, and commits on branches as the real undo.
-
Permissions opened too wide
- What you see
- Claude stopped asking before it ran commands, and at some point it touched something it should not have.
- What is actually wrong
- The mode that skips permission prompts is documented for containers, virtual machines or dev containers without internet access, and the automatic mode's classifier does not guarantee safety. On a laptop with production credentials, either is a risk.
- How we fix it
- Deny rules for production commands and secret files, which apply in every mode, a sandboxed environment for unattended work, and production keys kept off the development machine.
-
Tests that pass whatever the code does
- What you see
- Hundreds of green tests, and bugs in production anyway.
- What is actually wrong
- Tests written after the code, by the same session, often check what the code does rather than what it should do, or mock away the part that matters.
- How we fix it
- We read the tests against the business rules, replace the hollow ones, and add tests that fail first and then pass with the fix.
-
Secrets in the repository or the conversation
- What you see
- An
.envfile is committed, or a key was pasted into a session to get something working. - What is actually wrong
- A key written into code or committed once stays in Git history after it is deleted.
- How we fix it
- Rotate every exposed key, move secrets to your host's secret store, deny Claude access to secret files, and add secret scanning to CI.
Before you hire anyone
What to try yourself first in Claude Code.
- Rewind for recent edits, Git for the rest. Press Esc twice or use
/rewindto restore code from before a prompt. Checkpoints are not version control, so for anything older, or anything done by a shell command, go back to a commit. - Commit before each task. Work on a branch and commit before you hand Claude a task, so one bad session costs one revert.
- Trim CLAUDE.md. Keep it under about 200 lines; move the details into path-scoped files in
.claude/rules, and use/contextto see what is filling the context window. - Plan first. Switch to plan mode (Shift+Tab cycles the modes) and have Claude explain the problem and its plan before it edits anything.
- Deny what must never happen. Add deny rules for production commands and for files that hold secrets. Deny rules apply in every permission mode.
- One session per task. Start a new session for each task, or use
/compactwith a focus, rather than one long conversation whose early instructions have been summarised away.
How we work
How we work on a Claude Code app.
There is nothing to export: the code is already in your repository. We work there, in branches and pull requests, with continuous integration that checks every change, ours, yours or Claude's.
We leave a short CLAUDE.md and rules that describe the architecture we settled on, plus deny rules and hooks for what must never happen, so your next Claude Code session starts from the design instead of guessing.
-
A free 20-minute call
You show us the Claude Code app and tell us what is going wrong. We say what we expect to find, and whether a paid check is worth it yet.
-
Quick Security Check or App Readiness Review
A senior engineer reads the code and tests the running app: data access, keys, sign-in, payments, deployment.
You get Every finding in writing with its severity and fix; the review adds a keep, change or replace call for each part and a fixed quote.
-
Fixed-price fixes
Security & Data Hardening from $7,500, or Production Launch from $15,000, in your repository, with a test beside each fix.
-
Handover
Production kept apart from development, a deploy you can roll back, and notes so you, the tool or any developer can carry on.
Prices
Where to start, and what it costs.
-
App triage call
Free
20 minutes
-
Quick Security Check
$495
Delivered in 48 hours. The fee is credited toward the App Readiness Review.
-
App Readiness Review
$1,500 flat
5 business days. The fee is credited toward any fix booked within 30 days.
Fixes are priced after the check or review, at one fixed price before anything starts. The full price list and how fees are credited.
Proof
Who does the work.
A US software engineering firm. The founding team has taken a product off an AI app builder before (built, not yet in paid use) and runs a production telehealth platform on Supabase. We are an independent firm, not a Claude Code partner or agency. Across the systems the team built and runs:
- 20,900+ automated tests across the systems the founding team built and runs
- 16,800+ CI runs automated builds and test runs on GitHub Actions
- 940+ merged pull requests across the same codebases
Counted from the repositories and CI history of the systems the founding team built and runs, 22 Sep 2026; each figure rounded down. How we counted
Questions buyers ask
Claude Code questions, answered.
Can I keep using Claude Code after you fix it?
Yes, and it should work better: one consistent design, a short CLAUDE.md that describes it, and tests and CI that catch a change that breaks something before it reaches production.
I built it by copying code out of Claude chats, not with Claude Code. Can you help?
Yes. The code is reviewed the same way. Apps assembled from chat answers often lack tests, a deploy pipeline and consistent structure, and those are the first things we put in.
Will you rewrite it?
Rarely. Most code Claude writes is worth keeping. The review marks each part keep, change or replace, with the reason, before any work is priced.
Do you need my Anthropic account?
No. We need access to the repository and, for the review, to the hosting and database.
Are you affiliated with Anthropic?
No. Oracis is an independent US software engineering firm. We fix and finish apps built with Claude Code, alongside apps built with Cursor, Lovable, Replit and other tools.
What does it cost to fix a Claude Code app?
The first call is free. The Quick Security Check is $495 and its fee is credited toward the App Readiness Review, which is $1,500 flat and credited toward any fix booked within 30 days. Security & Data Hardening is from $7,500 and Production Launch from $15,000, each at one fixed price set after the review. We never bill hourly on work nobody has sized. The full price list.
Send us the Claude Code app.
The repository, what worries you about it, and when it needs to be live.