The Provider / Client Model
Every project in Vanillaround is built around two distinct roles: Provider and Client. Understanding this distinction is the foundation for using the tool correctly.
Providers
Section titled “Providers”A Provider is the delivery team — the agency, development team, or consultancy responsible for building the product. Providers are typically the ones who:
- Set up and structure the project
- Write and maintain the spec pages
- Define and configure requirement cards
- Propose solutions and technical approaches
- Sync approved requirements to Jira and begin development
Think of the Provider as the team that needs a clear, approved mandate before they can safely start building.
Clients
Section titled “Clients”A Client is the business side — product owners, stakeholders, executives, or any decision-maker who defines what should be built. Clients:
- Read and comment on specs written by the Provider
- Request changes to requirements before approving
- Formally approve or reject individual requirement cards
- Track progress through boards and change feeds
The Client does not need to understand how something will be built — only what it should do and whether the spec accurately captures their intent.
Why the separation matters
Section titled “Why the separation matters”This two-role model mirrors how real software projects actually work: one side knows the business problem, the other knows how to solve it technically. Without a formal handshake between them, assumptions fill the gap — and assumptions are where projects go wrong.
Vanillaround’s approval workflow enforces that handshake. A requirement card cannot be considered ready for development until a Client with the right permissions has explicitly approved it. This creates an auditable record of who agreed to what and when.
Inviting people to a project
Section titled “Inviting people to a project”When you invite someone to a project, you assign them either the Provider or Client role. This determines:
- Which parts of the interface they see
- What actions they can take on cards
- How they appear in the approval workflow
See Members & Roles for the full breakdown of permissions.