Welcome to Church Fuel Labs

Our internal platform for managing development requests, church onboarding, and team workflows. Here's how to get started.

How It Works

1

Submit a Request

Use the Submit Portal to send in bugs, feature ideas, improvements, or special requests. Include as much detail as possible — screenshots help!

2

Ember Scores & Categorizes

Ember reads your request and suggests an ICE score (Impact, Confidence, Ease), a category, effort estimate, and tags.

3

Team Triages

The dev team reviews the AI suggestions, adjusts scores if needed, sets priority, and assigns the work to a sprint.

4

Work Gets Done

Items move through In Progress and Testing. You'll get notified when your request ships.

Request Types

Not sure which to pick? Is it broken? → Bug. Something new? → Feature. Make it better? → Improvement.

Bug

Something is broken or not working as expected

Feature

Something entirely new that doesn't exist today

Improvement

Something exists but needs to work better

Special Request

Webhooks, integrations, custom work

Status Flow

Every request moves through these stages from left to right.

Inbox

Received, not yet reviewed

Backlog

Reviewed, waiting for sprint

In Progress

Actively being worked on

Testing

Built, being verified

Done

Shipped and verified

ICE Scoring

We use ICE scores to prioritize objectively instead of relying on gut feelings. Each request gets three scores (1-10) that multiply together.

Impact

How many people does this affect? How much does it matter?

Confidence

How well-defined is the request? Do we know what to build?

Ease

How straightforward is it to implement? Less effort = higher score.

500-1000: Critical300-499: High150-299: Medium50-149: Low<50: Minimal

Sprint Rhythm

We work in 2-week sprint cycles, Monday to Friday. Each sprint has a capacity target of 80 hours across the team.

During triage, requests get assigned to upcoming sprints based on priority, ICE score, and available capacity. If a sprint is full, your request moves to the next one.

Items that aren't completed by sprint end automatically return to the backlog for re-prioritization.

Definition of Done

Nothing ships until all five checks are complete. This keeps quality high.

Requirements met — does it do what was asked?
Code reviewed — a second pair of eyes checked it
Tested — verified in a real environment
Documented — notes, screenshots, or changelog updated
Stakeholder approved — requester confirmed it works

Tips for Great Requests

Be specific. “The calendar page is broken” is hard to act on. “Calendar booking page shows a blank white screen after clicking Submit on Chrome” is perfect.

Attach screenshots. A picture of the problem is worth a thousand words in a bug report.

Explain the “why”. Help us understand the problem you're solving, not just the solution you're imagining. Sometimes there's a simpler path.

Mark blockers. If something is actively preventing you or a church from doing their work, check “This is blocking critical work” and it auto-escalates to critical priority.