4 min read - Evaluating SoarUI for an Enterprise Angular Team

A shared design system can remove repeated interface work, but only if product teams can adopt it without surrendering control of their application. That is the problem we are addressing with SoarUI, an Angular and Tailwind design system under active development at Exceev.

This article describes the project as it exists today. It does not claim a public release date, licence, price or fixed catalogue because those decisions are not yet published.

The question SoarUI is meant to answer

When several Angular products solve buttons, forms, navigation and visual tokens separately, small differences accumulate. Accessibility fixes land in one application but not another. A brand change requires several implementations. Engineers spend review time debating interface details that should already have an owner.

A shared system can move that work into reusable components and conventions. The value is qualitative until a team measures its own baseline. We therefore do not promise a generic percentage of time saved. The relevant measures are local: time from design approval to a tested screen, defects caused by inconsistent components, accessibility findings and the cost of upgrading Angular across consuming applications.

What is verified today

SoarUI is:

• an Angular design system that uses Tailwind;
• under active development;
• used in the FormAI interface;
• intended to provide reusable components that can reduce repeated implementation work;
• represented by its official website at soarui.com.

Those facts do not establish that every component is production-ready, that the library is open source or that it is generally available. Teams evaluating it should use the current project page and waitlist rather than assumptions copied from an older article.

How to evaluate a shared design system

Start with one screen that already exists. Inventory the states that make it difficult: validation, loading, empty results, keyboard navigation, responsive layout and translated copy. Then recreate that screen with the candidate system in a branch.

Review four things before discussing rollout:

1. Behaviour. Does the component handle the real states in the product, including errors and partial data?
2. Accessibility. Do keyboard, focus, labels and contrast work in the consuming application? A design system can support accessibility, but it cannot certify the final product by itself.
3. Adaptation cost. Can the team apply its visual language without overriding internal selectors or forking the component?
4. Ownership. Who reviews changes, communicates breaking changes and supports product teams when a shared component is wrong?

This trial should produce evidence, not a sales comparison. Record the implementation time, the code that remains product-specific and every gap that required a workaround.

Adopt incrementally

A design-system rollout does not require a rewrite. Begin with a small component whose states are understood, publish the integration rules and keep the existing implementation available until the replacement passes the same tests.

The next component should be chosen because it removes repeated work, not because it makes the catalogue look complete. Forms and data-heavy views often expose important requirements, but the right order depends on the products that will consume the system.

For SoarUI, FormAI provides a real product context in which components and conventions can be exercised. That is more useful than an invented table claiming that a data grid always saves a particular number of days.

What buyers should ask next

Before adopting any internal or third-party design system, ask for:

• the supported Angular versions and upgrade policy;
• the current component inventory and known limitations;
• examples of keyboard and screen-reader testing;
• the theming and token contract;
• the release, migration and support process;
• evidence from a trial in your own application.

SoarUI remains in active development. See the SoarUI project page and official website for the current public information.

Sources

• SoarUI official website, reviewed 27 August 2026
• Exceev SoarUI project page, reviewed 27 August 2026