[ 2026-05-11 ]

Vibe coding a project management app with Claude

Oliver is a small browser-based project management application for turning messy delivery work into a visible map. I built it with Claude, using the project as a way to explore how planning software can show both formal structure and practical dependencies at the same time. My experience and preferred style of working shaped a simple but powerful concept.

Overview

The concept is a canvas where every piece of work is represented as a rectangle (we used Miro a lot). A department objective can be broken down into initiatives, projects, workstreams, tasks and subtasks, creating a clear hierarchy from strategy through to execution. Instead of hiding that structure inside nested lists, Oliver lays it out spatially so the shape of the work can be read at a glance.

The application also separates hierarchy from dependency. A project can belong to an initiative, but it can also depend on a workstream, task or subtask somewhere else in the map. Those dependency links are drawn directly between rectangles, making it easier to see where delivery risk, handoffs or coordination problems might sit.

How it works

Users create canvases, add work items, choose each item's level in the hierarchy, and place it on the map. Items can be dragged around freely, while their connecting lines follow them. The tool uses colour to distinguish levels of work, green connectors for hierarchy relationships, and coral connectors for dependencies.

When a user starts drawing a connection, Oliver highlights valid targets and fades out unavailable ones. This keeps the map flexible without letting the structure become meaningless: department objectives flow down through the hierarchy, while dependency links are reserved for the levels where actual delivery coordination usually happens.

Development process

I followed a loose vibe-coding process: start with the feeling of the tool, make the smallest working version, then tighten the rules as the product logic became clearer. The first idea was simple: combine the visual freedom of Miro with the accountability of Microsoft Planner. From there, the work became less about adding features and more about deciding what the map should refuse to do.

The hierarchy was the anchor. I settled on Department Objective -> Initiative -> Project -> Workstream -> Task -> Sub-Task, then used that as the source of truth for creation rules, valid hierarchy links, and visual colour. Every item stayed as the same rounded rectangle so the interface did not become visually noisy; the object type, connector state and relationship rules carried the complexity instead.

The interaction model changed through iteration. The early version used dropdowns to create relationships, which worked technically but felt too administrative for a canvas tool. The next version moved relationship creation onto the map itself: connector dots on each rectangle, drag-to-link behaviour, target highlighting while drawing, and a small popover that asks the user to choose between hierarchy and dependency only when that choice is valid.

That rule-checking became the main technical pattern. Hierarchy links are validated against the object stack, with one important exception: a Project can be tied to more than one Initiative. Dependency links are deliberately narrower and cannot go higher than Project, so Initiative and Department Objective objects remain strategic structure rather than operational blockers. When a rectangle is moved, its stored coordinates change and the SVG relationship paths are recalculated from those coordinates, which keeps the diagram feeling alive without needing a heavier canvas engine.

The development process was conversational and visual. Each pass started with a product instinct: make it blank on startup, remove bulky explanation, make the background darker, make rectangles rounder, allow free zoom, add saved canvases, then make the lines feel hand-drawn rather than form-driven. The result is a small prototype, but the logic underneath is already close to a real product model: typed objects, relationship validation, local persistence, canvas navigation, and visual feedback during user actions.

Why it matters

Most project management tools are good at storing tasks, but less good at showing why one piece of work is blocked by another. Oliver treats the project plan as a living diagram. It is meant to help a team see where work belongs, how it connects, and which items are becoming pressure points because too many dependencies run through them. If a team wants to delegate work out, Oliver can provide a platform for visibility on downstream reasoning behind a project.

The pain-point view is designed for moments where a user or manager needs to know what to push next. At work, several projects can be held up by the same blocker (i.e. Cyber clearance or an email procedure being enacted in Snowflake). If that blocker is visible as a shared pain point, it becomes much easier to see that resolving one issue could get several projects moving again.

The Oliver demo includes local canvas saving, quick switching between saved maps, starred canvases for important flows, zooming, panning, dependency visibility controls, and a pain-point view that highlights items with multiple dependency connections. The result is less like a task list and more like a working model of how delivery is actually arranged.