Shipped Building Next Declined

Where things stand

Shipped, building, next, and the ones we said no to

The fourth column is the one nobody publishes. It is here because a public no is more useful to you than a quiet maybe.

Shipped this quarter

Out and running in every practice.

Shared waiting list across sites

Eleven weeks of testing with three practices before it went out.

v3.4.0, 14 May

Insurer reconciliation on one ledger

Billing no longer splits when an insurer is involved.

v3.3.0, 11 April

Asked for by Fenwick Group

Roles in plain language

Forty checkboxes became six named roles.

v3.2.4, 9 March

Building now

In testing with at least one practice.

Public API and webhooks

Read and write on appointments and invoices, with booking webhooks already live in pilots.

Testing with 2 practices

Per-room capacity reporting

The thing we said no to twice, then built differently after a better argument.

Testing with 1 practice

Asked for by Bramble Health

Next up

Agreed, not started, in this order.

Recurring care plan templates

Repeating series defined once and applied to a member in a click.

Starts after the API

Two-way calendar sync

For clinicians who keep a personal calendar and always will.

Third quarter

Said no to

With the reasoning, so you can argue back.

Editable audit log retention

An audit log you can shorten is not an audit log. Two groups disagree and we are still listening.

Declined 12 May

An in-product marketing sender

We do not want to be the reason a member gets a promotional email from their clinic.

Declined 3 February

Anything asked for by a named practice keeps that credit through to the release note. Nine of the last quarter's changes came from the feedback group.

Ask for something
About this block

Shipped Building Next DeclinedPRO

A roadmap board of four hairline columns carrying state icons, running from what shipped through what is building to what was turned down, crediting the practice that asked where there was one.

Changelog29: Shipped Building Next Declined

A roadmap board of four hairline columns carrying state icons, running from what shipped through what is building to what was turned down, crediting the practice that asked where there was one.

Upgrade to Pro

Pro blocks install through the shadcn CLI with your license key and ship their full source. Docs and live previews stay open to everyone, so you can read every block's details first.

Upgrade Now

Installation

Swap YOUR_EMAIL and YOUR_KEY for the email and license key on your account. Find your license key on your account page.

Radix flavor

bash
npx shadcn add "https://ui.beste.co/r/changelog29?email=YOUR_EMAIL&license_key=YOUR_KEY"

Base UI flavor

bash
npx shadcn add "https://ui.beste.co/r-base/changelog29?email=YOUR_EMAIL&license_key=YOUR_KEY"

This installs the block to components/beste/block/changelog29.tsx plus the badge23 and button21 components it uses for the eyebrow and the action.

Quick start

The installed file exports changelog29Demo alongside the block: the exact props behind the preview above. Spread it to get a working board in one line.

tsx
import { Changelog29, changelog29Demo } from "@/components/beste/block/changelog29";

export default function RoadmapPage() {
  return <Changelog29 {...changelog29Demo} />;
}

Then replace the demo with your own props. Written out, a trimmed setup looks like this:

tsx
import { Changelog29 } from "@/components/beste/block/changelog29";

export default function RoadmapPage() {
  return (
    <Changelog29
      badge={{ label: "Where things stand" }}
      heading="Shipped, building, next, and the ones we said no to"
      description="The fourth column is the one nobody publishes."
      columns={[
        {
          label: "Shipped this quarter",
          summary: "Out and running in every practice.",
          state: "shipped",
          items: [
            {
              title: "Shared waiting list across sites",
              detail: "Eleven weeks of testing with three practices.",
              meta: "v3.4.0, 14 May",
              askedBy: "Asked for by Fenwick Group",
            },
          ],
        },
        {
          label: "Said no to",
          summary: "With the reasoning, so you can argue back.",
          state: "declined",
          items: [
            {
              title: "Editable audit log retention",
              detail: "An audit log you can shorten is not an audit log.",
              meta: "Declined 12 May",
            },
          ],
        },
      ]}
      footnote="Anything asked for by a named practice keeps that credit through to the release note."
      button={{ label: "Ask for something", href: "/feedback" }}
    />
  );
}

Props

PropTypeDefaultDescription
badge{ label: string }Eyebrow above the hairline rule, rendered through Badge23
headingstringSection heading in the left column of the header
descriptionstringSupporting paragraph, right-aligned from md up
columnsColumn[][]Board columns, each with its own state and items
footnotestringCredit policy beside the closing action
button{ label: string; href: string }Closing action
classNamestringExtra classes for the outer section
ts
type State = "shipped" | "building" | "next" | "declined";

type ActionLink = {
  label: string;
  href: string;
};

type Item = {
  title: string;
  detail: string;
  meta: string;
  askedBy?: string;
};

type Column = {
  label: string;
  summary: string;
  state: State;
  items: Item[];
};

Behavior notes

  • state sits on the column, not on each item, so a column is homogeneous by design. It drives the icon and the node style, and in the declined column it also mutes every item title.
  • next and declined share the same Circle icon and node style. The difference between them is the column label and the muted titles, which is deliberate: a declined item should read as closed rather than as a different kind of pending.
  • askedBy is optional and renders in the accent, which is the one accent use in the item rows. It survives from the request through to the shipped column, which is the point of keeping it on every state.
  • The board lines are the gap, not borders: gap-px over a bg-border container with bg-card columns, and the container's overflow-hidden clips the corners so it reads as one panel.
  • Columns are flex flex-col with the item list marked flex-1, so all four columns end level regardless of how many items each holds.
  • The grid is one, two, then four across. At sm the four columns pair up, which keeps the shipped and building pair together on tablet.
  • Loader is used as a static shape rather than a spinner, so nothing animates.

More Changelog blocks

View all Changelog
PRO

changelog20

Roadmap Status Changelog

Hybrid roadmap and changelog with shipped, in-progress, and planned items. Includes status dots, tags, and optional feature images.

PRO

changelog11

Two-Column Date Changelog

Minimal two-column layout with fixed-width date column on the left and version heading with change list on the right.

PRO

changelog9

Release Card Grid

Responsive card grid of releases with version badges, descriptions, and optional links. Great for browsable release archives.

PRO

changelog21

Kanban Board Changelog

Three-column kanban board grouping changes by type — Features, Fixes, and Improvements — with stacked cards.

PRO

changelog16

Visual Release Notes

Alternating split layout with feature screenshots on one side and release content on the other. Ideal for marketing-focused product update pages.

PRO

changelog4

Grouped Changelog Board

Month-grouped changelog board with aligned labels, release details, and optional links.