Developer Kit

For developers

Vincia users spin up websites and portals by composing pieces from the Forge. Developers contribute the functional layer — connectors, workflow steps, widgets, app blueprints, and solution packs — that make a build actually do something. Solution packs earn on every install; the parts they’re built from (connectors, workflow steps, widgets, blueprints) aren’t paid standalone but make packs cheaper to ship.

What you can build

Two archetypes — website and portal. Every contribution you ship slots into one or more of these.

Website

A public-facing site. The site owner always has a sign-in to manage forms, data, and content. Customer accounts (sign-up + a customer dashboard) are optional.

Where developers plug in: Connectors (forms → email, payment for pricing pages, sign-in providers for customer accounts), workflow steps (lead routing, signup welcomes, purchase follow-ups), widgets (pricing tables, contact forms, embedded calendars, customer-dashboard tiles), blueprints (full marketing-site starters, SaaS site with customer portal).

Portal

A sign-in-gated app. Every page sits behind a login. Sidebar layout, data-heavy widgets, multi-step flows, and views that depend on the user’s role.

Where developers plug in: Data-heavy widgets (KPI tiles, tables, kanban, calendars), storage connectors, workflow steps for internal automation, blueprints for specific business apps (CRM, project tracker, member directory, ops dashboard).

Five contribution types, in three families

They live in the same marketplace and use the same CLI — but they’re not the same kind of thing. Only the first family is code that runs live; the other two are starter kits the user picks once.

Plugins3 types

Code that runs live. When a Vincia site needs the capability you ship, Vincia calls your code with the right inputs. You write against a small SDK and list what your code needs (URLs to call, secrets, storage).

Connector

Build one if: You want to add a single external capability that any Vincia site can use. The agent (or you) scaffolds with `vincia create connector --capability payment` (or storage, notification, sign-in, mailbox).

Examples: Payment (Stripe, PhonePe, Razorpay), storage (S3, R2, Cloudflare Images), notification (push, SMS, Slack), sign-in (Google, Microsoft, GitHub), mailbox (Mailgun, SES, Postmark).

Where it fits: Any kind of site. A website uses payment on pricing pages; a portal uses storage for file uploads; a customer-account site uses a sign-in provider for signup. You list what your code needs (URLs to call, secrets, storage namespaces) so Vincia grants only those.

Workflow node

Build one if: You want to add a single step that any workflow can drop in — typed inputs, typed outputs, no UI of its own.

Examples: Translate text, classify image, transform PDF, query an external API, run inference, send a conditional email, split a comma-separated string into a list.

Where it fits: Every kind of site. Form submissions, customer signups, scheduled internal jobs, and agent-driven automations all stitch together workflow steps.

Widget

Build one if: You want to add a new on-page component that any Vincia site can drop onto a page or dashboard. It picks up the site’s theme automatically — no brand details from you.

Examples: Live KPI tile, multi-step form, booking widget, data table, kanban board, file uploader, embedded map, chart, sparkline.

Where it fits: Public-page widgets show on websites; sign-in and dashboard widgets show on portals and customer-account areas; data widgets show wherever they have data to display. You ship four visual states — empty, loading, error, populated — so the widget looks right in every situation.

Blueprints1 type

Ready-made app starters. The user picks one from the marketplace and Vincia sets up the pages, data, and automations in a single click. After install, your blueprint isn’t running in the background — the user owns and edits the build.

Blueprint

Build one if: You want to ship a ready-made app — pages, data structure, and automations all set up together. Two sizes: a full app (standalone, with its own chrome and brand prompts), or a module that drops into an app the user already has.

Examples: Full apps: restaurant POS, agency CRM, course platform, member directory, dental-clinic intake. Modules: invoicing, support tickets, CRM-lite.

Where it fits: Pick whether your blueprint is a full app or a module, and (for apps) whether it’s a website or a portal. The end user picks it from the marketplace, names their brand, and Vincia sets up the pages, data, and automations from your template — ready to edit.

Solution packs1 type

A pre-packed kit for one use case (small clinic, boutique hotel, agency, …). Bundles together blueprints, connectors, workflow steps, and widgets that work well together. No code; just a recipe.

