What is project data?
Project data is the information created and used by your application. For a CRM, this might include:- Leads
- Contacts
- Deals
- Follow-ups
- Notes
- Activities
- Team members
- Customers
- Services
- Staff
- Appointments
- Availability
- Payments
- Customers
- Products
- Orders
- Order items
- Addresses
- Payments
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:
AIWA can build interfaces for your data
Your users shouldn’t need to interact directly with a database. Instead, AIWA can create interfaces that allow them to work with the information stored by your application. For example, a Leads page might provide:- Search
- Filters
- Sorting
- Pagination
- Create Lead
- Edit Lead
- Delete Lead
- Status changes
- Assigned agents
Creating data
You can tell AIWA 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. AIWA can build:
- Tables
- Cards
- Lists
- Detail pages
- Kanban boards
- Calendars
- Dashboards
- Charts
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.AIWA 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:Detail Pages
Lists help users find records. Detail pages help them understand individual records. For example, selecting a lead might open:Create a lead detail page showing contact information, status, assigned agent, budget, notes, follow-ups, associated deals, and recent activity.AIWA 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:
Define deletion behavior
For important records, tell AIWA 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: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: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:
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: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 AIWA 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:- What does the dashboard show?
- What does an empty table look like?
- Is there a clear next action?
- Does the user understand what to do?
- Are charts empty or broken?
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: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 AIWA:
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 AIWA 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:- Different statuses
- Different agents
- Different deal values
- Different dates
- Completed and overdue follow-ups
Ask AIWA questions about your data model
You can also use AIWA 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:Example: Managing CRM Data
Suppose you’re building a real estate CRM. Your application contains: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: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. AIWA 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
AIWA’s goal isn’t to require every founder, marketer, designer, or business owner to become a database administrator. You define:- What information your product needs.
- How users should interact with it.
- Who should have access.
- What rules should apply.
Section 3 Complete
You now understand the major systems AIWA 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 AIWA to go beyond generating interfaces and help you build full-stack applications.Next: Integrations (Connectors)
Some capabilities depend on services outside AIWA. 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 AIWA Connectors, starting with what connectors are, how they work, and how AIWA handles the credentials required to connect external services.What connectors are
Learn what AIWA connectors are and how your keys are stored.