FluentBoards from WPManageNinja is a recent, well-built kanban and project-management plugin in the same family as Fluent Forms, FluentCRM, and Fluent Support. It is shaped like a Trello-or-Asana clone that lives inside wp-admin: workspaces, boards, stages, tasks, subtasks, comments, time tracking, and integrations with the rest of the FluentCRM stack. The data is its own, stored in custom tables that the plugin owns and manages.

SleekView is not a project-management product. It is a data-views plugin: point it at any post type, configure columns or kanban groups or feedback cards, and render that data as a view. The kanban view type is one of several, all reading the same CPT and ACF or Meta Box fields. There is no concept of a board with its own tasks; the cards are the posts the rest of WordPress already knows about.

That makes the choice a question of what is being built. A team kanban for project management, with subtasks, time tracking, and a Fluent ecosystem to plug into, is what FluentBoards is for. A view of existing WordPress data (roadmap, content workflow, leads, releases, anything that already exists as a CPT) rendered as a kanban among other view types, is what SleekView is for. Both are valid, and they rarely overlap on the same job.

FluentBoards and SleekView's kanban look similar in screenshots, columns, cards, drag-and-drop, but the products underneath are different shapes solving different problems. FluentBoards is a project-management application that happens to live inside wp-admin: it ships its own data model (workspaces, boards, stages, tasks, subtasks), its own UI for editing those records, and its own ecosystem hooks into the FluentCRM family. The kanban is the product.

SleekView is a view layer over WordPress data: the data already exists as a post type, structured with ACF or Meta Box, and the kanban is one of several ways the team wants to look at it. Picking the wrong shape is more painful than picking the wrong feature. A team buying SleekView to manage internal tasks finds the PM features missing, because data rendering is not project management.

A team buying FluentBoards to render a public roadmap finds itself fighting to surface task data into the rest of WordPress, because plugin tables are not posts. The honest answer is that the two products only compete in a thin overlap: kanban over data that could plausibly live as a CPT or as plugin tasks. Outside that overlap, the choice is a question of product shape, not which one is better, and the right pick is the one whose data model matches how the data actually wants to live.