Your first hour with GoVueKit: clone, configure, ship

June 24, 2026

This is what the first hour looks like: what you run, what it does, and what you should have on screen at the end. No screenshots — commands you can check against the repository you receive.

Minute 0: what you need

Go 1.26 and Node 22 for development. Docker is optional. No database server: SQLite is the development default and the file is created for you.

git clone <your-copy-of-the-repo> myapp && cd myapp

The first thing to do is make the module yours, because every import path in the repository refers to it:

go mod edit -module github.com/you/myapp
find . -name '*.go' -exec sed -i 's|github.com/kolapsis/govuekit|github.com/you/myapp|g' {} +

Two commands, and the codebase is no longer named after somebody else.

Minute 5: configuration without reading 51 variables

make setup

An interactive assistant asks the questions that actually change behaviour — product name, public URL, tenancy mode, database, sign-in providers, email backend, storage, what this deployment sells, error reporting — and writes .env, generating a fresh CSRF_KEY for you. Everything it does not ask about has a working default.

If you prefer to read rather than answer, cp .env.example .env works too: every variable is documented in that file. The ones that decide the shape of your product:

Variable	Choice it makes
`ORG_MODE`	`multi` for B2B teams, `solo` for a personal organization per user (B2C)
`DB_DRIVER`	`sqlite` (a file, zero setup) or `postgres`
`MAILER`	`log` in development, `smtp` or `resend` in production
`BILLING_PLANS`	the JSON array of plans you sell — empty means the deployment sells nothing
`SUPER_ADMIN_EMAIL`	the account that may open `/admin`

Pick ORG_MODE deliberately: switching an existing deployment is not retroactive.

Minute 10: the application runs

make front   # npm ci + vite build → web/dist, embedded by the Go binary
make dev     # http://localhost:8080

The database file is created and migrated at startup. Nothing else to start: sessions, the job queue and uploads all live inside that one process and its database.

Sign up at http://localhost:8080/signup. With MAILER=log, the verification email is printed to the server log with a clickable link — no mail server needed to test the flow.

Working on the frontend? Run the two together:

make dev                 # API on :8080
cd web && npm run dev    # Vite on :5173, proxies /api to :8080

If you would rather see the whole thing wired up before configuring anything, there is a second door:

docker compose -f deploy/labs/docker-compose.yml up -d --build

That starts the app on http://labs.localhost and everything it talks to: single sign-on through Dex, S3 uploads into MinIO, a Stripe API double, a Mailpit inbox catching every email, PostgreSQL. No account anywhere, no domain, no certificate, nothing to fill in. down -v wipes it.

Minute 20: data to look at

make seed

This fills the development database with demo users (credentials are printed) and an organization — idempotent, so run it as often as you like. You now have something to click through: the dashboard with its onboarding checklist, organization settings with members and invitations, the billing page, account settings with active sessions and 2FA.

Set SUPER_ADMIN_EMAIL to your seeded address and /admin opens: MRR, ARPU, 30-day churn, signups, plan mix, user moderation and the audit log.

Minute 30: make it your product

Two questions decide what you touch first.

Is it B2B or B2C? ORG_MODE=solo hides the whole team surface — creation, invitations, the switcher — and gives each account a personal organization. Billing keeps working unchanged, which makes it per-user in practice.

What is your core object? The kit ships no example business module on purpose: it is a core, and the invoices or campaigns or shipments you are about to add are the part nobody can write for you. What it does ship is the chain those objects hang from, used by its own tables and documented in build order — a goose migration, org-scoped queries for sqlc, a handler, routes under the org router, a Pinia store, a view, and the tests that hold tenancy in place.

It is seven steps and every one of them is one obvious file. The full walkthrough is here, and docs/CUSTOMIZING.md §8 is the same list next to the code.

Minute 45: change the marketing side

The public landing in web/src/views/HomeView.vue is deliberately plain — a heading, a way in and the legal links — because a marketing page is the one thing you were always going to write yourself. Its copy lives in the landing.* keys of web/src/i18n/{en,fr}.json; the legal pages are structured placeholders waiting for your company details.

Prices are configuration, not UI: BILLING_PLANS feeds GET /api/plans, which feeds every pricing surface, so nothing you display can disagree with what the server actually sells.

One build flag decides whether search engines and AI assistants see that page:

make prerender build

The build captures every public page as static HTML in both languages and embeds it in the binary, so a crawler reads a full page before a line of JavaScript runs — and the binary is still one binary. docs/SEO.md covers turning it on, what it changes, and removing it.

Minute 55: prove it still works

make test        # Go tests, race detector on
make test-front  # vitest
make lint        # golangci-lint + eslint
make e2e         # Playwright against the real production binary

Run these before your first commit, not after your tenth. They are how you find out whether your change to the org middleware broke tenant isolation — the suite includes a journey whose only job is to try to read another organization's data and expect a 404.

Minute 60: production, when you want it

make build   # one binary, frontend embedded, version stamped

Copy it to a server, or use the provided compose file with Traefik and Let's Encrypt. The deployment guide is three commands and covers backups and updates.