Two problems collapsed into one build. The first is generic: teams don’t need Jira’s endless configuration surface, they need a ticket tracker that matches how their org actually works — its own roles, its own workflow states, its own custom fields — without paying for or fighting a general-purpose tool. The second is the one I actually cared about: can an agent be trusted to build a real multi-week feature set unattended, all the way through spec, implementation, and test evidence, without stopping every few minutes for a status check?

That second question is the one with legs for a company. Any engineering org running AI-assisted development hits the same wall — an agent that writes code fast but needs constant babysitting doesn’t actually save time, it just moves the bottleneck to the human reviewing every step. The interesting engineering question is whether you can build enough structure (specs, guardrails, a place to log decisions and blockers) that the agent can run for hours against a real, non-trivial backlog and produce something a human would actually sign off on.

DTT (Development Ticket Tracker) is a full Jira-like issue tracker: multi-workspace and multi-project structure, role-based access across eight roles (Admin, Owner, Project Manager, Team Lead, Team Member, Tester, Account-Manager Manager, Account-Manager Member), and a ticket model with statuses (Backlog, In Progress, In Review, Testing, Done, Rejected, Closed), priorities, sub-tasks, relations, labels, custom fields, and configurable ticket types per project.

On the actual screens: a global Kanban board and a per-project board with area/sprint filters and drag-and-drop reassignment; a Backlog view grouped by application area with “move to sprint”; a Sprint Board with sprint create/start/complete lifecycle; an Epic view with per-epic ticket counts; a My Work view split into assigned/reported; a Reports dashboard with stats by status/priority/area and CSV export gated by role; global search; saved filters; in-app notifications with mark-read/mark-all-read; and a ticket detail slide-over with Details/Comments/Subtasks tabs, @mentions, comment moderation, file attachments, and time logging. Admin screens cover user/role bootstrap, workspace and project settings, workflow configuration (which status transitions are legal), and label/custom-field config. Auth is email/password plus Google OAuth, dark/light mode, keyboard shortcuts, and responsive layout down to 375px are all in.

What makes this one worth writing about isn’t the CRUD app itself — it’s how it was built: I wrote 58 Gherkin-style requirement cards up front (one markdown file per REQ, each with Given/When/Then acceptance criteria), then ran an autonomous “Ralph loop” — a single long-running agent driver that read one unchecked requirement at a time, implemented the backend, the UI, unit tests, integration tests, and a dedicated Playwright e2e spec per requirement, then checked the box and moved to the next one, with no human in the loop between requirements. It ran end to end — Next.js 16 App Router, Prisma 7 over Postgres, Auth.js v5, shadcn/base-ui, SSE for live notifications — until all 58 requirements were checked off and it wrote its own DONE.flag.

The loop only stayed honest because I forced evidence at every step: no requirement gets checked off without unit, integration, and Playwright tests passing, and every test run gets pasted into TEST_EVIDENCE.md rather than summarized. Without that rule an agent will happily mark things done on vibes. The other half was giving it a place to fail loudly instead of silently: a DECISIONS.md for architectural choices it had to make on its own (like resolving a mismatch between the spec’s role list and the schema’s role enum) and a LESSONS_LEARNED.md logging every blocker that stopped the loop — wrong DB credentials, a misspelled Jest config key, a Next.js 16 middleware rename it didn’t know about, Prisma 7 dropping automatic DATABASE_URL reads. Feeding each blocker back into the driving prompt meant the loop got harder to stop over time instead of hitting the same wall twice.

The most useful realization was procedural, not technical: one requirement per iteration, never two. That constraint is what kept a 58-requirement, multi-week-equivalent build from drifting into inconsistent patterns or losing track of what “done” meant.

As a tracker, the natural extension is the stuff every team eventually asks Jira for: webhooks/API for CI integration, a public API for other tools to file tickets against, and SSO/SCIM for real org onboarding instead of an admin-bootstrap flow. The role model (eight roles, workspace/project scoping) is already shaped like something a mid-size engineering org could actually run internally instead of paying per-seat for a heavier tool.

The bigger transfer is the build methodology, not the app. “Spec as Gherkin cards up front, autonomous loop implements one card at a time end-to-end with mandatory test evidence and a running decision/blocker log” is a pattern that generalizes past ticket trackers to any backlog-shaped piece of internal software — a team could point the same loop at their own REQ list for an internal admin tool or a migration project. At enterprise scale that’s the pitch: agent-driven development stops being a demo and starts being adoptable once there’s an audit trail (decisions log, blocker log, per-requirement test evidence) a tech lead can actually review after the fact instead of trusting the agent’s word for it.