The problem with frontend-only AI builders

Most AI code generators give you a React app with hardcoded data. The login form looks nice but does not authenticate anyone. The dashboard shows charts with static JSON that never changes. The "Save" button triggers a toast notification but saves nothing.

I built VULK's backend generation because I was tired of seeing this pattern. A frontend without a backend is a prototype, not an application. And if you are paying for an AI code builder, you should get something that actually works.

When your prompt describes functionality that requires a backend -- user accounts, saved data, API endpoints, admin panels -- VULK generates the backend automatically. Not a mock. A real backend with PostgreSQL, Express.js API routes, authentication, and schema migrations. The login form actually logs you in. The data actually persists. The API endpoints actually respond.

How detection works

You do not need to say "generate a backend." You describe what you want, and VULK determines whether a backend is needed based on signals in your prompt.

Authentication signals -- "login," "signup," "user accounts," "admin panel," "roles and permissions." Any mention of users with accounts triggers the auth system.

Data persistence signals -- "save," "store," "database," "CRUD," "records," "history." These trigger database schema and API generation.

API signals -- "API," "endpoint," "webhook," "REST," "fetch from server." These trigger route generation even without explicit database mentions.

The detection is intentionally conservative. VULK does not add a backend to a simple landing page or a static portfolio. It only activates when your prompt genuinely requires server-side functionality.

Why PostgreSQL (and not Supabase, Firebase, or MongoDB)

I get asked about this decision a lot, and I want to be transparent about the reasoning.

Why not Supabase or Firebase? Because they are third-party services that create external dependencies. If I generated code that requires a Supabase project, you would need to create a Supabase account, set up a project, configure environment variables, and manage another service. That breaks the "one prompt, working app" experience. VULK's backend runs on our infrastructure with zero external setup.

Why not MongoDB? Because most applications that VULK users build are relational. Tasks belong to projects. Projects belong to users. Orders contain order items. Products have categories. These are naturally expressed as tables with foreign keys, not as document collections. MongoDB is great for specific use cases, but for the breadth of applications VULK generates, relational databases produce cleaner, more maintainable code.

Why PostgreSQL specifically? It is the most capable open-source relational database. Full ACID compliance, excellent JSON support for when you need flexibility, robust indexing, and a massive ecosystem. It is what I would choose for a production application, so it is what VULK generates.

What gets generated

When backend generation triggers, VULK produces a complete server-side application alongside your frontend. Here is what each layer includes.

Database schema. Complete PostgreSQL tables with columns, types, constraints, indexes, and relationships. A users table gets id, email, password_hash, name, created_at, and updated_at. Posts get a foreign key to users. Every table gets a primary key, timestamps, and indexes on columns used in queries.

The column is called password_hash -- never password. This is a deliberate security decision that I enforce in the prompt engineering. Passwords are hashed with bcrypt on registration and compared on login. The column name itself makes the intent unambiguous.

API endpoints. RESTful routes for every entity in your schema. A posts table generates GET /api/posts (list with pagination), GET /api/posts/:id (single record), POST /api/posts (create), PUT /api/posts/:id (update), and DELETE /api/posts/:id (delete). Each endpoint includes input validation, error handling, and appropriate HTTP status codes.

Authentication system. Registration (POST /api/auth/register) and login (POST /api/auth/login). Registration hashes the password with bcrypt and stores it. Login compares against the hash and returns a JWT. Protected routes verify the JWT via middleware.

Frontend integration. This is the part that makes it feel complete. The React frontend is generated with API calls already wired up. Fetch calls point to the correct endpoints. Auth tokens are stored and attached to requests. Loading states and error handling are included. The login form actually authenticates. The registration form actually creates an account. Saved data actually persists across sessions.

Real examples

Task management app: "Build a task management app where users can create an account, log in, create projects, and add tasks to projects. Tasks have title, description, priority, due date, and status. Users can only see their own projects."

This generates: users table, projects table with user_id foreign key, tasks table with project_id foreign key, auth endpoints, CRUD for projects and tasks, authorization middleware that filters by user_id.

E-commerce store: "Create an online store for selling handmade ceramics. Admin can add products. Customers can browse, add to cart, and place orders. Order history is saved to the user account."

This generates: users table with a role column, products table, orders table, order_items junction table, role-based access control, admin-only endpoints for product management, customer endpoints for browsing and ordering.

The database layer in detail

I care about schema quality because bad schemas create bad applications. Here is what VULK enforces:

Primary keys use auto-incrementing integers for simplicity. UUID is available for specific use cases.

Foreign keys include ON DELETE CASCADE where appropriate (deleting a user deletes their posts) and ON DELETE SET NULL where orphaned records should survive (deleting a category does not delete products).

Indexes are created on foreign key columns, email columns (for login lookups), and any column used in WHERE or ORDER BY clauses. This is not an afterthought -- the generated indexes match the generated queries.

Timestamps (created_at, updated_at) are on every table.

Enums and constraints are used for bounded values. A task status is constrained to specific values, not arbitrary strings.

Security patterns that are not optional

Here is what most people get wrong about generated code: they ship it without thinking about security. VULK's backend generation includes security patterns by default because shipping without them creates real vulnerabilities:

• Password hashing with bcrypt (never plaintext)
• Parameterized queries (never string concatenation in SQL)
• JWT verification middleware on protected routes
• Input validation on all endpoints (type checking, required fields, length limits)
• CORS configuration limiting origins to the frontend domain
• Rate limiting on auth endpoints to prevent brute force
• User-scoped queries ensuring users only access their own data

These are not optional add-ons you enable. They are part of the default output because I believe generated code should be secure by default.

When backend generation is the right choice

It works best for standard data-driven applications: task managers, CRM tools, inventory systems, blogs, e-commerce stores, booking platforms, dashboards. These follow patterns that the AI models handle well, and the generated code is clean, readable, and maintainable.

It is less suited for applications with exotic requirements: real-time collaboration with operational transforms, complex financial calculations, or integration with obscure third-party APIs. For those, generate the standard parts with VULK and implement the specialized parts manually.

The generated code is standard Express.js and PostgreSQL. Every file is readable, modifiable, and deployable. No proprietary runtime, no framework lock-in. If you outgrow the generated backend, you refactor it like any other Node.js application.

That is the principle I build around: VULK should accelerate your development, not trap you in a walled garden. Start building at vulk.dev.