Solution pack

Build one if: You want to ship a turnkey kit for one use case — blueprints, connectors, workflow steps, and widgets pre-selected to work well together. No new code; just a recipe that points at the marketplace pieces and the wiring between them.

Examples: Small-clinic intake suite (bookings + patient records + reminders), boutique-hotel pack, agency-CRM pack.

Where it fits: How niche agencies ship turnkey. One install gives the customer a finished app plus everything it needs to run — connectors, automations, widgets — already set up.

How to start

The shortest path is a desktop AI agent. Open the Developer Kit folder in Claude Desktop (Settings → Projects → Add a project → pick the kit folder), Claude Code, Cursor, or Codex. The kit ships a CLAUDE.md at its root; the agent reads it on its own and learns everything it needs to do.

  1. Download the Developer Kit from Studio and unzip it.
  2. Open the folder in your AI agent. The agent reads the CLAUDE.md and the prompt files alongside it (including a 1-page summary of all five contribution types and three worked-example blueprints).
  3. Tell it what you want to ship — in plain English. For example: “A Stripe payment connector with refund + webhook support.” or “A small-clinic intake blueprint with bookings, patient records, reminders.”

From there the agent does the rest. On first use it installs the Vincia CLI and signs you in. Then it asks the right type-specific questions, scaffolds the contribution, fills in the manifest, writes the implementation against the SDK, scaffolds unit tests, runs them, previews against a disposable test build (for blueprints + widgets), and publishes when you’re ready. You stay in chat; the agent handles the terminal.

Want to run the CLI directly without an agent? See the CLI quickstart for the commands and the manual flow. Need to know what the SDK exposes? See capabilities for the connector interface contracts.

Three ways your work pays off

Same kit, same publish flow — three ways to deploy your code and earn from it. You can do all three over time, on different projects.

1. Open-source — reputationShip it open. Every install grows your reputation and shows on your contributor profile. Especially powerful for foundational pieces — connectors for common services, workflow steps that wrap a standard primitive — where ubiquity matters more than per-install revenue.
2. Monetize — recurringSolution packs earn recurring income on every install — set your own price, or take the $1 / recipient / month default. Connectors, workflow steps, widgets, and blueprints aren’t paid standalone (they’re parts, not a full end-to-end capability), but shipping them publicly makes solution packs cheaper for everyone to build. Not a one-time license — a pack that lands well keeps paying as long as people use it. Dashboard at /admin/contributor.
3. Freelance — client workBuild a plugin or blueprint for one specific client. Your contribution lives in your team’s private library — not the public catalog. Solution packs are a particularly good fit here for niche-agency work. Promote to public later if you want marketplace earnings on top.

Free + paid contributions go through the same LLM gate plus human review. Freelance / client work skips the public review (it’s yours and your client’s) but follows the same scaffolding flow.

What Vincia gives you to build against

Each capability (payment, storage, notification, sign-in, mailbox) has a small, stable interface in @vincia/sdk/connector. Implement it once and your connector slots into every Vincia site that needs the capability. See capabilities for the current list and how many providers exist for each.

Not sure where to start? A connector has the smallest surface and ships fastest; a widget gives you immediate visual feedback. Both scaffold in seconds.

See /needed for what’s missing right now — explicit asks from the platform and from teams shipping on Vincia.

Why your code compounds here

Vincia isn’t a Zapier alternative or a Retool alternative. It’s a base that lasts and absorbs new tools as they appear. Every external service that matters becomes a connector here. When a new payment processor lands (PhonePe, Razorpay, whatever’s next), the marketplace gets a Payment connector for it. When a new AI capability is worth wiring in, it becomes a workflow step. When a new on-page pattern catches on, somebody ships it as a widget. The base stays where it is — the catalog around it grows.

That’s the contributor pitch: people pick Vincia precisely so they can sit in one place and try many things from it. Their data stays portable, Vincia scales with them, and they don’t need to migrate to chase the next tool — the next tool shows up in the marketplace. Your connector or workflow step joins that durable surface. A capability you ship today is still earning a year later because Vincia builds tend to grow, not get replaced.

Designing the visual layer instead? See designer types →