English

Managing Your Project Data

Organize, search, filter, and safely change the data your users create with the interfaces and rules condoo.Vibe builds around your database.

Once people begin using your application, they create data.

Customers sign up. Leads are added. Orders are placed. Appointments are booked. Projects are created. Deals move through pipelines.

condoo.Vibe helps you build applications that don't just collect this information. They can organize, retrieve, update, filter, analyze, and protect it.

Your application's data is part of your product. condoo.Vibe helps you build the experiences that make that data useful.

What is project data?

Project data is the information created and used by your application.

For a CRM, this might include:

For a booking application:

For an e-commerce application:

This information is stored in your project's database and used throughout the application.

Data vs content

It's useful to distinguish between application data and normal website content.

A homepage headline such as:

Build your dream home with confidence.

is primarily website content.

A customer record such as:

Name: Sarah Chen
Email: sarah@example.com
Plan: Pro
Status: Active

is application data.

Application data is usually dynamic.

It changes as people use your product.

condoo.Vibe can build interfaces for your data

Your users shouldn't need to interact directly with a database.

Instead, condoo.Vibe can create interfaces that allow them to work with the information stored by your application.

For example, a Leads page might provide:

The interface becomes the user's way of working with the underlying data.

Conceptually:

USER
 ↓
APPLICATION INTERFACE
 ↓
SERVER-SIDE LOGIC
 ↓
NEON POSTGRES

Creating data

You can tell condoo.Vibe how users should create records.

For example:

Add a Create Lead button. The form should collect name, email, phone, source, status, assigned agent, budget, and notes.

When the user submits the form, the application can validate the information and save the new lead.

The user doesn't need to know anything about the underlying database operation.

Viewing data

Once information exists, users need useful ways to view it.

For example:

Create a Customers page showing name, company, email, plan, account status, and signup date.

Or:

Show all properties in a card grid with image, property name, location, price, type, and listing status.

Different data may need different presentations.

condoo.Vibe can build:

based on how users need to interact with the information.

Searching and filtering

Applications become harder to use as the amount of data grows.

Imagine a CRM with 10 leads.

A simple list may be enough.

Now imagine it has 10,000.

Users need ways to find what matters.

You could ask:

Add search to the Leads page. Users should be able to search by name, email, phone number, or company.

Then:

Add filters for lead status, source, assigned agent, and date created.

Or:

Allow users to show only deals expected to close this month.

condoo.Vibe can build these data-management experiences into your application.

Sorting

Users may also need to control how records are ordered.

For example:

Allow the customer table to be sorted by name, signup date, and total revenue.

Or:

Sort upcoming appointments by date and time, with the earliest appointment first.

Or:

Show the highest-value deals first.

Describe the experience you want rather than worrying about how the database query should be written.

Pagination

Loading thousands of records at once can create unnecessary performance problems.

Applications commonly divide large collections into smaller sets of results.

For example:

Showing 1-25 of 2,418 leads

← Previous     1  2  3  4  5     Next →

This is called pagination.

For larger datasets, condoo.Vibe can build appropriate pagination or incremental-loading behavior.

Technical users can also specify exactly how they want pagination implemented.

Detail Pages

Lists help users find records.

Detail pages help them understand individual records.

For example, selecting a lead might open:

Sarah Chen

Status
Qualified

Budget
$850,000

Assigned Agent
Marcus

Property Interest
3-bedroom home

Follow-ups
3

Recent Activity
...

You can ask condoo.Vibe:

Create a lead detail page showing contact information, status, assigned agent, budget, notes, follow-ups, associated deals, and recent activity.

condoo.Vibe can retrieve and combine the appropriate project data for that experience.

Editing data

Most applications need users to update existing records.

For example:

Allow agents to edit a lead's contact information, status, budget, assigned agent, and notes.

Or:

Customers should be able to update their billing address from Account Settings.

When the user saves the changes, the application can update the corresponding data in Neon.

Think about who can edit what

Not every authenticated user should necessarily be allowed to change every record.

For example:

Agents can update leads assigned to them. Admins can update any lead in the workspace.

Or:

Customers can update their own profile but cannot edit another customer's information.

This is where project data, authentication, and authorization work together.

