Workflow Blueprint is a small, production-shaped task planning workspace I built around a simple premise: the next useful workflow app is not just a dashboard for a human to click through. It is a shared operating surface for humans, APIs, and headless agents. The browser still matters. The contract underneath it matters more.
On the surface, the product is familiar: sign in, open a dashboard, jump into a board, drag tasks through a kanban flow, edit details, track subtasks, write notes, and switch between day and night modes. Underneath, the more interesting build decision is that the same task system also exposes a private read-only API so an agent can inspect work without pretending to be a user moving a mouse around a web page.
Why build another task workspace?
Most task tools are optimized for one of two extremes. Either they become personal scratchpads, useful but too loose to trust as an operating system, or they become heavyweight project-management suites that ask a solo operator to maintain the tool instead of doing the work.
Workflow Blueprint sits in the middle. It is built for a person or small team that wants just enough structure: named boards, clear statuses, task details, subtasks, notes, and a dashboard that answers basic operational questions without ceremony. How many tasks are in progress? What percentage of active work is done? Which boards are carrying the load? What closed in the last seven days?
That is intentionally not a huge product surface. The goal is to create a reliable workflow map, not another place to hide work behind configuration. The app ships with a fixed vocabulary of statuses:ICE_BOX, ON_DECK, IN_PROGRESS, DONE, and ARCHIVED. That vocabulary is boring in the right way: agents, API routes, dashboard metrics, and UI components all speak the same language.
The stack is deliberately narrow
The codebase is a Next.js 16 App Router application using React 19, Prisma 6, Supabase Postgres, Tailwind CSS 4, Zod, signed HTTP-only cookies with jose, and Resend for transactional email. That stack gives the project three things I care about in a one-person product build:
- Server-rendered entry points. Dashboard and board pages fetch snapshots on the server, so the first render already has the user’s current work state.
- A typed persistence layer. Prisma keeps users, boards, tasks, subtasks, notes, password reset tokens, and invitations explicit instead of hiding the business model in ad hoc JSON blobs.
- Runtime validation at the edges. Zod validates incoming task, note, profile, auth, invitation, and read-only API payloads before the app trusts them.
The result is a codebase that stays small without being casual. There is a shared API helper for JSON parsing, authentication checks, and rate limiting. Data access lives behind named functions like getDashboardSnapshot, getBoardSnapshot, and reorderTasksForUser. The UI receives serialized snapshots instead of reaching through the stack for whatever it wants.
The product loop is board, detail, note, review
The main board screen is the workhorse. It supports a kanban view and a list view, an archive toggle, drag-and-drop task movement, a task drawer for editing details, sortable subtasks, due dates, and an autosaving notes panel. The UI is intentionally tactile: blueprint grid paper, strong borders, compact controls, and enough color to show state without turning the workspace into decoration.
The dashboard is the review layer. It does not try to become analytics theater. It computes a few blunt signals from the same data model the board uses: task breakdown by board, sprint completion rate, active task count, in-progress count, and work closed in the last seven days. For a small operational system, those signals are enough to start a weekly review.
That split matters. Boards are where work changes. The dashboard is where work is interpreted. The API contract follows the same split.
Security starts with boring constraints
The app is invite-only. Admins create invitations, invitations are tokenized, accepted invitations are tied back to accounts, and welcome or reset emails flow through Resend when email is configured. Password reset tokens are hashed and claimed before the password changes. Session cookies are HTTP-only, signed, same-site, and secure in production.
None of that is flashy, which is the point. A workflow tool stores the shape of a person’s life or a firm’s operating reality. Even a tiny task app deserves production-grade defaults: scoped queries by user, schema validation on every mutation, rate limits on sensitive routes, non-leaky auth failures, and predictable error responses.
Small software should not mean casual software. The app is compact, but the security posture is intentionally closer to a commercial product than a weekend demo.
The read-only API is the agent surface
The most important architectural piece is the private read-only API. Workflow Blueprint exposes three agent-friendly endpoints:
GET /api/read-only/dashboardfor top-level task metrics, board breakdowns, sprint completion, and recent close counts.GET /api/read-only/boardsfor the list of boards, slugs, descriptions, icons, and task totals.GET /api/read-only/boards/[slug]for a full board snapshot: note content, tasks, statuses, due dates, completion timestamps, archive timestamps, and subtasks.
Access requires either an Authorization: Bearer <READ_ONLY_API_KEY> header or an X-API-Key header. The configured token and submitted token are hashed before comparison, then checked with a timing-safe comparison. Responses set Cache-Control: no-store and X-Robots-Tag: noindex. The endpoint is rate limited and intentionally read-only.
The subtle part is response validation. The read-only API has its own Zod contract in read-only-contract.ts, and responses are validated before being returned. If the server accidentally constructs a payload outside the published shape, the endpoint fails instead of leaking a surprise contract to whatever agent depends on it.
Headless agents should not screen-scrape the kanban board. They should call a typed, permissioned, observable contract.
Why read-only first?
It is tempting to start agent integration with write actions: create a task, move a card, archive something, rewrite the weekly plan. That is the demo path. It is not the safest product path.
Observation is already valuable. A headless agent with read-only access can prepare a morning brief, summarize stalled work, find overdue tasks, compare board load, draft a weekly review, or answer, “What should I look at first today?” It can do all of that without changing production data. The first agent surface should make the system legible before it makes the system writable.
Write access can come later, but it should arrive with an approval model, audit trail, and idempotent tool contracts. The read-only API is the first half of that architecture: a stable map of the work, designed for non-human operators from the beginning.
What this says about Software 3.0
Workflow Blueprint is a small project, but it points at the bigger shift I keep seeing in AI-native software. The valuable part is no longer only the interface. The valuable part is the contract layer that lets the same workflow be used by a browser, a cron job, a command-line tool, a Slack bot, or an agent.
In older SaaS, the dashboard was the product. In agent-ready software, the dashboard is one client. The real product is the data model, permission boundary, validation layer, and tool surface that make the workflow safe to operate from multiple places.
That is why Workflow Blueprint was worth building this way. A practical task workspace gives the human a clean place to run the week. A private read-only API gives headless agents a clean place to understand the week. The combination is where the product starts to feel less like another task board and more like an operating layer.
What I would build next
The next layer is not more UI chrome. It is better operational leverage: request-scoped telemetry, model and token accounting for agent calls, agent-readable route documentation, and eventually a write API with explicit approvals. That is the path from useful task workspace to agent-ready workflow substrate.
For now, the important foundation is in place. Workflow Blueprint has a real UI, a real data model, a real auth model, and a read-only contract that treats headless agents as first-class consumers. That is the build I care about: small enough to own, structured enough to trust, and ready for the software layer that comes after dashboards.
