Virex Docs

Guides, setup, comparison, and practical continuation for owned repos.

Documentation

Understand the repo, the tool order, and the continuation path before you go deeper

Virex is meant to produce a real project baseline you can keep moving forward. Start here if you want to understand what the repo is, how the first setup steps fit together, when mobile works differently from web, and which docs page to read next.

Overview

Start by understanding what Virex is actually giving you

The main job of the overview page is orientation. It should help you understand what the asset is, what the first steps are, and which deeper page to open next without dumping the whole docs system on you at once.

Keep this mental model in mind

  • Virex gives you a real repo you can open, run, keep, and continue instead of a disposable concept screen.
  • You do not need every tool on day one. Start with the repo, local run, and README before adding deployment or backend layers.
  • The docs are split so overview introduces the system, build explains the generation and continuation path, and tool pages explain the supporting stack in plain language.

Who Virex is built for

  • Beginners can use Virex as a practical learning path because the output is a real project they can inspect and run locally.
  • Regular builders get a stronger baseline and clearer continuation path than a pure one-shot generator.
  • Advanced users get speed, leverage, repo ownership, and controlled generation that still fits inside their own workflow.

The simplest way to read the product

Virex is meant to give you an MVP-ready or real build-ready repo baseline that you can continue. It should feel more serious than throwaway code, but it should also stay honest about project-specific setup that still needs your decisions.

Choose your path

Open the docs path that matches how you build

These pages explain the same product from different starting points so a complete beginner is not overloaded and a more technical builder is not forced to read only beginner-level material.

First local run

The core setup order for most web-oriented repos

This is the short practical order most users should follow first. The dedicated beginner page explains the same flow in more detail.

  1. 1
    Install Node.js first

    Node.js needs to be installed before npm commands will work. npm comes with Node, so this is the first practical setup step for many web-based Virex repos.

  2. 2
    Open the repo in VS Code or another editor

    Download the generated repo, unzip it, then open the project folder in VS Code. VS Code is the recommended default because it keeps the editor and terminal in one place, but the repo is not locked to it.

  3. 3
    Open the terminal inside the editor

    Use the built-in terminal so you are running commands inside the actual repo folder. On Mac the shortcut is Command + backtick. On Windows it is Control + backtick.

  4. 4
    Run the install step

    Use npm install to bring in the packages the project expects. This only works after Node.js is installed.

  5. 5
    Run the local dev server

    Use npm run dev and then open the localhost URL shown in the terminal, such as localhost:3000. That URL means the app is running on your own machine so you can inspect the baseline locally.

Typical first commands
npm install
npm run dev

Then read the README

Many generated repos include a README with project-specific setup notes. Read it after the first local run so you know which keys, URLs, or services the repo still expects.

Tools

Use tools because the repo needs them, not because the docs throw logos at you

The tools section exists to explain when a tool enters the workflow, what it changes, and what to do first. It should help you sequence the work instead of turning the docs into a logo wall.

Recommended default starting point

VS Code is the easiest default editor for most users because it combines file browsing and terminal access in one place. That recommendation does not lock the repo to VS Code or one hosting path.

Web and mobile

Mobile is a real supported path, but it starts differently from web

Web projects are often run through localhost in a browser. Mobile projects usually continue through Expo and app-oriented testing, so the steps and expectations are slightly different.

Starting with a mobile app?

  • Open the generated mobile repo and follow the project README before changing anything else.
  • Use Expo when the project is a mobile app and you want the practical testing and continuation layer.
  • Expect mobile testing to differ from a web repo: you are not always only opening localhost:3000 in a browser.
  • Keep Apple and Google developer accounts as later release steps, not first-day requirements.

Find the mobile guide fast

If your generated project is a mobile app, jump to the dedicated mobile docs page before assuming it runs exactly like a web repo. The mobile page explains Expo, local testing, README expectations, and later release needs in simpler terms.

Expo continuationOpen the repo locallyKeep repo ownership

Where next

Use deeper pages when you are ready to move from orientation into action

The overview page should point you onward, not try to become every docs page at the same time.

Connected workflow

GitHub, Vercel, Supabase, and Expo make more sense as a flow

Most users understand these tools faster once they are placed in a normal continuation sequence instead of explained as isolated brand names.

  • Generate and download the repo from Virex.
  • Run it locally first so you understand what the baseline already includes.
  • Push it to GitHub when you want remote backup, version history, or collaboration.
  • Connect the GitHub repo to Vercel when you want a web project live quickly.
  • Add environment variables in Vercel when the project needs real keys or service URLs.
  • Use Supabase when the app needs auth, database, storage, or saved user state.
  • Use Expo when the project is mobile and you need the native continuation path.