FlowBoard: the tracker I run my own work on.

A board that loads fast and stays in sync.

Columns, story points and epic pills, all drag-and-drop with optimistic UI. Every issue carries a per-project number that starts at #1 for each project, so the ids stay short and human. When a card moves, connected clients update over SignalR instead of waiting for a refresh.

I wanted a portfolio piece that was actually load-bearing.

My day job is .NET, C# and SQL, and none of that work is public. A toy CRUD app would not have shown much, so I built the tool I would have to live with: FlowBoard runs on my own machine and holds its own backlog. Every feature on it exists because I hit the gap while using it.

That constraint kept the scope honest. Bulk actions exist because triaging a dozen issues one at a time was tedious. The notification centre exists because I kept missing replies. The cumulative flow diagram exists because I wanted to see where work was piling up, and a bar chart would not have told me.

Raw SQL, on purpose, all the way down.

There is no Entity Framework here, and that is the point. Every query is hand-written SQL executed through Dapper and Npgsql, so the interesting work stays visible instead of disappearing behind an expression tree.

SELECT
  s.name,
  COALESCE(SUM(i.story_points), 0) AS points_completed,
  SUM(COALESCE(SUM(i.story_points), 0))
    OVER (ORDER BY s.start_date ROWS UNBOUNDED PRECEDING) AS cumulative_points
FROM sprints s
LEFT JOIN issues i
  ON i.sprint_id = s.id
 AND i.closed_at IS NOT NULL
 AND i.closed_at <= s.end_date + INTERVAL '1 day'
WHERE s.project_id = @ProjectId
  AND s.status = 'completed'
GROUP BY s.id, s.name, s.start_date
ORDER BY s.start_date;

A few other pieces of SQL worth calling out:

• Full-text search on a weighted tsvector. Title and description are indexed with different weights into a GIN index, with English stemming and prefix matching. Queries under three characters fall back to a title ILIKE, because stemming a two-letter fragment returns noise.
• Deadlock-free issue numbering. Each project has its own #N sequence. A BEFORE INSERT trigger bumps a single counter row with INSERT … ON CONFLICT … RETURNING, so concurrent inserts serialise on one row instead of racing each other.
• Sorting that cannot be injected. The issue table sorts server-side on a whitelisted set of columns, so an arbitrary ORDER BY never reaches the database.

Charts that only show what actually shipped.

The velocity chart counts completed sprints only, and counts a story point on the day it closed rather than the day you look at it. Epics roll their progress up from their issues, so a 60% bar means sixty percent of the points, not sixty percent of the tickets.

What held up, and what I would change.

• Skipping the ORM was the right call. Every performance question had an answer I could read. When a query got slow, the fix was an index and a rewritten join, not a fight with lazy loading.
• Putting filter state in the URL paid for itself immediately. A filtered, sorted issue view is just a link. It survives a refresh, and it is shareable without building anything extra.
• Realtime should have come first. I bolted SignalR on after the query layer had settled, which meant revisiting a lot of cache invalidation. Designing the event shape alongside the mutations would have been cheaper.
• It is not deployed yet. The Railway and Vercel config is written and the app runs locally against Postgres, but I have been using it as a private tool rather than a public demo. Hosting it properly, with seeded demo data, is the next job.

Read the code.

The repo includes the full schema, a documented walk-through of the trickier queries, and the xUnit and Playwright suites.