Skip to main content
Building a product doesn’t always happen alone. AIWA allows you to invite other people to collaborate on your projects, making it easier to work with teammates, developers, designers, partners, and other people involved in your product. Instead of sharing account credentials, you can invite people to participate through their own access. Build together without sharing your AIWA login.

Why Invite Team Members?

You may want other people involved at different stages of your project. For example, you might have:
  • A developer helping refine functionality
  • A designer reviewing the interface
  • A marketing team preparing the launch
  • A business partner reviewing progress
  • A team member managing content
  • Someone testing the application
Rather than sending screenshots back and forth or sharing your AIWA account credentials, you can bring collaborators into the appropriate project.

Your AIWA Workspace

Think of your AIWA account as the place where your products live. Inside it, you may have several projects:
Collaboration allows you to bring other people into your workflow without giving them ownership of your entire account.

Invite a Team Member

Open the project or collaboration area where you want to add someone. Choose the option to invite a team member. Aiwa Invite Team Member Enter the email address of the person you want to invite. For example: Before sending the invitation, choose the appropriate access level if prompted. We’ll explain Editor and Viewer permissions on the next page.

Send the Invitation

Once you’ve entered the team member’s information, send the invitation. Aiwa Team Dialog The invited person can then use the invitation to access the collaboration experience available to them. You don’t need to give them:
  • Your AIWA password
  • Your email password
  • Your personal login
  • Your billing credentials
Never share your AIWA account password as a way to collaborate. Invite people through the collaboration features instead.

Choose Access Carefully

Not everyone needs the same level of access. For example, someone helping you actively build the application may need more access than someone who only needs to review the project. Conceptually:
Give each person only the level of access they need. We’ll cover the differences between these roles on the next page.

Working With a Developer

Suppose you’re building a SaaS product and another developer is helping you. Your workflow could look like:
This allows multiple people to participate in the product-development process without sharing a single account.

Working With a Designer

You may want a designer to review:
  • Layout
  • Typography
  • Navigation
  • Mobile responsiveness
  • User experience
  • Branding
  • Visual consistency
Instead of sending screenshots every time the project changes, you can give them appropriate access to review the latest version.

Working With Your Internal Team

AIWA collaboration can also support internal product teams. For example:
Different people can contribute to the same product-development process. This becomes particularly useful as an AIWA project moves from an idea into a real business application.

Working With Clients

Agencies may also need to involve clients in the project lifecycle. For example:
However, client review is slightly different from normal team collaboration. We’ll cover the dedicated Client Sharing & Review workflow later in this section.

Don’t Give Everyone Editing Access

More access isn’t always better. Someone who only needs to inspect the project shouldn’t necessarily be able to modify it. For example:
Choose access based on what the person actually needs to accomplish. This helps protect the project from accidental changes.

Collaboration and Production Apps

Be especially careful when inviting people to work on applications that are already live. A production application may contain:
  • Real users
  • Customer workflows
  • Payments
  • Integrations
  • Business logic
  • Important data
Someone making changes to the project should understand that their work may eventually affect a production application. Use the same workflow we’ve discussed throughout the documentation:
Don’t publish changes simply because a collaborator made them. Review important updates first.

Collaborating With AIWA

Remember that your human team isn’t working alone. AIWA itself remains part of the product-development workflow. For example:
Your team can use AIWA to help:
  • Plan features
  • Build functionality
  • Improve designs
  • Debug problems
  • Explore ideas
  • Iterate on the product
This is where the idea of AIWA as your AI product team becomes particularly powerful. Your human team brings business knowledge and decisions. AIWA helps accelerate the work required to turn those decisions into software.

Managing Team Members

As your project evolves, the people who need access may change. For example:
Review project access periodically and make sure the right people still have the appropriate permissions.

Remove Access When It’s No Longer Needed

If someone is no longer working on the project, remove their access rather than leaving unused collaborator accounts indefinitely. This is particularly important when:
  • A contractor finishes their work
  • A team member leaves
  • A client relationship ends
  • A temporary reviewer no longer needs access
  • Someone changes responsibilities
Good access management becomes more important as your applications become more valuable.

Collaboration Without Credential Sharing

Avoid workflows like:
Apart from being difficult to manage, shared credentials make it harder to control who should still have access. Instead:
Each collaborator uses their own access.

Common Questions

Do I need to share my AIWA password?

No. Use AIWA’s invitation and collaboration functionality instead.

Can I invite someone just to review my project?

Use the appropriate Viewer or review access rather than giving them unnecessary editing permissions. We’ll explain roles on the next page.

Can I collaborate with clients?

Yes. AIWA’s Agency workflows can also support client review. We’ll cover Client Sharing & Review separately because clients often need a different experience from internal team members.

Can my team continue working after the app is published?

Yes. Publishing doesn’t end development. Your team can continue improving the project, test the changes, and publish new versions when they’re ready.

Should everyone on my team have the same permissions?

Usually not. Give people access based on what they actually need to do. Someone reviewing a project doesn’t necessarily need the ability to change it.

A Good Collaboration Workflow

A healthy workflow might look like:
As your product grows, you can adjust who participates and what level of access they have.

Build Together

AIWA can be your AI product team without preventing your human team from participating.
Whether you’re a solo founder bringing in a contractor, a startup team building a product, or an agency working with clients, collaboration gives you a structured way to bring the right people into the project.

Next: Roles & Permissions

Inviting someone is only the first step. Next we’ll cover Roles & Permissions, specifically:
  • Editor
  • Viewer
  • What each role can do
  • Who should receive each role
  • Protecting projects from unnecessary changes
  • Changing someone’s access
  • Removing access

Roles & Permissions

Understand Editor and Viewer access and choose the right role for each collaborator.