English

APIs and Server-Side Logic

Describe how your product should behave and condoo.Vibe builds the APIs, permissions, validation, and business logic behind the interface.

Behind every useful application are rules that determine what happens when users take action.

When someone creates a booking, updates a customer, completes a payment, invites a team member, or changes a deal's status, your application needs logic to process that action.

condoo.Vibe can build the APIs and server-side functionality required to power these experiences.

You don't need to design every endpoint yourself.

Describe what your application should do, and condoo.Vibe can build the logic behind it.

You define the behavior. condoo.Vibe builds the logic that makes it happen.

What is server-side logic?

Your application has things users can see and things that happen behind the scenes.

The interface might display a button:

[Create Lead]

But clicking that button may need to:

The button is the visible part.

The rules and operations behind it are part of the application's logic.

Frontend vs backend

A simple way to think about an application is:

USER
 ↓
FRONTEND
What the user sees and interacts with
 ↓
BACKEND
Processes requests and applies rules
 ↓
DATABASE / SERVICES
Stores data or communicates with other systems

The frontend might contain:

The backend might handle:

condoo.Vibe can work across both.

What is an API?

An API provides a structured way for different parts of software to communicate.

For example, your Leads page needs to retrieve leads from your application's backend.

Conceptually:

Leads Page
    ↓
"Give me the leads"
    ↓
API
    ↓
Database
    ↓
API
    ↓
Leads Page

When someone creates a lead:

Create Lead Form
      ↓
API Request
      ↓
Validate Data
      ↓
Save to Database
      ↓
Return Lead
      ↓
Update Interface

The user doesn't need to see or understand these requests.

They simply experience an application that works.

condoo.Vibe can create APIs for your application

When the application you're describing needs APIs, condoo.Vibe can create them as part of the implementation.

Suppose you ask:

Build lead management. Users should be able to create, view, edit, search, filter, and delete leads.

Behind that experience, the application may require operations for:

A developer might think about these as API endpoints.

As an condoo.Vibe user, you can start with the desired product behavior.

You don't need to specify endpoint names

Technical users may choose to provide explicit API requirements.

For example:

GET /api/leads
POST /api/leads
GET /api/leads/:id
PATCH /api/leads/:id
DELETE /api/leads/:id

But that's optional.

You can simply say:

Users should be able to create, view, edit, and delete leads.

condoo.Vibe can determine what application infrastructure is required.

Business Logic

Server-side functionality becomes especially important when your application has rules.

For example:

When a deal moves to Closed Won, record the closing date and include the deal value in won revenue.

That's a business rule.

Or:

Only workspace Owners and Admins can invite team members.

Another business rule.

Or:

A booking cannot be created if another confirmed booking already occupies the selected time slot.

Another rule.

condoo.Vibe can build application behavior around these requirements.

Describe rules in normal language

You don't need to convert business rules into code before giving them to condoo.Vibe.

For example:

Users can cancel bookings until 24 hours before the appointment. After that, the Cancel button should no longer be available and the backend should reject cancellation attempts.

This tells condoo.Vibe:

That's enough to define meaningful product behavior.

Don't rely only on the interface

Suppose only administrators should be able to delete users.

It isn't enough to simply hide:

[Delete User]

from regular users.

A user shouldn't be able to bypass the interface and perform the restricted operation anyway.

The backend should also enforce the rule.

Conceptually:

Delete User Request
        ↓
Is requester authenticated?
        ↓
Is requester an Admin?
       ↙ ↘
     Yes   No
      ↓     ↓
   Delete  Reject

This is why server-side logic is important for permissions and sensitive operations.

Authentication and APIs

Many APIs should only work for authenticated users.

For example:

Only signed-in users should be able to create projects.

The application needs to determine who is making the request before allowing it.

Conceptually:

Create Project
      ↓
API Request
      ↓
Is user signed in?
   ↙         ↘
 Yes          No
  ↓            ↓
Continue      Reject

For team applications, there may be another check.

Create Project
      ↓
Signed in?
      ↓
Workspace member?
      ↓
Has permission?
      ↓
Create project

This combines authentication with authorization and application logic.

