Skip to main content
Every Vybe app is built on the same production-grade technology stack. This page documents every technology, its version, and its role in your app.

Core technologies

TechnologyVersionPurposeDocumentation
Next.js15React framework with App Routernextjs.org/docs
React19UI library for component-based interfacesreact.dev
TypeScript5.5Type-safe JavaScripttypescriptlang.org
Tailwind CSS4Utility-first CSS frameworktailwindcss.com
Shadcn UILatestComponent library (50+ components)ui.shadcn.com
RechartsLatestCharting libraryrecharts.org
LucideLatestIcon librarylucide.dev
SonnerLatestToast notificationssonner.emilkowal.ski
PostgreSQLLatest (Neon)Built-in databaseneon.tech/docs
PrismaLatestDatabase ORMprisma.io/docs
InngestLatestBackground workflows and scheduled jobsinngest.com/docs

Architectural decisions

These are the key architectural patterns used in every Vybe app. Understanding them helps you write better prompts and understand the AI’s output.

App Router (not Pages Router)

Vybe uses the Next.js 15 App Router exclusively. All pages use the app/ directory structure with file-based routing.
src/app/
  page.tsx              → /
  customers/
    page.tsx            → /customers
    [id]/
      page.tsx          → /customers/:id
  api/
    customers/
      route.ts          → /api/customers
If you are familiar with Next.js Pages Router (pages/ directory), note that Vybe does not use it. All routing, layouts, and data fetching follow App Router conventions.

Server Components by default

Components are server-rendered unless explicitly marked with "use client" at the top of the file. Server Components can fetch data directly, access the database, and read environment variables.
// This is a Server Component (default)
export default async function CustomersPage() {
  const customers = await prisma.customer.findMany()
  return <CustomerTable data={customers} />
}
"use client"

// This is a Client Component (explicitly opted in)
export default function SearchBar() {
  const [query, setQuery] = useState('')
  // Client-side interactivity...
}
Use Client Components only when you need browser APIs, event handlers, or React state.

API routes instead of Server Actions

Vybe apps use API routes for all server-side mutations. Server Actions are not used.
// src/app/api/customers/route.ts
import { NextResponse } from 'next/server'

export async function GET(request: Request) {
  const customers = await prisma.customer.findMany()
  return NextResponse.json(customers)
}

export async function POST(request: Request) {
  const data = await request.json()
  const customer = await prisma.customer.create({ data })
  return NextResponse.json(customer, { status: 201 })
}

Dynamic route params in Next.js 15

Next.js 15 changed how dynamic route parameters work. The params object is now a Promise:
// src/app/customers/[id]/page.tsx
export default async function CustomerPage({
  params,
}: {
  params: Promise<{ id: string }>
}) {
  const { id } = await params
  const customer = await prisma.customer.findUnique({ where: { id } })
  // ...
}
This Promise<{ id: string }> pattern is specific to Next.js 15 and the App Router. The AI handles this automatically, but it is useful to understand if you are reading the generated code.

Database

Every Vybe app includes a built-in PostgreSQL database hosted on Neon. The database is managed through Prisma ORM. Key details:
  • Schema is defined in prisma/schema.prisma
  • Migrations are managed by the AI when you request schema changes
  • The database is available in both development (sandbox) and production (deployed app)
  • You can also connect external databases (PostgreSQL, MySQL, Amazon Redshift) through Integrations
For more on databases, see App Data and External Data.

Background workflows

Inngest powers background processing in Vybe apps. Use workflows for:
  • Scheduled tasks — sync data every 15 minutes, send daily reports
  • Event-driven processing — trigger actions when database records change
  • Long-running operations — batch data processing, multi-step pipelines
Workflows run outside of the request/response cycle, so they are not subject to API route timeouts. For more on workflows, see Workflows Overview.

What this means for your prompts

You do not need to specify technology choices in your prompts. The AI knows the full stack and uses the right tools automatically. However, understanding the stack helps you:
  • Read the generated code more easily
  • Ask targeted questions about how things work
  • Debug issues by understanding the architecture
  • Write better prompts by referencing the right concepts (e.g., “add an API route” instead of “add a server action”)

What’s next