Project Management Software Visual

Visual project management usually means one of four layouts: a board, a timeline, a Gantt chart, or a calendar. They are often sold as interchangeable views of the same data, and they are not. Each makes a different property of the work easy to see and a different one hard.

We sell source code you clone and run yourself, so there is nothing here to log into. Most people searching this should use a tool they can already access, and the sections below are about choosing the view rather than the vendor.

What each layout is actually for

The third row explains most disappointment in this category. A Gantt view is only meaningful if the underlying items have durations and dependencies, and in tools where those are optional, most teams never fill them in. The result is a chart made of bars that do not constrain each other, which looks like a plan and behaves like a drawing.

Boards hide the number that matters most

A board is the default because it is the easiest to keep current. The property it hides is time, and specifically how long a card has been sitting where it is.

Two boards can look identical while one has work flowing through in three days and the other has cards eight weeks old in the middle column. If the tool offers card ageing or a cycle time report, that is the single most useful visual feature in this category, and it is more valuable than any additional layout.

Dependencies are the expensive feature

Whether a tool models dependencies properly is the main line between light and heavy products, because it changes what the software has to compute rather than just draw.

Real dependency support means moving one item moves the ones that follow, and it means the tool can tell you which chain determines the finish date. Drawing an arrow between two cards without recalculating anything is a decoration. For most software teams the decoration is fine, because the constraint is usually people rather than sequence. For construction, events, and manufacturing, the calculation matters and the light tools do not do it.

When a team builds its own view

Not often, and rarely the whole tool. What does get built is a view of existing data for an audience that should not be in the tool.

A client-facing progress page, an executive summary that rolls several projects into one picture, a public roadmap. These exist because the internal tool's sharing options are per-seat or too permissive, and because the audience needs a curated view rather than a filter on everything.

What you would start from here

There is no board, no Gantt chart, no timeline, and no dependency engine in this stack.

The projects pack ships projects, tasks, and assignment, which is the data a view renders. If you are building a client-facing or public view, the starter's organizations, roles, and invitations are what keeps one customer's data out of another's, and the Hono backend with Prisma and Kysely on Postgres is what serves it.

Two practical notes if you build a visual layer. Dependencies belong in the data model from the start, because adding them later means revisiting every existing item, and a board that stores only a status column can never become a Gantt chart. And if you want a node-and-edge canvas rather than bars, React Flow from xyflow is the library most people use; it is theirs rather than ours, and there is a wired-up example in the Aether template to read.

Below is the data and tenancy layer. The view itself is the part worth writing yourself, because it is the part your audience actually sees.