Workspace-scoped data

Multi-tenant SaaS applications require particularly careful server-side logic.

Imagine two companies use the same CRM:

Acme Realty
├── Leads
├── Deals
└── Properties

Northstar Realty
├── Leads
├── Deals
└── Properties

When someone from Acme Realty requests leads, the application should return Acme's leads, not every lead in the database.

Conceptually:

Authenticated User
       ↓
Determine Workspace
       ↓
Verify Membership
       ↓
Retrieve Records
WHERE workspace = user's workspace
       ↓
Return Results

This isolation should happen on the backend.

Server-side validation

Forms can validate information in the interface, but important validation should also happen server-side.

Suppose your application requires:

Every lead must have a name and either an email address or phone number.

The frontend can help the user by showing validation errors immediately.

But the server should also reject invalid requests.

Why?

Because the backend is ultimately responsible for protecting the integrity of your application's data.

Working with your database

APIs often sit between your application's interface and its Neon database.

For example:

Dashboard
    ↓
GET DATA
    ↓
Server
    ↓
Neon Postgres
    ↓
Server
    ↓
Dashboard

When information changes:

Edit Customer
      ↓
Save
      ↓
Server validates request
      ↓
Neon Postgres updated
      ↓
Updated customer returned
      ↓
Interface refreshes

This separation helps keep database operations in the appropriate part of the application.

Calculations and Aggregations

Server-side logic can also calculate information from your stored data.

Suppose your database contains hundreds of deals.

You ask condoo.Vibe:

Show total pipeline value, active deal count, deals won this month, and average deal size on the dashboard.

The application can calculate those metrics from the underlying records.

For example:

Deals
  ↓
Filter active deals
  ↓
Calculate total value
  ↓
Return metric
  ↓
Dashboard

$4.2M Pipeline Value

The displayed number can come from real application data rather than hard-coded content.

Date-based logic

Applications frequently need logic based on time.

For example:

These requirements can be implemented as application logic around your stored data.

Connecting External Services

Your backend can also communicate with external services.

Suppose a customer completes a booking.

Your workflow might be:

Customer submits booking
         ↓
Server validates request
         ↓
Save booking to Neon
         ↓
Send confirmation through Resend
         ↓
Return success
         ↓
Show confirmation screen

Or a payment:

Customer selects Pro
         ↓
Create Stripe checkout
         ↓
Customer pays
         ↓
Stripe confirms payment
         ↓
Server processes event
         ↓
Update subscription
         ↓
Unlock Pro features

condoo.Vibe can build the application logic that connects these systems.

Webhooks

Some external services need to tell your application when something happens.

This is commonly done using a webhook.

For example, after a Stripe payment:

Your Application
      ↓
Stripe Checkout
      ↓
Payment
      ↓
Stripe Webhook
      ↓
Your Application
      ↓
Update Subscription

The customer may have already left the checkout page when Stripe sends this information.

That's why reliable payment systems shouldn't depend only on what happens in the browser.

You don't need to understand webhooks to request them

You can describe the desired behavior.

For example:

When Stripe confirms that a subscription has been successfully activated, update the user's plan in our database and unlock the features included in that plan.

condoo.Vibe can determine the technical implementation required.

Technical users can, of course, provide more specific webhook requirements when needed.

Background Actions

Some workflows involve actions that don't need to block the user's immediate experience.

For example:

After a new customer registers, create their account and then send a welcome email.

The important customer-facing action is account creation.

The email is a follow-up action.

Similarly:

When a lead is assigned to an agent, update the lead immediately and notify the agent.

Your application can coordinate multiple actions around a single user event.

Error Handling

Server-side operations can fail.

A database may reject a request.

An external service may be unavailable.

A payment may fail.

A request may contain invalid information.

A good application should handle these situations gracefully.

For example:

Create Booking
      ↓
Something fails
      ↓
Do NOT pretend booking succeeded
      ↓
Return error
      ↓
Show useful message
      ↓
Allow user to retry

You can explicitly tell condoo.Vibe how important failures should behave.

For example:

If the booking cannot be saved, don't send the confirmation email. Show the customer an error and allow them to try again.

