DecisionBee
DecisionBee was a developer-tool experiment around RFC-style decision workflows. The founder shipped quickly, then stopped after customer conversations showed target users were not dissatisfied enough with existing tools.
View original storyProduct snapshot
What it was
A dedicated tool for writing, sharing, and managing engineering RFCs and technical decisions.
Who it was for
Problem / value
Give teams a more focused RFC workflow than general documents or issue trackers.
Core workflow
Teams wrote RFCs, discussed technical options, and managed engineering decisions in a dedicated workflow.
Core dependency
In comments, the founder said teams he interviewed were happy with Google Docs or GitHub/GitLab for RFCs.
Product form
Competitors or alternatives
What happened
Summary
The founder started DecisionBee because he could not find a tool dedicated to engineering RFCs.
Outcome
The founder said he shut down after about one month because the problem was not important for target customers.
Core risk
Weak Switching Motivation
Before you build
Why it matters
DecisionBee was a developer-tool experiment around RFC-style decision workflows. The useful pre-build question is whether engineering teams, tech leads, and product-engineering groups using RFCs will repeatedly use and pay for write and review engineering RFCs and Track technical decisions outside general documents or issue trackers through a channel you can keep reaching.
Primary check
Test whether engineering teams will switch away from Docs, GitHub, or GitLab before investing in a dedicated RFC tool.
Checklist
- Who owns the budget for this problem?
- What repeated event triggers the buyer to use this every week or month?
- Which channel reliably reaches engineering teams, tech leads, and product-engineering groups using RFCs without a one-off launch spike?
- What evidence would show Weak Switching Motivation before you build more?
- Define which segment among engineering teams, tech leads, and product-engineering groups using RFCs pays first and why the problem is urgent now.
- Prove the workflow happens often enough to justify buying.
- Test one acquisition channel for engineering teams, tech leads, and product-engineering groups using RFCs before relying on launch traffic.
- Write down why a buyer would switch from Google Docs, GitHub issues, and GitLab.
Relevant if
- You are building a web app for engineering teams, tech leads, and product-engineering groups using RFCs.
- The main value is specific: Give teams a more focused RFC workflow than general documents or issue trackers.
- You have interest, signups, usage, or founder confidence but have not proven paid repeat use.
- Your acquisition or product value depends on a platform, search channel, API, or third-party system you do not fully control.
Less relevant if
- You already have paying engineering teams, tech leads, and product-engineering groups using RFCs who repeatedly use the workflow and renew or expand usage.
- The product is an internal tool with a mandated user base and no external go-to-market risk.
Pre-build tests
- Run the workflow manually for a small group of engineering teams, tech leads, and product-engineering groups using RFCs.
- Ask one buyer to pay, renew, or sign a dated pilot before building the next version.
- Test one non-launch acquisition channel and count qualified conversations, not page views.
- Put the offer next to Google Docs, GitHub issues, and GitLab and ask what would make the buyer switch now.
Transferable lessons
- Validate whether engineering teams will pay for the workflow, not only say it sounds useful.
- Treat Weak Switching Motivation as the first assumption to test.
- Compare the product against Google Docs, GitHub issues, and GitLab before adding more features.