Plug VrittOS Into the Code You Already Have

Until now, every VrittOS project began the same way: you describe an idea, the platform asks you questions, and the code gets written from nothing. That is the right shape for a new product. It is the wrong shape for most founders we talk to, who already have one — a codebase that a contractor built, or an earlier version of themselves built, that works well enough to have customers and badly enough to need the next thing.

Those founders could not use VrittOS at all. There was no way in.

There is now. Start from an existing repo connects a GitHub repository you already own, reads it, and produces the documents VrittOS would have produced had it built the product itself — so that Add a feature works on top of your code exactly as it does on a project we built.

What "reads it" means

The scanner clones your repository and works through it in nine stages, each one narrated on screen as it happens. The interesting stages are these:

1. Tech stack, without guessing. Your manifests — package.json, .csproj, pubspec.yaml, and the rest — say what the stack is. No model is asked; the files are read. Angular next to a .NET API is recognised as exactly that.
2. A module map. Which parts of the repository are the frontend, the API, the shared library, the tests — and which files best explain each one.
3. A product requirements document, as built. Not what the product should do — what the code does today. Anything the scanner had to infer rather than read is marked (inferred), and what it could not work out goes under an explicit "assumptions and open questions" heading rather than being guessed silently.
4. An architecture document in the same shape the platform writes for its own projects, including the build and test commands it detected.
5. A design system, when your app has a user interface — the palette, typography and component conventions the existing screens already follow, so new screens match.
6. An as-built backlog. The epics and stories that would have produced this code: "Users can sign in with email and password", "Agents can assign a ticket to a colleague" — each one linked to the files that implement it.

That last one is what makes everything afterwards work. When you later add a feature, the planner sees the existing backlog and the files behind it, and plans the new work as an extension of your modules rather than a fresh start.

You check it before anything builds on it

Inference from code is wrong in places. It will always be wrong in places — a repository does not record why a decision was made, and a scanner reading a rate limiter cannot know whether it exists for cost, for abuse, or because someone copied it from a tutorial.

So the scan does not go straight to "done". It stops at a review screen: the requirements document is editable, the architecture and backlog are laid out with the files behind each item, and the scan shows its own working — how many files it read, which commit, which tier. You correct the requirements where the scanner misread your product, then approve. Every feature you add afterwards is planned against the corrected version, not the inferred one.

That review is deliberately not optional. Fixing one document once is cheap. Discovering, three features later, that every plan assumed something untrue is not.

What it costs, and why it is priced that way

Scanning is priced by the size of the repository — specifically by the number of source files, counted before anything starts:

Tier	Source files	Credits
Small	up to 300	20
Medium	up to 1,500	40
Large	more than 1,500	80

Three things about this are worth knowing.

The quote is free. Counting files is one call to GitHub and involves no AI at all, so you see the price before a project exists — and before anything is charged. A repository with no source files on the branch is refused outright rather than priced.

"Source files" means code. Configuration, lockfiles, generated migrations, minified bundles and vendored packages do not count. A repository with two thousand JSON fixtures and forty TypeScript files is a small repository.

A bigger tier buys a deeper read, not just a bigger bill. This is the part that is not obvious. Reading a repository with AI does not get more expensive as the repository grows — the model reads a bounded amount of it whatever its size. So a large repository priced as a small one would simply be read less thoroughly, and the features planned against it later would be planned against a thinner picture. The tiers exist so that a large codebase gets a proportionately larger sample of its own source in front of the model. You are paying for depth.

The credits are charged when you start and refunded in full if the scan fails for any reason on our side — a clone that times out, a worker that crashes, a result that never arrives. Every one of those paths pays you back, and none of them can pay you back twice.

What it does not do yet

The scan is a snapshot at one commit. If your team keeps committing to the repository outside VrittOS — which they should — the requirements and backlog do not update themselves. The code the AI developers work against is always fresh (they read the repository again every time they implement something); only the documents go stale. A paid re-scan is the obvious next step and is not built yet.

The repository picker shows your hundred most recently pushed repositories. If yours is not among them, type its name.

And to be straight about it: this is new. The first repositories through it will teach us where the scanner reads well and where it does not, and the review screen exists precisely so that you, not we, are the last word on what your product is.

Where this leaves things

VrittOS was a way to turn an idea into a shipped product. It is now also a way to keep shipping a product you already have — same review gates, same pull requests, same rule that nothing reaches your main branch without you. The only thing that changed is where the story starts.