Think about what happens when something fails

Consider a workflow:

Payment
   ↓
Create Order
   ↓
Send Email

What happens if payment succeeds but order creation fails?

For critical workflows involving money, access, inventory, or important customer data, failure behavior deserves careful consideration.

For these systems, using Plan Mode before implementation is often a good idea.

Optimistic Updates

Some applications can feel faster by updating the interface immediately while the server processes the change.

For example, when moving a deal between pipeline stages:

Qualified → Negotiation

the card can visually move immediately.

The application then saves the change.

If saving fails, the interface can return the deal to its previous stage and tell the user something went wrong.

This pattern is known as an optimistic update.

You don't need to request it for every interaction, but it can improve the experience for highly interactive applications.

Example: CRM workflow

Suppose you tell condoo.Vibe:

When an agent moves a deal to Closed Won, save the new stage, record the closing date, add an activity entry, update dashboard revenue, and show a success notification.

That one action involves several pieces:

Agent moves deal
       ↓
Verify permission
       ↓
Update deal
       ↓
Record closing date
       ↓
Create activity
       ↓
Recalculate metrics
       ↓
Return success
       ↓
Update interface

You're describing product behavior.

condoo.Vibe handles the implementation behind it.

Example: Booking System

Consider:

Customers can book appointments with a specific staff member. A time slot cannot be booked twice. After a booking is created, save it and send the customer a confirmation email.

The server-side workflow might conceptually be:

Booking Request
      ↓
Validate customer information
      ↓
Check availability
      ↓
Slot available?
   ↙          ↘
 Yes           No
  ↓             ↓
Create         Reject
Booking        Request
  ↓
Send Confirmation
  ↓
Return Success

The customer simply experiences a booking system that works correctly.

Example: SaaS Permissions

Suppose your SaaS has:

You define:

Owners can manage billing and delete the workspace. Owners and Admins can invite users. Members can create and edit projects but cannot manage the team.

condoo.Vibe can build those rules into the application's server-side behavior.

The UI can also reflect the permissions, but the backend remains responsible for enforcing important restrictions.

Use Plan Mode for complex logic

Straightforward logic can often be built directly.

For example:

When a task is marked complete, save the completion date.

Build Mode may be sufficient.

But consider:

Add usage-based billing where each workspace receives monthly credits, actions consume different numbers of credits, unused subscription credits expire at the end of the billing cycle, purchased top-up credits don't expire, and the system must consume monthly credits before top-up credits.

That involves:

That's a strong candidate for:

Plan + Max → Review → Build

Describe behavior precisely

A good server-side prompt answers questions such as:

For example:

Workspace Owners and Admins can invite team members. The email must not already belong to a workspace member. Create a pending invitation and send the invitation email. If sending the email fails, keep the invitation pending and allow the administrator to resend it.

That's much stronger than:

Add invitations.

You can still specify technical requirements

Developers aren't restricted to product-level prompting.

You can tell condoo.Vibe:

Add a cursor-paginated API for activity records ordered newest first, with a maximum limit of 100 records per request.

Or:

Validate the webhook signature server-side before processing Stripe events.

Or:

Make this operation transactional so partial updates aren't committed if one step fails.

condoo.Vibe allows you to work at the level of abstraction appropriate for your experience and requirements.

The principle

The frontend determines what users interact with.

The database determines what information exists.

Authentication determines who the user is.

Server-side logic determines:

What is allowed to happen?

And APIs provide the communication paths that make those interactions possible.

Together:

USER
 ↓
INTERFACE
 ↓
API
 ↓
SERVER-SIDE LOGIC
 ↓
DATABASE + EXTERNAL SERVICES

condoo.Vibe can work across this entire flow.

You focus on defining the product behavior.

Next: Managing Your Project Data

Your application now has a database, authenticated users, forms, integrations, APIs, and server-side logic.

But once real users begin creating information, another question becomes important:

How do I work with the data my application creates?

Next, we'll cover Managing Your Project Data: understanding, viewing, changing, and safely working with the information stored by your application.

Managing your project data

Understand, view, and safely change the information stored by your app.