Skip to content

๐Ÿงญ Way of Working (WoW)

We operate in one synchronized flow with a philosophy - Vibe collaboratively, Iterate intentionally.

Our flow is fully guided by the customer sentiment, it ensures the feature lifecycle (Design System -> Idea -> Design -> Build & Validate -> Live) is followed transparently (between customers and Visualli Crew). This is our promise to the customers - Co-creating with them.


๐ŸŒŠ Vibe Collaboratively, Iterate Intentionally.

The high-level journey of every feature.

graph LR
    S[<span style='color:#000; font-weight:bold; font-size:18px'>๐ŸŽจ Design System</span>] --> A
    A[<span style='color:#000; font-weight:bold; font-size:18px'>๐Ÿ’ก Idea</span>] --> B[<span style='color:#fff; font-weight:bold; font-size:18px'>๐Ÿงฉ Design</span>]
    B --> C[<span style='color:#fff; font-weight:bold; font-size:18px'>๐Ÿ”จ Build & Validate</span>]
    C --> D[<span style='color:#000; font-weight:bold; font-size:18px'>๐Ÿš€ Live</span>]

    style S fill:#FFD347,stroke:#333,stroke-width:2px,font-weight:bold,font-size:18px
    style A fill:#12C7D3,stroke:#333,stroke-width:2px,font-weight:bold,font-size:18px
    style B fill:#325E8C,stroke:#333,stroke-width:2px,font-weight:bold,font-size:18px
    style C fill:#8A70A6,stroke:#333,stroke-width:2px,font-weight:bold,font-size:18px
    style D fill:#F28C16,stroke:#333,stroke-width:2px,font-weight:bold,font-size:18px
Phase Starts here What happens there? Ends here
๐ŸŽจ Design System The Design System - start with its Feature matrix. - Find its place. Decide which surfaces it fits (web, mobile, MCP widget, Chrome extension, desktop viewer etc).

- Shape it. Design it into the components and prototypes of each surface until it is UX Ready on the Feature matrix. It gets a SPEC or PRODUCT tag based on where the feature must reside ultimately.

- Release it. Merge design-system/* changes to dev to release a new design-system version. If the change affects what the open .visualli spec renders, the release also opens a new PR on the spec repo to keep the two in sync.
- New design-system version released (if it introduces any new components or tokens etc).

- Spec PR reviewed and merged, if one was opened - our product surfaces render visuallis by importing the spec, so both must stay current and in-sync always!

- Continue with ๐Ÿ’ก Idea step, enrich the feature description by adding the VI-xxx ID from the Feature matrix.
๐Ÿ’ก Idea Public Backlog or Private Backlog - For Public Backlog, our customers are able to influence our priorities directly via together.visualli.ai and via Give Feedback button inside our App.

- For Private Backlog, which is meant for internal stuff (e.g. tech debt, security postures, etc), priorities are set by Visualli Crew during All Hands calls.

NOTE: In both cases, you need to tag at least one another Visualli crew member to be able to take their feedback into the design / build of the feature.
- Polished story title & description, citing the feature's VI-NNN ID from the design system, to reflect 'human-centered' approach and establish clear, intuitive outcome to be expected by the user.
Example Feature: here.

- For frontend stories, provide these special instructions here so the agents can consume the design-system effectively during the implementation.
๐Ÿงฉ Design Move the feature card to Design column. - This triggers a webhook automatically which spins-off a throw-away container for the Agent Loop on build.visualli.ai letting the Visualli Crew to collaboratively iterate on the design. - The direct URL to the Agent Loop Chat can be found under the feature comments section.

- New feature branch created on GitHub with the PRD (product requirements spec) under prds/* folder available for human review.

โ€ผ๏ธ MUST DO: Owner of the feature must review the PRD line-by-line, iterate with the agent / Visualli Crew on build.visualli.ai until they are happy with the PRD to proceed further.
๐Ÿ”จ Build & Validate Move the feature card to Build column. - This triggers a webhook automatically which re-uses the above container to continue with the actual build of the feature strictly based on the PRD that we signed-off.

- On every PR comment on GitHub, it triggers webhook again and re-uses the above container (for context purposes) and completes its job.

- When the PR is merged, it triggers clean-up of containers and things are kept tidy.
- New PR is created on GitHub for this feature avaialble for human review.

- Further conversations will happen on GitHub as a part of PR comments section, which will be picked up by the build.visualli.ai automatically.

- PR has been reviewed & approved by self & one another Visualli Crew.

- PR is merged to dev branch

- Feature is available on dev.visualli.ai.

โ€ผ๏ธ MUST DO: Owner of the feature must review the code, and continue iterating with the agent / Visualli Crew on build.visualli.ai until they are happy with the outcome and passes all the validation checks.
๐Ÿš€ Live Move the feature card to Live column.

โ€ผ๏ธ CAUTION: This action will trigger automated e-mails to all customers who have subscribed to this feature (to be informed) so they can start using it right away.
โ€ผ๏ธ MUST DO: Visualli Crew releases it to Alpha environment manually based on schedule / need-basis. - Live on alpha.visualli.ai.

๐Ÿ˜‰ For curious minds!

Why the design system comes first

Shaping a feature in the design system first keeps every surface consistent. The same release keeps the open spec in sync โ€” and our apps render Visualli with that very spec.

How this all comes together

Our synchronized flow is powered by a seamless product-human-agent collaboration architecture, where AI-powered containers spin up and persist contextually across every stage of your feature's journey.

This design keeps cross-functional Visualli Crew, customers, and autonomous build agents in perfect alignment, turning customer feedback and ideas into live features through transparent, iterable loops that preserve context, automate repetitive toil, and keep collaboration at the heart of every release.