A product becomes a conversation.
Today, QA.army welcomed its first design partner. We have spent our early work testing the product on our own journeys. Bringing in a partner opens a different conversation: what does another team need to check before it feels ready to ship?
That is the milestone we are celebrating. The partner’s production account is confirmed and enabled. Their identity and private product details are kept out of this announcement.
QA.army is built around a straightforward idea: describe an important user flow in plain language, execute the saved Test, and inspect what actually happened. A useful result connects the expected behavior to a Run and its evidence.
Build around the work a team needs to do.
A design partnership gives product decisions a concrete place to start. Which customer journey matters most? What would a meaningful failure look like? Can someone understand the outcome without reconstructing an entire debugging session?
Our aim for this partnership is to learn from those questions and improve the ordinary QA.army experience. The standard is the same one we apply to our own product: a claim about working software should come with something a person can inspect.
We have published our own QA dogfood state and release bar, including the gaps still being closed. That transparency continues as we work with design partners.
The proof behind this announcement.
QA.army checked the supplied partner account against production account records on September 15, 2026, Pacific time. The account was created that day and is confirmed and enabled. The first-design-partner designation comes from our launch announcement.
The public proof summary records the scope of that verification. Customer quotes, private screenshots, and performance results are not part of this release.
Bring one journey that needs to work.
Start with your application URL and the customer flow you care about. Use the product directly, or read the current agent setup instructions before asking a coding agent to begin.