Deleting Data

Deletion deserves special consideration because it can be destructive.

A simple application might allow:

Delete this note.

But deleting a customer could affect:

Customer
   ↓
Projects
   ↓
Tasks
   ↓
Comments

What should happen to all the related information?

That decision should be intentional.

Define deletion behavior

For important records, tell condoo.Vibe what should happen.

For example:

Users can delete draft invoices, but paid invoices should never be permanently deleted.

Or:

When an administrator deletes a project, delete its tasks and comments as well, but don't delete the customer.

Or:

Don't permanently delete customers. Archive them instead.

These are product decisions, not merely database decisions.

Consider archiving instead

Sometimes information shouldn't be permanently deleted.

You may prefer:

Active → Archived

rather than:

Record → Permanently Deleted

For example:

Allow users to archive completed projects. Archived projects should disappear from the default Projects view but remain accessible through an Archived filter.

This preserves historical information while keeping the main interface clean.

Data Relationships

Your application's data often becomes more useful when different records are connected.

For example:

CUSTOMER
   ↓
PROJECT
   ↓
TASK
   ↓
COMMENT

Or:

LEAD
  ↓
DEAL
 ↙  ↘
AGENT PROPERTY

These relationships allow condoo.Vibe to create richer experiences.

For example:

On the customer detail page, show all projects belonging to that customer.

Or:

On the property detail page, show all deals associated with the property.

Or:

Show every task assigned to the currently signed-in user.

Don't duplicate information unnecessarily

Suppose a project belongs to a customer.

Instead of storing the customer's full details separately inside every project, the application can connect the project to the existing customer record.

Conceptually:

Customer
ID: 124

      ↓

Project
Customer: 124

This makes it easier to maintain consistent information as your application grows.

condoo.Vibe can design these relationships based on your product requirements.

Dashboard Data

Project data can also power dashboards and reports.

For example:

Show total customers, active subscriptions, MRR, new customers this month, and churned customers.

Or:

Show total pipeline value grouped by deal stage.

Or:

Show appointments today and compare this week's bookings with last week.

Conceptually:

APPLICATION DATA
       ↓
Filter + Calculate
       ↓
METRICS
       ↓
DASHBOARD

Your dashboard becomes a representation of real application activity.

Keep metrics dynamic

When building a real application, make it clear when dashboard numbers should come from the database.

For example:

Replace the placeholder dashboard metrics with live values calculated from the current workspace's data.

This prevents a production dashboard from continuing to display decorative sample numbers.

Empty States

Your application also needs to work when there is no data yet.

Imagine a new customer creates an account and reaches:

Total Leads: 0
Deals: 0
Pipeline: $0

Simply displaying an empty table isn't always the best experience.

Instead:

You don't have any leads yet.

Add your first lead to start building your pipeline.

[Add your first lead]

This is called an empty state.

You can ask condoo.Vibe to create useful empty states throughout the application.

Design for the first user

When building data-heavy applications, test what happens before any records exist.

Ask:

For example:

Add designed empty states to Leads, Properties, Deals, and Follow-ups. Each empty state should explain the feature and provide a clear CTA for creating the first record.

This improves the experience for new users.

Loading States

Data isn't always available instantly.

While your application retrieves information, users should understand that something is happening.

Instead of briefly showing:

0 Leads

before the actual data appears, the application might show a loading state.

For example:

████████████
████████
██████████████

Skeletons, progress indicators, or other loading patterns can help make data-driven interfaces feel more polished.

Error States

Sometimes data can't be loaded.

A useful application should communicate this clearly.

For example:

We couldn't load your leads.

[Try again]

Rather than showing a broken page.

You can ask condoo.Vibe:

Add loading, empty, and error states to the customer table. If loading fails, show an inline error with a Retry button.

Working with production data

Once real users are using your application, database changes deserve more care.

Adding a new field is very different from deleting a table containing customer information.

Before significant structural changes, tell condoo.Vibe that the application contains real data.

For example:

This application is now in production and contains customer data. We need to change the relationship between customers and organizations. Analyze the existing database and create a safe migration plan before making any changes.

This is a good use case for Plan + Max.

Test with realistic data

