Frequently Asked Questions

Vroni is a software delegate: an autonomous AI developer you assign tasks to. Give it a task, issue, bug report, product idea, or spec. It reads the codebase, plans the task, writes code, runs checks, fixes failures, and returns a pull request.

Claude Code, Codex CLI, and similar tools are AI coding agents. They are powerful, but they are usually meant to be used interactively by a developer who plans the task, drives the tool, reviews the output, fixes problems, and keeps the task moving. Vroni replaces the developer in that workflow, not the coding agent. You assign the task and Vroni runs the process. Under the hood, Vroni uses state-of-the-art AI coding agents, including tools like Claude Code and Codex CLI, inside a larger engineering workflow for planning, implementation, checks, failure repair, and follow-up requests. You get the benefit of those coding agents plus a system built to deliver finished software.

Vroni is for anyone who needs software built, fixed, or improved: solo founders, small businesses without developers, agencies, product teams, and engineering teams with more tasks than time.

No. Developers can give Vroni precise technical tasks, but non-developers can also describe the outcome they want in plain language. More detail helps, but a short brief is enough to start.

Vroni can be the only developer for a small product, or an extra senior developer for an existing team. It does real implementation, but you still decide what task to assign and when a result should be merged or shipped.

No. Vroni is built for serious development tasks. It can start from rough input, but the goal is production-quality implementation, not throwaway prototypes.

Vroni can handle features, bug fixes, UI updates, API endpoints, tests, refactors, documentation, integrations, performance fixes, and architecture updates. It is not limited to small tickets.

No. A clear ticket is useful, but Vroni can also start from a rough idea, a bug report, a support note, a product brief, or a follow-up comment. If you give details, Vroni follows them. If you give less detail, it plans from the context it has.

A software delegate is an autonomous AI system that accepts high-level software tasks, executes them asynchronously using development tools and runtime environments, and returns reviewable software artifacts such as pull requests, apps, tests, fixes, or deployments.

Because the main action is delegation. You are not prompting a coding tool step by step. You assign the task, Vroni carries it forward inside clear boundaries, and you get software back.

Delegated software engineering means handing a software outcome to an autonomous system that can plan, implement, check, repair, and return the result. The user provides intent and boundaries; the delegate does the engineering.

A coding agent is usually a tool a developer operates directly. A software delegate is the larger workflow around the task: intake, planning, coding, checks, repair, summaries, artifacts, permissions, and handoff.

A copilot helps while you code. A software delegate takes assigned tasks and keeps going without you steering every step. The difference is not only intelligence; it is the ownership of the workflow until a result is ready.

A chatbot answers in conversation. A software delegate uses development tools, edits real code, runs checks when possible, and returns software artifacts. The output is not just advice; it is software you can inspect and ship.

No. Running in the cloud helps because tasks can run asynchronously, but the category is broader than hosting. A software delegate has a bounded workflow for accepting tasks, executing them, checking them, and returning artifacts.

Bounded autonomy means Vroni can act independently inside a defined task, repository, runtime, permission set, and review process. It is autonomous enough to complete the task, but not unbounded across your whole business.

Depending on the workflow, a software delegate can return pull requests, updated apps, tests, bug fixes, documentation updates, summaries, verification notes, and deployment workflows.

You still describe the task, but you do not need to drive the implementation step by step. A short task can be enough. A detailed spec is still useful when you have one.

It can be, depending on the task. For a small business or solo founder, Vroni can act as the main developer for many tasks. For an existing team, it can take tasks that would otherwise wait for developer time.

Join the waitlist. Vroni is currently in waitlist mode, so joining does not charge you. Paid access will use the published Solo, Team, and Concierge pricing.

You leave your details and the kind of task you want Vroni to handle. We will use that to prioritize access and contact you when your workspace can be enabled.

The first workflow is GitHub-based: connect the GitHub App, assign or label an issue for Vroni, and wait for the pull request. Other intake workflows can be added later.

Start with a real but contained task: a bug fix, a UI cleanup, a small feature, a test gap, a refactor with clear boundaries, or a product update you already understand. After that, give it larger tasks.

