Accela Ideas Board: From Customer Need to Working MVP

The work converted a customer replacement request into a coherent product that could be exercised end to end in a local environment. Customers could submit ideas, vote, follow progress, and see roadmap status while product managers could triage the queue and coordinate delivery status.

That is the bounded impact: a working, locally verified MVP existed where there had previously been a requirement. The product was not published, so I do not claim customer adoption, production usage, or a business outcome.

Three customer stakeholders described the need to replace the existing customer ideas board. Their requirement was larger than a submission form. A useful replacement needed to preserve participation for customers while giving product managers a practical operating queue and keeping roadmap status connected to delivery work.

I translated that need into a product surface with idea submission, voting, following, comments, notifications, roadmap visibility, and a PM triage console. Stakeholder names stay private in this public case.

I treated the board as a two-sided workflow. Customer participation and product operations had to work together, so every visible status needed a corresponding PM action and every PM decision needed a customer-facing state.

The MVP scope centered on the ideas board, notifications, and AI-assisted triage. Public comments remained controlled by a feature flag, and program-enrollment work stayed outside the initial release boundary. Those choices kept the core replacement workflow testable without pretending every adjacent idea-management feature was ready.

The TypeScript monorepo contains four app services: a Next.js 15 and React 19 web app, a Fastify 5 REST API, a BullMQ notifications worker, and a BullMQ Jira sync worker. Shared packages cover database access, typed contracts, UI components, email templates, Jira access, Supabase clients, and AI services.

Supabase Postgres supplies the data layer, with row-level security across the documented schema. Redis backs queues, caching, rate limiting, and distributed job locks. Zod validation, tiered authentication middleware, and shared types keep trust boundaries explicit across the web, API, and workers.

Bidirectional Jira synchronization connected idea status with delivery work, including polling and webhook paths designed to prevent duplicate processing. The notifications worker handled in-app events, email delivery paths, and scheduled digests.

The AI layer used Claude for duplicate detection and tag suggestions at submission time. AI remained an assistive triage layer rather than the system of record. Product status, permissions, and lifecycle decisions stayed in deterministic application and database logic.

The repository's main-branch CI passed. Its documented local readiness pass included type checking, linting, unit and integration tests, 127 browser tests, an eight-check smoke run, and local performance baselines for idea, notification, and vote paths.

The local import and seed dataset contained 2,468 ideas, 979 comments, 204 roadmap items, and 1,158 legacy authors. Those counts demonstrate validation scale only. They are not customer, adoption, or production-usage metrics.

The project reached a locally running MVP, not a hosted product. Production services, hosted pipelines, owned integration credentials, and environment promotion were outside the completed scope. The repository remains private.

I use this case to demonstrate translation from customer requirement through product definition, architecture, implementation, and verification. I do not claim that customers used the replacement, that Accela published it, or that it produced a commercial result.