Sample data can help you understand how an application behaves before real customers arrive.

For example, a CRM might include realistic examples across:

This allows you to test filters, dashboards, tables, charts, and workflows more realistically.

But sample data should be clearly distinguishable from real production information.

Ask condoo.Vibe questions about your data model

You can also use condoo.Vibe to help understand the application you're building.

For example:

Explain how customers, projects, tasks, and users currently relate in this application. Don't make any changes.

Or:

Analyze the current database structure and identify whether anything would prevent a customer from having multiple projects.

This can be particularly useful before making significant changes.

Explore or Plan Mode can help when you want analysis before implementation.

Data Security

Your application's data may include private customer or business information.

The application should therefore enforce appropriate access rules.

For example:

Users must only be able to access data belonging to their workspace.

Or:

Customers should only see orders associated with their own account.

Or:

Only administrators should be able to access the complete customer directory.

These rules should be enforced in the application's backend, not only through the visible interface.

Think in ownership

For private application data, ask:

Who owns this record?

For example:

Workspace
   ↓
Project

or:

Customer
   ↓
Order

or:

User
   ↓
Private Document

Then define who should be able to access it.

This becomes particularly important for multi-tenant applications.

Example: Managing CRM Data

Suppose you're building a real estate CRM.

Your application contains:

Workspace
   │
   ├── Agents
   ├── Leads
   ├── Properties
   ├── Deals
   └── Follow-ups

You might tell condoo.Vibe:

Every CRM record must belong to a workspace. Users should only see data belonging to workspaces where they're members.

Then:

Add search, filters, sorting, and pagination to Leads.

Then:

Allow agents to archive lost leads instead of permanently deleting them.

Then:

Show pipeline value by deal stage on the dashboard.

Then:

Add an activity history to each lead showing important changes.

You're progressively turning raw stored information into a complete data-management experience.

Example: Customer Portal

Imagine a customer portal containing:

Customer
   │
   ├── Projects
   ├── Files
   ├── Invoices
   └── Messages

You could define:

After signing in, customers should only see records associated with their own account.

Then:

Show active projects first and allow completed projects to be viewed through an archive.

Then:

Allow customers to search their files by filename and project.

Then:

Show unpaid invoices at the top of the Billing page.

The database provides the information.

condoo.Vibe builds the experience around it.

A useful data checklist

When building a data-driven feature, think about:

What information exists?

Leads, customers, bookings, orders...

How is it created?

Form, import, payment, automated process...

Who can see it?

Owner, team, customer, administrator...

Who can change it?

Everyone, assigned users, admins only...

How is it organized?

Search, filters, sorting, pagination...

What is it connected to?

Customer → Project → Task

What happens when it's deleted?

Permanent deletion, archive, cascade...

What happens when there is no data?

Empty state.

What happens while loading?

Loading state.

What happens when loading fails?

Error state.

These questions help turn a database-backed feature into a complete product experience.

You manage the product, not the database server

condoo.Vibe's goal isn't to require every founder, marketer, designer, or business owner to become a database administrator.

You define:

condoo.Vibe helps translate those decisions into the application.

And because condoo.Vibe uses Neon Postgres, your dynamic application can have a real relational database behind the experiences you're building.

Section 3 Complete

You now understand the major systems condoo.Vibe can build behind your application:

Database

Persistent application data powered by Neon Postgres.

Authentication

Google and email/password user identity.

Forms & Uploads

Ways for users to provide information and files.

Email & Payments

External workflows powered through integrations.

APIs & Server-Side Logic

The rules and functionality behind your application.

Project Data

The information your users create and how your product works with it.

Together, these systems allow condoo.Vibe to go beyond generating interfaces and help you build full-stack applications.

Next: Integrations (Connectors)

Some capabilities depend on services outside condoo.Vibe.

Payments need Stripe.

Transactional email can use Resend.

Communications can use Twilio.

Media can use Cloudinary.

AI features can connect to providers such as OpenAI, Anthropic, Google, and xAI.

In the next section, we'll cover condoo.Vibe Connectors, starting with what connectors are, how they work, and how condoo.Vibe handles the credentials required to connect external services.

What connectors are

Learn what condoo.Vibe connectors are and how your keys are stored.