Before You Build
Web AppShut Down

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 story

Product snapshot

What it was

A dedicated tool for writing, sharing, and managing engineering RFCs and technical decisions.

Who it was for

engineering teamstech leadsproduct-engineering groups using RFCs

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

web appdeveloper workflow tool

Competitors or alternatives

Google DocsGitHub issuesGitLabNotioninternal RFC templates

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 is a fast-validation case for developer tools: the founder found a real workflow, shipped quickly, then stopped after customer conversations showed the target users were not dissatisfied enough with existing RFC tools.

Primary check

Test whether engineering teams will switch away from Docs, GitHub, or GitLab before investing in a dedicated RFC tool.

Checklist

  • Can you name the first buyer segment and the repeated job they need solved?
  • Can you reach that segment without relying on one fragile channel?
  • What happens if the platform, API, or data source changes terms or blocks access?
  • What evidence would disprove the weak switching motivation risk?

Relevant if

  • You are building a similar web app with public-source distribution risk.
  • Your product depends on another platform, search channel, API, or third-party data source.
  • You need to validate who will repeatedly pay before investing in product polish.

Less relevant if

  • You already control a reliable acquisition channel for the exact buyer segment.
  • The product is an internal tool with no need for public distribution.

Pre-build tests

  • Run a landing-page or concierge test with the narrowest buyer segment before building the full workflow.
  • Ask users to commit to a paid pilot, not only to join a free waitlist.
  • Prototype the highest-risk platform or data dependency first and document backup options.