Pulse entry

A public ideas project built from RustGrid primitives

2026-06-24
Back to Pulse
productfeedbackideascustom-fieldspublic-roadmap

Product feedback usually starts in the wrong place.

Teams add a feedback widget, collect a pile of messages, export the useful ones into a spreadsheet, and then manually copy the important requests into the product roadmap. The public surface and the internal workflow drift apart almost immediately.

The better shape is simpler: make the feedback surface a RustGrid project.

Think of it as a modern Get Satisfaction-style project. A customer opens a tab in the product, searches existing ideas, votes for the ones that match their need, comments with context, or suggests a new idea. Internally, the team sees the same object as a ticket with status, ownership, comments, audit history, custom fields, and workflow automation.

No sync job. No duplicate roadmap. No separate feedback database.

The public ideas tab is just another surface over the same workflow core.

The Project Model

Create a public project called IDEAS. Its tickets are customer-facing ideas:

{
  "project_key": "IDEAS",
  "type": "idea",
  "title": "Let customers bulk edit renewal dates",
  "description": "Several account managers need to update renewal dates across many customers at once.",
  "status": "open"
}

The default workflow can stay small:

  • open
  • under_review
  • planned
  • in_progress
  • shipped
  • declined

That is enough for customers to understand where an idea stands and enough for the product team to operate the backlog.

Custom Fields

The project can use custom fields instead of hard-coding a feedback schema into the product:

  • product_area: CRM, billing, permissions, reporting, integrations
  • customer_segment: startup, mid-market, enterprise, internal
  • impact: low, medium, high
  • effort: small, medium, large
  • roadmap_confidence: exploring, likely, committed
  • source: product_tab, support, sales, success, import

Those fields let teams build views without changing the primitive. Product can sort by impact. Support can filter by customer segment. Engineering can look at planned ideas by effort. Leadership can see committed roadmap items without asking where the latest spreadsheet lives.

Votes Are Events

Voting should be a first-class action, not a counter hidden in a widget table.

curl -X POST "https://app.rustgrid.com/api/v1/projects/IDEAS/tickets/idea_123/votes" \
  -H "Authorization: Bearer <PUBLIC_IDEA_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: vote-cus_42-idea_123" \
  -d '{
    "actor": {
      "type": "customer",
      "external_id": "cus_42"
    },
    "weight": 1
  }'

The vote increments the visible score, records the actor, and emits an event. If the same customer votes again with the same idempotency key, the operation is safe to replay. If the team wants account-weighted voting later, the vote event can carry weight without changing the ticket model.

Suggesting A New Idea

The product tab should first search existing ideas. If no match fits, the customer can create a new one:

curl -X POST "https://app.rustgrid.com/api/v1/tickets" \
  -H "Authorization: Bearer <PUBLIC_IDEA_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: idea-cus_42-bulk-renewals" \
  -d '{
    "project_key": "IDEAS",
    "type": "idea",
    "title": "Bulk edit renewal dates",
    "description": "We need to update renewal dates for many customers after contract changes.",
    "fields": {
      "product_area": "billing",
      "customer_segment": "mid-market",
      "source": "product_tab"
    }
  }'

The public token should only be allowed to create idea tickets, vote, and add public comments inside the IDEAS project. It should not be allowed to read private projects, edit internal fields, assign owners, or transition work to shipped. That keeps the public surface small while still using the same backend primitives.

One Object, Many Surfaces

The public tab needs a customer-facing view:

  • search ideas
  • show status and vote count
  • vote for an idea
  • add a comment
  • suggest a new idea

The internal product team needs a working view:

  • triage new ideas
  • merge duplicates
  • tag product area and segment
  • move ideas through roadmap states
  • link shipped work back to release notes

Both views should read and write the same RustGrid objects. That is the point. The public surface is not a separate feedback app; it is a scoped interface over a project.

Why This Belongs In RustGrid

Feedback is workflow state.

It has identity, permissions, comments, events, status, custom fields, idempotency, audit, and integrations. Those are already RustGrid primitives. A public ideas project should compose them instead of inventing a new feedback subsystem.

This is also a good public example for RustGrid itself. We can make the repo public, show the tab implementation, and let teams inspect the exact project model:

  • an Astro or embedded product tab for the customer-facing surface
  • a RustGrid project called IDEAS
  • custom fields for product context
  • scoped API keys for public actions
  • ticket events for votes, comments, and lifecycle changes
  • webhooks for roadmap notifications

That is the product story in code: workflow infrastructure flexible enough to become a support queue, an internal tracker, or a public ideas board without changing the underlying model.

The old feedback widget collected suggestions.

A RustGrid ideas project turns suggestions into durable workflow.