Coach Pulse × Featurebase: How We Track, Approve, and Ship Every Change

The idea behind it

Now that Coach Pulse is live, every change to the platform needs three things: a place where everyone can see it, a clear approval trail, and a predictable rhythm for shipping. Previously, updates moved through chat messages and one-off conversations — which made it unclear what was in production, what was still in QA, and who had signed off on what. Chat also expires after thirty days, which is a problem from an audit perspective.

Featurebase is our answer. It is a lightweight portal — the same idea as Jira, but sized for our team — that acts as a live feed of everything moving toward production. Anything being built for Coach Pulse appears here, moves through a visible pipeline of statuses, and lands in a changelog that becomes the formal summary sent before anything is pushed to production. If you want to know what's shipping, what's in testing, or what's waiting on approval, you look in one place.

The pipeline: how an idea becomes a production change

Every piece of work is a card on the board, and every card carries a status. The statuses aren't labels — they are the actual sequence a change moves through, and each one tells you who holds the ball.

1. In Review — Every new idea or request starts here. This is where something is a discussion, not yet a commitment. From here it is either approved or rejected.

2. Planned, but No Date — Approved and in the backlog. We've agreed it's worth building; it hasn't been scheduled into a week yet.

3. Planned, With Date — Scheduled. This item has been pulled into an upcoming build week.

4. DEV/QA: Code has been deployed. QA — The work is built and deployed to the QA environment. This is the handoff point for testing.

5. DEV/QA: Code has been approved By Tapestry: Shanelle And Sarah — QA and UAT are done and the Coach/Tapestry team has signed off. Nothing moves past this point without that approval.

6. Submitted to CAB — The approved change is in front of the Change Advisory Board. Once CAB confirms, we hold until the production push is executed.

7. Completed And Live In Production — Pushed, verified working in production, done. Once confirmed live and working, an item leaves the active pipeline.

Rejected — Items that won't proceed, kept visible so decisions aren't relitigated.

Clicking into any card shows its full description and history, and approvers can move a card forward directly from it. Notifications can be set up so that when items reach the QA stage, the people who need to test are pinged automatically.

The weekly rhythm

Monday — Release meeting. We lock what ships this week: anything that has finished dev, QA, and UAT is confirmed and prepared for CAB submission, and we align on what's being built during the week ahead.

Monday–Thursday — Build days. Work is developed and deployed into dev and QA as it completes.

Thursday — Connect. Status walkthrough, blockers, and handoff of completed work for testing — typically end of day Thursday.

Friday + Monday — UAT. Everything handed off is tested, so it can be approved in Monday's release meeting and the cycle rolls forward.

Three horizons run in parallel at all times: this week's release is locked, next week's work is being built, and the backlog holds everything dated for future cycles.

The production green light

Nothing goes to production on a nod in chat. When a release is ready, the changelog is compiled into a summary document of every change — what was built, tested, and approved. That summary is sent by email, so there is a permanent record. Only then does Tapestry engineering receive the green light to push to production. Once the push is verified working, items are marked Completed And Live In Production and the release is closed.

The email step exists because chat history expires, and a production release needs an audit trail that doesn't. Nothing should appear in production that hasn't gone through this sequence.

What this gives each of us

For the Coach/Tapestry team: one live view of everything in flight, a clear signal when it's your turn to test, and a formal record of what you approved and when.

For FutureProof: a structured intake for every request — new ideas land in In Review rather than arriving as exceptions — and a changelog that writes the release summary for us.

For the program: an audit trail from idea to production for every single change, and a weekly rhythm everyone can plan around.

If you'd like anything added to the board — a request, an idea, a fix — post it, and it enters the pipeline at In Review like everything else.