Shipping Is Not the End: Adding a Feature to an App VrittOS Built

For a while, finishing a project on VrittOS was a dead end in the most literal sense. The last story merged, the run completed, the app was live — and there was nowhere to go. If you wanted a second feature, your only option was a second project: a new idea, a new round of questions, a new codebase. The platform behaved like a generator, and a generator has no concept of next.

That was never the product we meant to build. Real software is not written once. It is written, used, and then changed by what its users turn out to need — and the second feature is where a team either keeps its momentum or loses it.

Add a feature is the way back in. On any completed project there is now a box that says, in effect, "what next?". Describe the feature in plain words, and it is planned and built into the same codebase.

What it keeps, and what it skips

The first build of a product has to settle a lot of things: the tech stack, the architecture, the foundation the rest sits on, the design system. A feature added later should not reopen any of them. So an increment goes through the same gates as an initial build, but each gate is scoped to the feature:

• Clarifying questions are about the feature only. Three to six of them, and they come with an explicit list of what the platform already knows and will not ask again. Nobody should have to re-explain their product to add a search box to it.
• The tech stack and architecture are read, not regenerated. They were decided once. The architecture document is context for the new work, not a fresh draft.
• Design happens only when there are new screens. A feature that lives entirely in the backend — a scheduled export, a new integration — goes straight from requirements to backlog without a design round. A feature with new screens gets them designed against the existing design system, so they match what is already there.
• The backlog is planned against the code. This is the part that took the most work. The planner is shown the stories already built and the files that implement them, so a new feature extends the modules that exist rather than inventing parallel ones. In our own testing this took the planner from referencing none of the existing modules to referencing most of them.
• Everything else is unchanged. Stories, pull requests, tests, review, merge — identical to the first build. The new epic simply joins the existing backlog, marked so you can tell it arrived later.

Two things about the price

Adding a feature never uses another project slot. Your plan's project limit is about how many products you are running at once. It was never meant to charge you for coming back to one you already have.

You are told the cost before you approve the build. When the backlog for a feature is ready, the approval gate says how many stories it contains and roughly what building them will cost in credits — "6 stories, about 120 credits" — before a single one starts. A first build is obviously a whole product; "add CSV export" gives no clue on its own whether it landed as two stories or nine. So the gate says.

The unit prices are the same as an initial build. There is no discount for increments and no premium either. We looked at both and neither is honest: an increment is not cheaper for us to run — a larger codebase means more context for every planning step — and charging more for it would be a tax on exactly the customers who finished.

Why the backlog is one list

There is a design choice here that is easy to get wrong. Internally, each added feature is its own run — it has to be, because every approval a run records is a single moment in time, and reusing the finished run would mean erasing the record of what was approved when.

But that is an internal fact, and it stays internal. In the workspace there is one backlog, one repository, one project. Epics from later features sit alongside the originals with a small "added later" mark, and the credit estimate at each approval gate counts only the feature being approved — not the stories already shipped. We got that last part wrong once, in testing, and quoted a founder for forty-seven stories when nine were new. It is the kind of mistake that is only obvious after it happens.

What comes next

The same machinery now lets a project begin from a repository you already have, rather than from an idea — the scanner reads your code and writes the documents an increment needs, and "add a feature" works from there. That is its own post.

The short version of both: VrittOS is now something you keep, not something you run once.