CRM Platform

Overview

This case is a B2B CRM: people, their roles, the tasks they own, and the process those tasks move through. I am publishing the shape of the work. I am not publishing a client name, a live URL, or a result I cannot source.

Context and challenge

Operational work gets messy when a task, a status, and a responsible person live in different places. The product had to make that chain visible. Someone should be able to see what the work is, who can move it, and which step it is in. The constraint is consistency. If two roles follow different rules, the interface cannot paper over that with another dropdown.

My role

My role was AI Product Builder. I defined the requirements, the business rules, the user flows, and the component structure, then guided implementation in Cursor and checked whether the result matched the rules. I do not claim that every line of code was written by hand.

Product thinking

The product is organized around work, not around a table of fields. A task sits inside a process. A process has states. A role decides who can move a state. Screens come after those rules. If a person cannot take an action, the interface should not offer it.

System architecture

At the product level I separate four areas:

• identity and roles
• tasks and their states
• the processes that connect those states
• a component system for the interface

The concrete stack, API contracts, and integrations are not documented here yet.

UX and UI

Lists, a task view, and process state need the same language. Status, assignee, and the next action should look and behave the same wherever they appear. That is the reason for a shared component set. Screen-level visual design is not part of this page yet.

Reflections

This page is ready for a conversation about the product problem. It is not ready to be read as a launch story. Before that, I need to confirm whether the product is live, what exactly shipped, and what changed for the people using it.