APIs and Server-Side Logic

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. AIWA 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 AIWA can build the logic behind it. You define the behavior. AIWA 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:

Check that the user is signed in
Validate the information entered
Check the user’s permissions
Save the lead to the database
Associate it with the correct workspace
Record the activity
Return the newly created lead
Update the interface

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:

Buttons
Forms
Dashboards
Tables
Navigation
Modals
Charts

The backend might handle:

Saving information
Retrieving information
Permissions
Calculations
Business rules
External integrations
Payment verification
Data validation

AIWA 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.

AIWA can create APIs for your application

When the application you’re describing needs APIs, AIWA 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:

Get leads
Get a lead
Create a lead
Update a lead
Delete a lead

A developer might think about these as API endpoints. As an AIWA 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.

AIWA can determine what application infrastructure is required.

If you’re a developer and need a specific API structure, naming convention, response format, or validation behavior, you can include those requirements directly in your prompt.

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. AIWA 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 AIWA. 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 AIWA:

Who can perform the action
What action is allowed
Under what condition
What should happen when the condition isn’t met

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.

Critical permissions and data-access rules should be enforced server-side, not only by hiding buttons or pages in the user interface.

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 AIWA:

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:

Show all follow-ups due today.
Mark invoices as overdue after their due date.
Prevent users from booking dates in the past.
Show deals expected to close within the next seven days.
Allow cancellation until 24 hours before an appointment.

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

AIWA 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.

AIWA 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 AIWA 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 AIWA:

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. AIWA 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:

Owner
Admin
Member

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.

AIWA 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:

Billing
Credit balances
Consumption rules
Renewal behavior
Payment events
Database structure
Concurrency
Permissions
Failure cases

That’s a strong candidate for: Plan + Max → Review → Build

Describe behavior precisely

A good server-side prompt answers questions such as:

Who can perform the action?
What should happen?
Under what conditions?
What data should change?
What should happen afterward?
What happens if it fails?

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 AIWA:

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.

AIWA 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

AIWA 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.

​What is server-side logic?

​Frontend vs backend

​What is an API?

​AIWA can create APIs for your application

​You don’t need to specify endpoint names

​Business Logic

​Describe rules in normal language

​Don’t rely only on the interface

​Authentication and APIs

​Workspace-scoped data

​Server-side validation

​Working with your database

​Calculations and Aggregations

​Date-based logic

​Connecting External Services

​Webhooks

​You don’t need to understand webhooks to request them

​Background Actions

​Error Handling

​Think about what happens when something fails

​Optimistic Updates

​Example: CRM workflow

​Example: Booking System

​Example: SaaS Permissions

​Use Plan Mode for complex logic

​Describe behavior precisely

​You can still specify technical requirements

​The principle

​Next: Managing Your Project Data

Managing your project data

What is server-side logic?

Frontend vs backend

What is an API?

AIWA can create APIs for your application

You don’t need to specify endpoint names

Business Logic

Describe rules in normal language

Don’t rely only on the interface

Authentication and APIs

Workspace-scoped data

Server-side validation

Working with your database

Calculations and Aggregations

Date-based logic

Connecting External Services

Webhooks

You don’t need to understand webhooks to request them

Background Actions

Error Handling

Think about what happens when something fails

Optimistic Updates

Example: CRM workflow

Example: Booking System

Example: SaaS Permissions

Use Plan Mode for complex logic

Describe behavior precisely

You can still specify technical requirements

The principle

Next: Managing Your Project Data