No. A full spec helps when you have one, but it is not required. Vroni can start from a few sentences, inspect the repository, form a plan, and produce a sensible result.

Include the desired outcome, relevant links, screenshots, error messages, acceptance criteria if you have them, and anything Vroni should avoid changing. The more context you provide, the less guessing is needed.

Yes. Vroni can start from rough input. For very ambiguous product requests, Concierge is a better fit because a human operator can clarify the brief and turn it into a sequence of Vroni tasks.

The first release is centered on GitHub because it gives Vroni a clear way to receive issues and return pull requests. Vroni is not conceptually limited to GitHub, but GitHub is the initial workflow.

Vroni reads the task and repository, plans the task, edits the code, runs available checks, investigates failures, fixes what it can, and prepares the result with a clear summary.

Vroni returns a pull request with the implementation, a summary of what Vroni did, and the checks or verification steps it ran.

Yes, the first workflow returns pull requests in GitHub. That keeps the result visible in the workflow developers already know.

You can review the pull request like any other code update, but Vroni is built to return results that are ready to merge in normal cases. How much review you do is up to your team and risk level.

You or your team merge it. Vroni prepares the implementation and keeps the context visible; your normal repository permissions decide who can merge.

Yes. Leave feedback on the issue or pull request and Vroni can continue from there with a follow-up run.

Yes. Follow-up comments are a natural part of the workflow. Vroni can update the same pull request instead of making you start a new task from scratch.

Vroni reports the useful reason in plain language. If the task needs user action, you can add more context. If it is a product or platform issue, support has the diagnostic detail needed to investigate.

Yes. Vroni runs in the cloud. You can assign a task, move on, and come back later to the pull request and run history.

It depends on repository size, task complexity, available checks, and how many repair loops are needed. Vroni optimizes for quality over raw speed, so difficult tasks can take longer than a quick coding-agent pass.

Vroni is meant to replace real developer time, not only generate code quickly. Better planning, stronger models, multiple checks, and repair loops cost more time and compute, but they produce better software.

Vroni is fast compared with waiting for developer availability, but it is not optimized to be the cheapest instant code generator. It spends time understanding, implementing, checking, and fixing.

Vroni uses strong coding agents and models under the hood, but it does not simply pass your task to one tool once. It runs them through Vroni's own workflow for planning, implementation, review, and QA.

Vroni runs relevant checks when they are available and practical for the task. Good project test commands, build commands, and lint commands help Vroni verify the result.

Vroni can still run, but confidence is lower. It will rely more on code inspection and task-specific verification. Adding tests or clear check commands improves results.

Yes. Vroni can handle architecture updates when the goal and constraints are clear enough. Larger architecture updates may be better split into a sequence of runs or handled with Concierge.

Yes. Vroni can refactor code, clean up duplication, improve structure, add tests around risky edits, and keep behavior stable when the intent is clear.

Vroni reads the repository and tries to follow existing patterns, naming, architecture, and conventions. Clear project notes and consistent code make this easier.

Vroni needs access to the repositories where it should implement tasks and open pull requests. You control that access through the GitHub App installation.

Yes. Solo includes 1 repository. Team includes 3 repositories. Larger repository needs can be scoped separately.

Solo includes 1 repository. Team includes 3 repositories. Concierge includes Team as its base and can be scoped for managed delivery. Contact us for larger repository needs.

No special framework is required, but Vroni gets better results when your repository has clear install, build, test, and lint commands. Team includes tailored setup for the included repositories.

Tailored setup means configuring Vroni around your repository: commands, conventions, review expectations, project notes, and known workflow rules.

Vroni uses repository context, prior task history, project conventions, feedback, and configuration notes to produce better future runs for the same codebase.

Yes, if the relevant project boundaries and commands are clear. Monorepos often benefit from tailored setup because the right package, app, or test command may not be obvious.

Yes. Vroni is designed for real private repositories. Repository access is controlled through the connected GitHub App.

