Kanbanish explores a product leadership problem hiding inside a familiar interface: teams do not always need more planning infrastructure; they need a clearer way to decide what exists, understand where it stands, and keep momentum visible. I designed and built Kanbanish as a restrained roadmap product for small teams that need the credibility of a real planning system without the overhead of enterprise project management software. The work focuses on information architecture, status legibility, interaction density, workflow control, and the discipline to add polish only where it supports comprehension, adoption, or team rhythm.
Small product teams often reach for heavyweight planning tools before they have a heavyweight planning problem. The result is familiar: configuration replaces clarity, teams spend time managing the tool, and the basic question of what is moving, blocked, validated, or shipped becomes harder to answer than it should be.
Kanbanish narrows the product to the decision layer that matters most. It turns loose initiatives into a visible workflow where status, ownership, priority, and context are immediately readable. The goal was not to build another project management system. The goal was to prove that thoughtful constraint can make planning faster, calmer, and more accountable.
The default workflow uses Backlog, Planned, In Progress, Testing, and Live as a simple roadmap spine. Each lane has a job: shape the idea, commit to it, move it through execution, validate it, and recognize when it has shipped. That gives the board an operating rhythm instead of becoming a generic bucket of tasks.
The system stays flexible without becoming formless. Teams can rename, collapse, recolor, duplicate, add, or remove columns as their process changes, but the core interaction model keeps the board readable. Cards remain compact while carrying the signals that matter for planning: work type, priority, source metadata, and owner presence.
Selecting a card opens a side panel instead of sending users to a separate page. That decision keeps people anchored to the roadmap while revealing the depth needed for the selected initiative.
The panel is organized around Issue, Activity, and Artifacts because each tab supports a different kind of product work. Issue defines intent and priority. Activity preserves the history of decisions and movement. Artifacts keep supporting material close without overcrowding the board. Source metadata is reflected back on the card so references like Jira links stay visible without dominating the planning surface.
Kanbanish puts structural control close to the object being changed. Columns can be added, renamed, collapsed, recolored, duplicated, or deleted from the places users already look, reducing the distance between recognizing a workflow problem and adjusting the system around it.
Workspace settings live in one predictable modal organized around Customization, Preferences, Share, and Account. That gives the product enough maturity to feel real while avoiding the fragmented administration model that makes heavier tools feel bloated.
The final product pass focused on the details that make a tool feel usable beyond a demo: workspace density, light and dark modes, sidebar behavior, column transparency, public sharing, and completion feedback. Each choice supports either comprehension, comfort, or team rhythm.
The restraint matters as much as the polish. Confetti and sound appear only at the moment work reaches the final column, reinforcing completion without turning the product into a toy. Density controls help the board scale across smaller screens. Theme and transparency settings make the workspace adaptable without distracting from the core planning task.