One credit equals one active Vroni minute. Plans include monthly Vroni time: Solo includes 2 hours and Team includes 10 hours. Credits are used only while Vroni is active on the task: reading context, planning, editing code, running checks, fixing failures, or improving the result. Queue time, idle time, and time waiting for your response do not use credits. Do not compare two Vroni hours to two hours of human typing. A Vroni run includes planning, implementation, QA, failure repair, and follow-up handling, so two active Vroni hours can cover work that would otherwise take a developer several days. If you need more time after signup, you can buy top-up packs in-app whenever you need more credits.

Because Vroni time includes more than typing code. It includes understanding the request, planning the implementation, using state-of-the-art AI coding agents, running checks, repairing failures, and returning software you can inspect or ship. A human developer also needs availability, meetings, handoff, context switching, and often a day-rate commitment. Vroni turns that into autonomous execution time. For many tasks, one Vroni hour can replace far more than one human hour; the exact saving depends on the task and repository.

No. Pull request size varies too much. Vroni is billed by active Vroni time, because that better matches the actual effort spent.

No. Queue time, idle time, and time waiting for your response do not use credits. Credits are consumed only while Vroni is active.

You can buy top-up hours. Tasks use included monthly Vroni time first, then top-ups.

Top-ups are available as 2 hour, 10 hour, and 30 hour packs. After signup, you can buy them inside the app whenever you need more credits. They are useful when a sprint or launch push needs more Vroni time than your monthly plan includes.

Monthly included hours are plan capacity for that billing period. Top-up handling can be shown separately in billing before launch.

No. Joining the waitlist is free because you are not buying access yet, but Vroni itself is a paid product.

Choose Solo for one repository and one user. Choose Team for shared access, priority queueing, 3 repositories, 5 seats, and tailored setup. Choose Concierge when you want a human operator to coordinate delivery.

Contact us. Larger teams, more repositories, security review, invoicing, and procurement requirements can be scoped separately.

Solo includes 1 seat, 1 repository, 2 hours of active Vroni time per month, run history, pull request summaries, and the ability to buy top-ups.

Team includes 5 seats, 3 repositories, 10 hours of active Vroni time per month, priority queueing, tailored setup for your included repositories, quarterly tuning updates, and top-ups.

Concierge is managed delivery on top of Vroni. We operate Vroni on your behalf, turn your requests into Vroni tasks, manage pull request follow-up, and keep delivery moving like an agency.

Choose Concierge when you want us to run the process for you: clarify requests, operate Vroni, manage pull requests, coordinate follow-ups, and drive delivery.

No. Concierge is managed delivery. Custom or enterprise needs such as more repositories, procurement, invoicing, security review, or larger rollout planning can be scoped separately.

Yes. Contact us if you need different repository limits, more seats, procurement support, security review, invoicing, or a larger rollout.

Yes. Team includes tailored setup for the included repositories. Concierge adds more hands-on coordination for ambiguous requests and managed delivery.

Vroni needs access to the repositories you connect so it can implement tasks and open pull requests. You decide which repositories are installed through the GitHub App.

Yes. Repository access is controlled through the GitHub App installation and your GitHub organization permissions.

Yes. Vroni keeps task, run, pull request, credit, and activity records so teams can inspect what happened.

Yes. Task and run history is part of the product because it helps you understand what Vroni did, what it checked, and how Vroni time was used.

Do not put secrets in issues, comments, screenshots, or documentation. Vroni should use normal repository and CI configuration instead of receiving credentials in task text.

Vroni should not need production access for normal code edits. Keep production credentials and deployment permissions separate unless you deliberately configure a controlled workflow.

Use the contact page or email [email protected]. For Concierge, include a short description of your product, repositories, and the tasks you want Vroni to handle.

Vroni can report what is missing or ask for follow-up context. You can answer in the issue or pull request and continue the same task.

Yes. Contact us with your repository count, team size, expected workload, and whether you want self-serve Vroni runs or Concierge-managed delivery.

Public docs are not part of the launch version yet. The FAQ and onboarding flow cover the basics for now, and docs can be added once the product content is locked.

Yes. The FAQ will grow as more users join the waitlist, ask real questions, and start using Vroni on real repositories.