devtools-business-model

{
  "skill_name": "devtools-business-model",
  "evals": [
    {
      "id": 1,
      "prompt": "I'm the founder of Trellisway. We maintain an Apache-2.0 workflow engine: teams write DAGs in Python, our server schedules and retries them, keeps run history, ships a web UI. Opt-in telemetry says roughly 9,400 self-hosted installs, 58% of them inside companies. There are five of us, 14 months of runway, and revenue is exactly zero. Two of us came out of SRE; nobody here has ever sold anything in their life. We need to turn this into an actual business. What's the move?",
      "expected_output": "A constraint statement, an explicit pass over the archetype space with each rejection carrying a blocking reason, a stated efficiency ranking, two or three candidate models each with a dated validation experiment, and a single recommended primary with its go-to-market consequence.",
      "files": [],
      "expectations": [
        "States the licence position as a fixed constraint before proposing any model, noting that the Apache-2.0 releases already published stay licensed that way permanently",
        "States where the software runs today (customer-side, self-hosted) as a fixed constraint",
        "States who would sign the contract, distinguishing the DAG author from the engineering or platform leader who buys",
        "Walks the archetype space and marks options as possible, blocked, or premature instead of jumping straight to a single answer",
        "Rejects dual licensing and names the permissive Apache-2.0 licence, which creates no forcing function, as the blocking constraint",
        "Rejects an ecosystem take-rate and names the absence of two-sided liquidity as the blocking constraint",
        "Presents two or three candidate models, never only one",
        "States the ranking order explicitly in the text rather than leaving it implied by the order candidates happen to be listed in",
        "Ranks candidates by value returned per unit of founder effort rather than by which is cheapest or easiest to start",
        "Gives each candidate a validation experiment carrying both a named success criterion and a date",
        "Commits to exactly one primary model with at most one secondary, and never leaves two primaries standing",
        "Names the go-to-market consequence of the recommended model: the motion it forces and the functions that must be built or hired"
      ]
    },
    {
      "id": 2,
      "prompt": "Sanity check on our paid tier before we announce it. Nuvexa is an MIT-licensed feature-flag server; about 2,000 organizations self-host it. We're putting the following behind the Enterprise plan: SAML/SSO login, role-based access control, audit logging, the Kubernetes operator (which honestly was written by a contributor at a bank, not by us), and bulk CSV export of flag history. Everything else stays free exactly as it is. Does that boundary hold?",
      "expected_output": "A rewritten boundary that removes SSO, the community-built operator and data export from the paid side while keeping the governance surface, with all five paid-boundary tests answered in writing and any failure treated as blocking.",
      "files": [],
      "expectations": [
        "Removes SAML/SSO from the paid side and refuses to treat it as an acceptable enterprise gate",
        "Cites sso.tax or the sso-wall-of-shame catalogue, or its argument that security should not be a premium feature, when rejecting paid SSO",
        "Removes the community-contributed Kubernetes operator from the paid side",
        "Names the hostile fork as the consequence of selling contributors their own work back to them",
        "Removes bulk CSV export of flag history from the paid side because data export must not be gated",
        "Keeps role-based access control and audit logging as legitimate organization-only paid surface",
        "Applies the organization-only test: everything paid must be something a company needs and a solo developer does not",
        "Applies the defensibility test by asking whether a motivated contributor could rebuild the paid part upstream in a weekend and would want to",
        "Applies the observable-trigger test and names a concrete, visible signal that a user has crossed from free need to paid need",
        "Applies the cost-to-serve test and asks what one free user costs per month in currency",
        "Applies the licence-compatibility test against the MIT licence already published",
        "Treats a failed test as blocking rather than as a weakness to be offset by strengths elsewhere",
        "Answers the five tests in writing, one by one, rather than closing with an overall impression of the boundary"
      ]
    },
    {
      "id": 3,
      "prompt": "Can you fill in a business model canvas for us? The product is Lanternctl, a Go CLI for managing edge device fleets, BSD-licensed, public for two years. Just do the nine boxes please: key partners, key activities, value propositions, customer relationships, customer segments, key resources, channels, cost structure, revenue streams. I'm taking it to the board on Thursday.",
      "expected_output": "A refusal of the canvas as the first deliverable, naming the three inputs it never asks for, followed by the constraint, archetype and paid-boundary work, with the canvas offered afterwards if still wanted.",
      "files": [],
      "expectations": [
        "Declines to fill the nine boxes as the first deliverable and explains why before producing anything",
        "Names the licence already published as something the canvas never asks about",
        "Names where the software runs as a second input the canvas leaves out",
        "Names whether any paid boundary can hold as a third input the canvas leaves out",
        "Runs the constraint, archetype-space and paid-boundary work in place of the canvas",
        "Treats the BSD licence on already-released versions as permanent and unchangeable",
        "Offers to produce the canvas afterwards if the user still wants it, rather than refusing outright",
        "Does not invent revenue-stream figures or customer-segment sizes in order to populate boxes",
        "Asks about the buyer and the deployment reality instead of assuming them"
      ]
    },
    {
      "id": 4,
      "prompt": "I need a number from you. Kestrelbase sells an observability agent. The free open-source agent is everywhere, and the paid tier unlocks multi-tenant RBAC, retention policies and SOC 2 compliance reporting. We list it at $39 per seat per month with a Stripe checkout right on the pricing page. At what annual contract value should we stop doing self-serve and hire an inside sales rep, and at what number do we need a real field sales team? Give me the thresholds.",
      "expected_output": "A refusal to invent currency thresholds, a unit-economics model of the sale with the Skok reference points attributed and labelled SaaS-wide, and identification of the enterprise-boundary-priced-as-self-serve mismatch with its two fixes.",
      "files": [],
      "expectations": [
        "Refuses to give currency thresholds separating self-serve from inside sales from field sales, and says no defensible published bands exist",
        "Offers to derive the answer from the company's own cohort data instead of a published band",
        "Models the sale with unit economics: estimated lifetime value against estimated acquisition cost, plus the months needed to earn the acquisition cost back",
        "Quotes the lifetime-value-to-acquisition-cost guideline of higher than 3, and as high as 7 or 8 in the best businesses",
        "Quotes the guideline that acquisition cost is recovered in 5-7 months",
        "Attributes both reference points to David Skok's SaaS Metrics 2.0",
        "Labels both reference points as describing SaaS generally rather than developer tools specifically",
        "Identifies the mismatch between a paid boundary that only triggers at enterprise governance needs and a self-serve credit-card motion",
        "Explains that the cost of a sale carrying security review, procurement and legal eats a per-seat contract of this size",
        "Offers both fixes: move the boundary down so a small team crosses it, or price and staff for the sale the boundary actually requires",
        "Treats a candidate that cannot plausibly reach those reference points as a motion problem to fix before committing, not as a revenue forecast"
      ]
    },
    {
      "id": 5,
      "prompt": "Halyard is our Apache-2.0 distributed queue. Two weeks ago a major cloud provider launched 'Managed Halyard': same API, their console, their pricing, and their sales team is already sitting in two of our biggest users' accounts. The board wants us to ship the next release under BUSL-1.1 and put out a blog post announcing our new open source licence. What do we do?",
      "expected_output": "Treatment of the licence change as an irreversible lever sequenced on the reversibility ladder, corrected naming discipline, documented precedent, and a requirement to name the model the licence protects and to run the reversible experiment first.",
      "files": [],
      "expectations": [
        "Treats a licence change on published code as effectively irreversible and separates it from the reversible decisions",
        "States that every Apache-2.0 release already published stays licensed that way forever, whatever the next release ships under",
        "Refuses to call BUSL-1.1 open source and supplies source-available, fair source or delayed open source as the correct term",
        "Cites the OSI ruling that SSPL violates the Open Source Definition, or Bruce Perens' objection to restrictive licences being called open source, when explaining the naming discipline",
        "Cites at least one documented relicensing outcome by name: Elasticsearch and the OpenSearch fork, Redis and the Valkey fork, or HashiCorp and the OpenTofu fork",
        "Notes that every documented relicensing has produced a fork, a trust cost, or both",
        "Places the source-available decision on the reversibility ladder rather than ranking it as a tenth peer archetype",
        "States that source-available creates no buyer of its own and only protects whichever model sits underneath it",
        "Requires the model the licence change is meant to protect to be named and chosen before the licence moves",
        "Runs the reversible experiment first to buy evidence before pulling the irreversible lever",
        "Names contributor count and downstream packaging status as what to watch in the quarters after a change",
        "Names the distributions, foundations, corporate allowlists or procurement processes that exclude non-OSI licences"
      ]
    },
    {
      "id": 6,
      "prompt": "Two of us just went full time on Pipesmith, an MIT-licensed data-transform library with about 400,000 monthly downloads. Here's the revenue plan: GitHub Sponsors with $5, $25 and $100 tiers, a $6/month 'Pipesmith Pro' badge for individual developers who want to support us, and we'll take consulting gigs implementing Pipesmith at companies when they come in. Sanity check the plan, anything we're missing?",
      "expected_output": "A verdict that none of the three lines is a company model, with donations routed to funding-side guidance, consulting allowed only as a bridge, individuals recast as the adoption base, and at least one archetype proposed that an organization would actually sign.",
      "files": [],
      "expectations": [
        "States that sponsorship and donations sustain maintainers rather than payroll, and are not a company revenue model",
        "Routes the sponsorship question to dedicated funding-side guidance instead of counting sponsor income as revenue in the model",
        "States that consulting and implementation services cap growth at hiring speed",
        "Allows consulting as a bridge while rejecting it as a destination",
        "Treats individual developers as the adoption and credibility base rather than the revenue base",
        "Notes that individuals pay small amounts for convenience and churn fast",
        "Names organizations as the revenue base and what they actually buy: risk removal, uptime, support, compliance, control, someone to call",
        "Proposes at least one archetype monetizing an organization that signs, instead of only repackaging the individual tiers",
        "Names the buyer inside that organization and what would make them sign",
        "Names the moment a user acquires a reason to pay, rather than assuming goodwill converts into revenue"
      ]
    },
    {
      "id": 7,
      "prompt": "Context on Ferrolane before you answer. Our engine is AGPL-3.0 and every contributor has signed our CLA since day one, so we own the copyright outright. Three of our four engineers are ex-SRE and we already run a small hosted instance for two design partners. The board wants a signed paying customer before the quarter closes, so twelve weeks. We have nobody who could build metering and billing this year, and no support rota at all. Give me the model ranking.",
      "expected_output": "A ranking re-ranked against this company's specific advantages and constraints, with dual licensing promoted for the AGPL-plus-CLA prerequisite, hosted models promoted for the existing operations function, four archetypes deleted with named reasons, and each move traced to the answer that caused it.",
      "files": [],
      "expectations": [
        "Re-ranks the default order against this company's own situation instead of presenting a generic ordering",
        "Promotes dual licensing toward the top and names AGPL-3.0 plus full copyright ownership under a signed CLA as the reason",
        "Promotes hosted models because the team already operates a service, so the expensive function is already paid for",
        "Deletes consumption metering and names the absence of billing engineering as the cause",
        "Deletes support and LTS and names the absence of a support rota as the cause",
        "Deletes embedded OEM licensing because it cannot produce revenue inside a twelve-week window",
        "Deletes the ecosystem take-rate because it cannot produce revenue inside a twelve-week window",
        "Deletes ruled-out options outright rather than parking them lower in the ranking",
        "States which answer moved which option, instead of presenting the re-ranked order without its reasons",
        "Warns that the ordering is a default rather than a law",
        "Names a commercial-licence enquiry page with counted inbound as the cheap validation test for dual licensing"
      ]
    },
    {
      "id": 8,
      "prompt": "Quick one on Braidmark, our schema-migration service. We bill $30 per developer seat per month. The problem: seat count has been flat for three quarters while API calls tripled, mostly because customers wired us into CI and into coding agents that open migrations automatically. Finance wants to add a per-API-call charge on top of the seat price, same accounts, keep both. Thoughts?",
      "expected_output": "A diagnosis that seats collapse under automation, a refusal to stack consumption on top of seats for the same value, the four value-metric checks applied to a replacement metric, and consumption guardrails plus the right leading indicator.",
      "files": [],
      "expectations": [
        "States that per-seat pricing collapses when usage grows through automation and agents instead of headcount",
        "Rejects stacking a consumption charge and seats on the same underlying value",
        "Explains that billing both makes the customer optimise against the vendor",
        "Tests any candidate metric against whether the customer already counts it for their own reasons",
        "Tests whether the metric grows as the value the customer receives grows",
        "Tests whether the customer can forecast the metric before the invoice arrives",
        "Tests whether the vendor can measure the metric accurately and explain the measurement in one sentence",
        "Rejects a metric only the vendor can measure, because it turns every invoice into a dispute",
        "Requires spend caps, alerts or forecasting before any consumption billing ships",
        "Names bill shock as the failure mode consumption billing dies of, and public posts from a developer audience as how it surfaces",
        "Names net revenue retention, or the share of accounts above a committed floor, as the leading indicator for a metered model"
      ]
    },
    {
      "id": 9,
      "prompt": "An investor asked about our free tier last week and I fumbled it badly. Cindersync is a hosted sync service for mobile apps. The free plan gives 50 GB of stored data, unlimited devices and unlimited bandwidth, which we think is pretty generous, and it is genuinely driving all of our signups. Paid starts at $99/month. How do I defend the free tier next time someone asks?",
      "expected_output": "A requirement to quantify the marginal cost of a free user in currency, identification of the infrastructure-heavy free surfaces, caps on those dimensions, and the verdict that a cost-to-serve failure means the wrong value metric.",
      "files": [],
      "expectations": [
        "Requires the marginal cost of one free user to be computed in currency rather than described as generous",
        "States that a free tier described in adjectives rather than numbers is an untested model",
        "Identifies unlimited bandwidth and 50 GB of stored data as infrastructure-heavy free surface that makes growth actively expensive",
        "Notes that heavy per-user infrastructure cost rules out generous free tiers of any kind",
        "Recommends caps, quotas or metering on the infrastructure-heavy dimensions",
        "Also asks what one paying customer costs to serve, not only the free user",
        "Treats a model failing the cost-to-serve check as having the wrong value metric rather than needing more discipline",
        "Requires the free-versus-paid line to be defensible on organization-only grounds rather than on volume alone",
        "Reports the cost-to-serve result inside an explicit threshold check rather than as a passing remark"
      ]
    },
    {
      "id": 10,
      "prompt": "We've picked our model. Runnelgraph stays fully Apache-2.0 and we sell the managed service around it. Now I want the internal one-pager so the team can execute without me in the room. We'll track MRR and GitHub stars monthly so we know it's working, and for the risk section I have competition, execution and market timing. Write it up properly please.",
      "expected_output": "A memo with the named sections, MRR and stars replaced by an indicator upstream of revenue with a target, a date and a margin guardrail, each risk given an observable signal, at least three revisit triggers including a failure condition, and section-by-section agreement rather than a single dump.",
      "files": [],
      "expectations": [
        "Rejects monthly recurring revenue as a leading indicator because revenue is the outcome rather than something upstream of it",
        "Rejects GitHub stars because they measure attention that no model converts",
        "Replaces them with self-host-to-cloud conversion, or another indicator that sits upstream of the money and is readable on a stated cadence",
        "Names gross margin per workload as the guardrail tracked beside it for a hosted open-source model",
        "Attaches a target and a date to the leading indicator",
        "Rejects competition, execution and market timing as risks because none of them carries an observable signal",
        "Gives each risk a named signal with a threshold and the place it is read",
        "Produces the memo with its named sections: constraints, rejected models, primary model, paid boundary, value metric, go-to-market consequence, leading indicator, risks, revisit triggers",
        "Includes at least three revisit triggers, at least one of which is a failure condition",
        "Presents the memo section by section and seeks agreement before continuing, instead of delivering all nine sections at once"
      ]
    },
    {
      "id": 11,
      "prompt": "Just tell me which business model to run. Glintpad is a single-binary MIT-licensed CLI that tidies up local photo libraries. It runs entirely on the user's laptop, never touches the network, and stores nothing of ours anywhere. Our users are hobbyists; in three years not one company has ever contacted us. We will never change the licence, we've promised that publicly. There's no plugin ecosystem, nobody here could sell anything to anyone, and there is nothing we could meter even if we wanted to. Which model is the right one?",
      "expected_output": "A plain statement that these constraints eliminate every archetype, each elimination carrying its blocking constraint, the conclusion that either a constraint is wrong or this is not a business yet, and no invented model to fill the gap.",
      "files": [],
      "expectations": [
        "Says plainly that the stated constraints eliminate every archetype, instead of forcing one to fit",
        "States that this means either one of the constraints is wrong or the product is not a business yet",
        "Eliminates hosted SaaS and hosted open source because nothing runs on the vendor's infrastructure and there is no operational burden to sell",
        "Eliminates dual licensing because the permissive MIT licence provides no forcing function",
        "Eliminates source-available because the licence change is refused and no reseller threat exists",
        "Eliminates consumption metering because nothing is meterable",
        "Eliminates the ecosystem take-rate because no third-party ecosystem exists",
        "Eliminates open core, support and LTS, and OEM licensing because no organization is present to sign anything",
        "Names which specific constraint would have to change for any model to become available",
        "Does not invent a revenue model or recommend a hopeful one in spite of the eliminations"
      ]
    },
    {
      "id": 12,
      "prompt": "Different question from my usual ones. Stonecourse is a platform: there's the open agent that runs on customer machines, a control plane we host, a web console, and about 30 connectors, of which we wrote 11 and the community wrote the rest. Our community keeps asking what will always be free and we keep dodging the question because we haven't settled the money side yet. What do I tell them?",
      "expected_output": "An explicit always-free list produced now rather than deferred, the 19 community connectors placed on the free side, the stack mapped layer by layer with Wardley mapping attributed, the chargeable layer identified, and the promise treated as irreversible.",
      "files": [],
      "expectations": [
        "Produces an explicit always-free list now rather than deferring it until the revenue model is settled",
        "States that silence about what stays free is read as intent to close, and that the community prices that in immediately",
        "Places the 19 community-written connectors on the always-free side",
        "Maps the stack layer by layer instead of answering at the level of the whole product",
        "Applies Wardley mapping because the product spans several layers",
        "Attributes Wardley mapping to Simon Wardley, created at Fotango in 2005",
        "Describes Wardley mapping as positioning components on a value chain against an evolution axis",
        "Locates the money one layer above the component everyone needs and nobody wants to own",
        "Treats a public promise about what stays free forever as effectively irreversible",
        "Identifies the hosted control plane, the layer the vendor operates, as the chargeable surface rather than gating features inside the open agent"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "How should our developer tool make money?", "should_trigger": true },
    { "query": "We have 12,000 weekly downloads and zero revenue. What now?", "should_trigger": true },
    { "query": "Should we go open core or sell a managed cloud?", "should_trigger": true },
    { "query": "Is open core the right model for us?", "should_trigger": true },
    { "query": "A cloud provider just launched a managed version of our project. Do we relicense?", "should_trigger": true },
    { "query": "What should stay free forever in our project?", "should_trigger": true },
    { "query": "Fill in a business model canvas for our CLI", "should_trigger": true },
    { "query": "Everybody deploys our server and nobody ever pays us.", "should_trigger": true },
    { "query": "What's the business model for a developer tool like ours?", "should_trigger": true },
    { "query": "How do commercial open source companies actually make money?", "should_trigger": true },
    { "query": "We need a monetization strategy for our SDK.", "should_trigger": true },
    { "query": "Should we sell support contracts or build a hosted version?", "should_trigger": true },
    { "query": "Our adoption chart is beautiful and our revenue chart is flat.", "should_trigger": true },
    { "query": "Where does the line between our free project and a paid product belong?", "should_trigger": true },
    { "query": "Is there any way to make money from an MIT-licensed library?", "should_trigger": true },
    { "query": "Should we even open source this at all, given we need revenue next year?", "should_trigger": true },
    { "query": "What do we actually sell?", "should_trigger": true },
    { "query": "Who would ever sign a contract with us?", "should_trigger": true },
    { "query": "Our investors want to understand how value capture works here.", "should_trigger": true },
    { "query": "Is dual licensing viable for us?", "should_trigger": true },
    { "query": "Does an AGPL plus CLA setup let us sell commercial licences as a business?", "should_trigger": true },
    { "query": "We're thinking about taking a cut of third-party plugin sales. Good idea?", "should_trigger": true },
    { "query": "Should we license our engine to other vendors to embed in their products?", "should_trigger": true },
    { "query": "Can donations be the revenue model for a company, not just a maintainer?", "should_trigger": true },
    { "query": "How do we turn 400k monthly downloads into a company?", "should_trigger": true },
    { "query": "Our CLI is free and we can't work out what the paid thing would even be.", "should_trigger": true },
    { "query": "Two years in, no revenue. Talk me through the options.", "should_trigger": true },
    { "query": "Which revenue model fits a self-hosted developer platform?", "should_trigger": true },
    { "query": "Managed cloud versus an enterprise support subscription, which one?", "should_trigger": true },
    { "query": "A hyperscaler is reselling our software. What's the commercial answer?", "should_trigger": true },
    { "query": "How should we capture value from our open-source project?", "should_trigger": true },
    { "query": "We built the thing everyone uses and we're broke.", "should_trigger": true },
    { "query": "What's a defensible paid boundary for an open-core product?", "should_trigger": true },
    { "query": "Board wants a revenue plan for our developer tool by Friday.", "should_trigger": true },
    { "query": "Should we keep the whole product open and sell operating it instead?", "should_trigger": true },
    { "query": "Explain the trade-off between open core and hosted open source.", "should_trigger": true },
    { "query": "What would we have to build or hire to run a consumption model?", "should_trigger": true },
    { "query": "Nobody here has ever computed what a free user costs us. Does that matter?", "should_trigger": true },
    { "query": "We want recurring revenue from an open-source project. Realistic?", "should_trigger": true },
    { "query": "Which of them gets the invoice, the developer or their employer?", "should_trigger": true },
    { "query": "Do we need to hire a sales team for the direction we're taking?", "should_trigger": true },
    { "query": "How do I decide what to sell before I decide what to charge?", "should_trigger": true },
    { "query": "Write me a memo I can take to the board on how this makes money.", "should_trigger": true },
    { "query": "Our devs love it and their employers have never heard of us. How does that become revenue?", "should_trigger": true },
    { "query": "Is a support subscription a real business or a trap?", "should_trigger": true },
    { "query": "What do we run if all our customers are air-gapped banks?", "should_trigger": true },
    { "query": "Anything we'd charge for, someone will just build upstream for free.", "should_trigger": true },
    { "query": "Should the hosted version be the product, or should the project be?", "should_trigger": true },
    { "query": "We're an open-source company with no idea how we're actually a company.", "should_trigger": true },
    { "query": "Talk me through commercial open source models.", "should_trigger": true },
    { "query": "How do we avoid ending up like every other project with stars and no money?", "should_trigger": true },
    { "query": "What has to be true before anyone pays us anything?", "should_trigger": true },
    { "query": "Is our project even monetizable?", "should_trigger": true },
    { "query": "Rank the ways we could make money off this.", "should_trigger": true },
    { "query": "Our engine is embedded in three other vendors' products for free. Should we fix that?", "should_trigger": true },
    { "query": "We need revenue this quarter. Which direction gets there fastest?", "should_trigger": true },
    { "query": "Should we build a cloud offering or keep selling licences?", "should_trigger": true },
    { "query": "What should we charge per seat for our API gateway?", "should_trigger": false },
    { "query": "How many tiers should our pricing page have?", "should_trigger": false },
    { "query": "Where should the free-tier request limit sit, 10k or 50k a month?", "should_trigger": false },
    { "query": "We want to raise prices 20% without a backlash. How?", "should_trigger": false },
    { "query": "Should our metered plan be billed per 1,000 requests or per GB?", "should_trigger": false },
    { "query": "Write the copy for our pricing page.", "should_trigger": false },
    { "query": "Which features belong in the enterprise column of our pricing table?", "should_trigger": false },
    { "query": "Our packaging feels wrong, can you restructure the tier ladder?", "should_trigger": false },
    { "query": "Price our new add-on against the competitor's $49 plan.", "should_trigger": false },
    { "query": "MIT or Apache-2.0 for a new Go library?", "should_trigger": false },
    { "query": "Do we need a CLA or is a DCO sign-off enough?", "should_trigger": false },
    { "query": "Which SPDX identifier and NOTICE file should we ship?", "should_trigger": false },
    { "query": "Is the GPL compatible with the dependency we just added?", "should_trigger": false },
    { "query": "What are the mechanics of relicensing: contributor consent emails, file headers, SPDX updates?", "should_trigger": false },
    { "query": "Which licence file layout do we need for a dual-licensed repo?", "should_trigger": false },
    { "query": "Which of our 40 internal repos should be public?", "should_trigger": false },
    { "query": "Who signs off internally when we open source something?", "should_trigger": false },
    { "query": "Draw the asset-by-asset open versus closed line across our platform.", "should_trigger": false },
    { "query": "What should we commit in writing to never closing, as company policy?", "should_trigger": false },
    { "query": "When should a rep contact a free-tier user?", "should_trigger": false },
    { "query": "Design our land-and-expand path inside enterprise accounts.", "should_trigger": false },
    { "query": "Our signup funnel converts badly at the activation step.", "should_trigger": false },
    { "query": "Bottom-up or top-down for our sales motion?", "should_trigger": false },
    { "query": "Write the developer-to-buyer handoff rule for our reps.", "should_trigger": false },
    { "query": "Should we open extension points so partners can build integrations?", "should_trigger": false },
    { "query": "Why does nobody build anything on our API?", "should_trigger": false },
    { "query": "Should partners build the connectors or should we?", "should_trigger": false },
    { "query": "Set up our FUNDING.yml and GitHub Sponsors tiers.", "should_trigger": false },
    { "query": "What rewards should a $500-a-month corporate sponsor get?", "should_trigger": false },
    { "query": "Why does nobody sponsor our widely used library?", "should_trigger": false },
    { "query": "Should we launch a certification program for our platform?", "should_trigger": false },
    { "query": "Design the learning path for our developer academy.", "should_trigger": false },
    { "query": "Should we join the working group for this new protocol or ship our own spec?", "should_trigger": false },
    { "query": "Which foundation should we donate the specification to?", "should_trigger": false },
    { "query": "Which awesome lists and registries should we target after launch?", "should_trigger": false },
    { "query": "How do we get onto GitHub Trending on launch day?", "should_trigger": false },
    { "query": "Plan the Show HN post for our repo.", "should_trigger": false },
    { "query": "Write our project's governance model and maintainer ladder.", "should_trigger": false },
    { "query": "How do we moderate our Discord when threads turn hostile?", "should_trigger": false },
    { "query": "Contributor onboarding takes three weeks. Fix it.", "should_trigger": false },
    { "query": "How big should our devrel team be next year?", "should_trigger": false },
    { "query": "Which devrel metrics should we report to the exec team?", "should_trigger": false },
    { "query": "Split our devrel budget across events, content and community.", "should_trigger": false },
    { "query": "Who are our developer segments and which one do we serve first?", "should_trigger": false },
    { "query": "Restructure the information architecture of our docs site.", "should_trigger": false },
    { "query": "Write the release notes for version 3.2.", "should_trigger": false },
    { "query": "Our quickstart takes 40 minutes. Shorten it.", "should_trigger": false },
    { "query": "Fill in a business model canvas for my coffee roastery.", "should_trigger": false },
    { "query": "Build a monetization strategy for my mobile game: ads or in-app purchases?", "should_trigger": false },
    { "query": "Which SaaS metrics belong on my dashboard: MRR, churn, ARPU?", "should_trigger": false },
    { "query": "Apply Crossing the Chasm to our positioning.", "should_trigger": false },
    { "query": "Set up a predictable revenue outbound SDR process.", "should_trigger": false },
    { "query": "Act as a business analyst and write requirements for this feature.", "should_trigger": false },
    { "query": "What does Azure pricing look like for twenty D4s v5 instances a month?", "should_trigger": false },
    { "query": "Model our cash runway and burn rate for the next 18 months.", "should_trigger": false },
    { "query": "Write this month's investor update email.", "should_trigger": false },
    { "query": "Draft the terms of service and DPA for our cloud product.", "should_trigger": false }
  ]
}

# Worked memo, and weak versus strong sections

The product below is fictional, so nothing here should be read as a benchmark. It exists to show the level of specificity a finished memo needs.

No real company publishes this deliberation - outcomes get announced, the reasoning behind them does not - so a fabricated-but-labelled example is the honest option. Every number in it is illustrative.

**Situation.**

- Team: five people, maintaining an Apache-2.0 workflow-orchestration server. Developers define pipelines in code, the server schedules and retries them, stores run history, and exposes a web UI.
- Adoption: roughly 4,000 self-hosted deployments send opt-in telemetry. No revenue.
- Team background: two of the founders are ex-SRE. Nobody has sold anything before.
- Runway: eighteen months.

---

## Table of Contents

- [Business model - Orchestron](#business-model-orchestron)
- [Weak versus strong sections](#weak-versus-strong-sections)

## Business model - Orchestron

### Constraints

- Licence: Apache-2.0 on everything published since the first release. The team refuses relicensing and has said so publicly.
- Deployment: the server is stateful, needs a database, and upgrades break pipelines when done carelessly - self-hosting genuinely hurts at scale.
- Buyer: telemetry shows 61% of deployments run inside companies, most of them on a single team's infrastructure. The signer is an engineering manager or platform lead, not the pipeline author.

### Rejected

- **Dual licensing** - impossible under Apache-2.0, and relicensing is refused.
- **Source-available** - no hyperscaler is reselling this; the cost would be contributors, with nothing bought.
- **Support/LTS as primary** - no enterprise footprint yet, and it caps growth at hiring speed with two engineers who would rather build.
- **Marketplace take-rate** - 19 community plugins exist; there is no market to tax.
- **OEM licensing** - nobody embeds an orchestration server, and Apache-2.0 already grants what an embedder would want.

### Primary model

Hosted open source: a managed Orchestron cloud, priced on concurrent pipeline runs. Everything in the product stays Apache-2.0; the company sells operation - upgrades, retention of run history, availability, and not being paged at 03:00 when the scheduler wedges. The prerequisite it depends on: operating it is hard enough that a platform team prefers to pay.

Telemetry supports this: 34% of company deployments are more than two minor versions behind, and the top issue label for eighteen months has been upgrade failures.

### Paid boundary

- Always free: the full server, every executor, the UI, the plugin API, all authentication methods including SSO, and every security patch.
- Paid: the hosted service only, plus retention beyond 30 days of run history on that service.

The line holds because it is not a feature line at all - nothing is withheld from the open project, so there is nothing to fork around.

### Value metric

Concurrent pipeline runs.

- Already counted: teams already size their self-hosted deployment by this number.
- Grows with value: it grows as the platform carries more of their work.
- Forecastable: it is visible in their own dashboards before the invoice arrives.
- Rejected: per-seat, because pipeline authors are a small fraction of the people who benefit and the count does not move as usage grows.

### GTM consequence

Self-serve first: sign up, point at a Git repository, run pipelines in under fifteen minutes. Expected contracts start small, so no sales hire before the first twenty paying teams.

What must be built:

- Multi-tenant isolation.
- A migration path from self-hosted state.
- Per-run metering.
- Spend caps.
- An on-call rotation the two ex-SRE founders can staff for six months and not longer.

First investments in order:

1. Metering and caps.
2. Migration tooling.
3. The third SRE.

### Leading indicator

- Primary: self-host-to-cloud conversion rate among deployments that have opted into telemetry and hit an upgrade failure in the last 90 days. Read monthly, target 3% of that cohort within two quarters of launch.
- Guardrail: gross margin per workload, tracked alongside it, with a floor of 60%.

### Risks

1. **Margin too thin.** Long-running pipelines make compute the dominant cost. Signal: gross margin per workload below 60% in any month after the third.
2. **Self-hosting is good enough.** The operational pain is real but tolerated for free. Signal: fewer than 1% of the upgrade-failure cohort converting after two quarters.
3. **Operating the service starves the project.** Releases slow, community drifts. Signal: median time-to-first-response on issues doubling from the current baseline.

### Revisit triggers

- A cloud provider announces a managed Orchestron-compatible service.
- Gross margin per workload stays below the floor for two consecutive quarters (failure condition - reopen with support/LTS as the candidate primary).
- Inbound requests for on-premises support exceed five per month, which would make support a viable secondary.
- Plugin installs pass 40% of active deployments, which would make an ecosystem model worth re-examining.

---

## Weak versus strong sections

### Paid boundary

**Weak:** "The open-source version stays fully featured; enterprise features will be added to the paid tier as we identify them."

Wrong because the boundary is deferred. "As we identify them" means:

- The community cannot tell what is safe to build.
- Contributors avoid the areas that might get taken.
- The first paid feature lands as a surprise.

A boundary that is not written is read as intent to close.

**Strong:** the section above - an explicit always-free list, a paid side that withholds nothing from the project, and a stated reason why the line survives contact with a motivated contributor.

### Value metric

**Weak:** "Usage-based pricing, based on compute consumed."

Wrong on three of the four checks:

- The customer does not count compute for their own reasons.
- Cannot forecast it before the invoice.
- Cannot verify your measurement.

Every invoice becomes a negotiation.

**Strong:** concurrent pipeline runs - a number the team already sizes their cluster with, visible in their own tooling, explainable in one sentence.

### Risks

**Weak:** "Risks: competition, execution, market timing."

Wrong because none of them has a signal, so nothing can ever be observed to be happening. A risk without a trigger is a disclaimer.

**Strong:** the three above - each with a number, a threshold and a place it is read.

### GTM consequence

**Weak:** "Open core, with SSO, RBAC and audit logging in the paid tier at $49 per user per month, sold self-serve through the website."

Wrong because the boundary and the motion contradict each other. Nothing triggers the paid tier until an organization needs governance features, and an organization buying governance features runs a security review, a procurement cycle and a legal review, none of which a self-serve checkout survives.

Model it before committing: the acquisition cost of a reviewed enterprise deal against the lifetime value of a handful of seats. David Skok's _SaaS Metrics 2.0_ puts the healthy reference at an LTV-to-CAC ratio above 3 with CAC recovered in 5-7 months. A boundary that only opens at enterprise scale, priced for a credit card, misses both by a wide margin.

Either move the boundary down so a small team crosses it, or price and staff for the sale the boundary actually requires.

**Strong:** the section above - a motion the boundary can support, a stated point at which a human enters the sale, and the investments ordered.

### Leading indicator

**Weak:** "We'll track monthly recurring revenue and GitHub stars."

Wrong because neither moves before the outcome. Revenue is the outcome, and stars measure attention that no model converts. A leading indicator has to sit upstream of the money and be readable monthly.

**Strong:** the section above - conversion of a specific, observable cohort, read on a stated cadence, with a target, a date and a margin floor beside it.

### Rejected

**Weak:** omitting the section entirely.

Wrong because the discarded options come back every quarter, argued from scratch, usually by whoever was not in the room. Writing the blocking constraint next to each rejection converts a debate into a lookup.

# Developer-tool business model archetypes

Nine ways a developer tool turns adoption into revenue. Each entry gives what is sold, the prerequisite that must be true, the economics, the go-to-market it forces, the leading indicator that moves before revenue, and the failure mode it dies of.

Company names appear as public illustrations only - never as an argument that a model fits your situation. The numbering below is a catalogue index, not a ranking: the order to work through them is the efficiency order in the skill's step 2.

## Contents

1. Proprietary hosted SaaS
2. Open core
3. Hosted open source
4. Support, LTS and certified builds
5. Dual licensing
6. Source-available / delayed open source
7. Consumption metering on a free client
8. Ecosystem take-rate
9. Embedded / OEM licensing
10. Non-models
11. Stacking rules

---

## 1. Proprietary hosted SaaS

- **Sold:** access to a vendor-operated service, priced per seat, per unit of usage, or both.
- **Prerequisite:** the product is operable as a multi-tenant service, and the buyer accepts data leaving their perimeter.
- **Economics:** software margins, provided the free surface is bounded. Cost-to-serve is the variable to watch.
- **GTM forced:** self-serve for small contracts, inside sales as contracts grow, security review at enterprise scale.
- **Leading indicator:** activation-to-paid conversion rate within the first month of signup.
- **Dies of:** commoditization by an open alternative that is 80% as good and free, and by buyers who cannot send data out.

## 2. Open core

- **Sold:** proprietary modules around an open-source core. The term was coined by Andrew Lampitt in 2008 for monetizing open-source software "to which a for-profit company provides significant development support".
- **Prerequisite:** a paid boundary built from features an organization needs and an individual does not - SSO/SAML, RBAC, audit logging, multi-cluster or multi-tenant management, compliance reporting, long-term support builds.
- **Economics:** adoption is cheap, conversion is the hard part; expect a long gap between deployment count and revenue.
- **GTM forced:** two release trains, a written open/paid boundary, and some way to learn who runs the free version (opt-in telemetry, registry signals, community presence). Pipeline generation is the bottleneck, not closing.
- **Leading indicator:** rate at which free deployments hit a paid-boundary trigger - a second team, an audit request, a second cluster.
- **Dies of:** a core good enough that nobody crosses the boundary, or a boundary drawn through something the community already built.
- **Public illustration:** GitLab's community versus enterprise editions.

## 3. Hosted open source

- **Sold:** running the fully open project for the customer - uptime, upgrades, backups, scaling, support.
- **Prerequisite:** genuine operational burden. Convenience is only worth money when self-hosting hurts; stateless single-binary tools rarely qualify.
- **Economics:** infrastructure margin, thinner than pure software. Gross margin per workload is the number that decides viability.
- **GTM forced:** an SRE-grade operations team, margin discipline, and a pitch built on time, risk and uptime rather than features - your largest competitor is your own free self-hosted option.
- **Leading indicator:** self-host-to-cloud conversion rate, and gross margin per workload.
- **Dies of:** a cloud provider offering the same managed service with better distribution and lower cost of capital.

## 4. Support, LTS and certified builds

- **Sold:** a subscription covering SLAs, security backports, certified or hardened builds, indemnification and an escalation path.
- **Prerequisite:** enterprise buyers with procurement, audit and risk requirements, plus a real support organization.
- **Economics:** revenue scales with headcount, not usage. Predictable, defensible, slow, and valued lower per unit of revenue than usage-based models.
- **GTM forced:** field sales, procurement-ready paperwork (security questionnaires, DPAs, insurance), backport engineering, on-call support tiers.
- **Leading indicator:** renewal rate, and support cost per contract.
- **Dies of:** linear scaling - every new contract needs more people.
- **Public illustration:** the Red Hat subscription model.

## 5. Dual licensing

- **Sold:** a proprietary licence exempting the buyer from copyleft obligations.
- **Prerequisite:** the vendor owns or is assigned every copyright - hence a CLA - and the obligation is genuinely painful. AGPL for server software is the classic forcing function; permissive licences make this model impossible.
- **Economics:** high margin, lumpy, legally triggered rather than value triggered.
- **GTM forced:** copyright hygiene, an inbound legal-triggered sales path, and a team comfortable holding licence-compliance conversations without becoming adversarial.
- **Leading indicator:** commercial-licence inquiries per thousand downloads.
- **Dies of:** a permissively licensed near-equivalent, or an audience that complies rather than pays.
- **Public illustration:** Qt's commercial licence alongside its LGPL/GPL offering.

## 6. Source-available / delayed open source

- **Sold:** the same product, with competing hosted use restricted by licence (BUSL, FSL, Elastic License), often converting to an open licence after a set period. The Functional Source License, created by Sentry, states the bargain plainly: "You can do anything with FSL software except undermine its producer. You can run it for almost all purposes, study it, modify it, and distribute your changes" - converting to Apache-2.0 or MIT two years after each version ships.
- **Prerequisite:** a credible hyperscaler-absorption threat that already exists. If nobody could plausibly resell your software as a service, this buys nothing and costs contributors.
- **Economics:** protects hosted revenue; costs contribution, packaging and procurement reach.
- **GTM forced:** language discipline - "source-available", "fair source", "delayed open source", never "open source" - plus a plan for the distributions, foundations and corporate allowlists that exclude non-OSI licences.
- **Leading indicator:** contributor count and downstream packaging status in the two quarters after the change.
- **Dies of:** the fork, the trust cost, or both. Every documented relicensing has produced at least one.
- **Documented outcomes:**
  - Elasticsearch moved from Apache-2.0 to SSPL plus Elastic License 2.0 in 2021 and AWS forked OpenSearch; Elastic added AGPL-3.0 back as a third option in 2024.
  - Redis moved from BSD to RSALv2 plus SSPLv1 in March 2024 and AWS and Google backed the Valkey fork; Redis added AGPLv3 in Redis 8 in May 2025, its CEO writing that the change achieved the anti-hyperscaler goal but "hurt our relationship with the Redis community".
  - HashiCorp moved from MPL-2.0 to BUSL-1.1 in August 2023, for future releases only, and OpenTofu forked under the Linux Foundation.
- **Naming discipline:** the OSI ruled that SSPL "violates the Open Source Definition", and Bruce Perens, co-author of that definition, argues restrictive provisions disqualify a licence from being called open source. Say "source-available", "fair source" or "delayed open source" instead. The correction always arrives in public otherwise.

## 7. Consumption metering on a free client

- **Sold:** a metered backend service; the SDK, CLI and client libraries are free and often open.
- **Prerequisite:** a value metric the customer already counts and can forecast - requests, messages, builds, gigabytes, active devices, tokens.
- **Economics:** revenue expands with customer success and contracts with their downturns. Net revenue retention is the headline number.
- **GTM forced:** metering and usage attribution, spend caps and alerts, forecast tooling, committed-spend contracts at the top end.
- **Leading indicator:** net revenue retention, and the share of accounts above their committed floor.
- **Dies of:** bill shock. Unpredictable invoices in a developer audience become public posts and then churn.

## 8. Ecosystem take-rate

- **Sold:** a share of third-party transactions, listings or applications built on the platform.
- **Prerequisite:** liquidity - enough buyers _and_ enough suppliers that neither side has to be recruited individually.
- **Economics:** near-zero marginal cost, very long ramp. Almost never a first model.
- **GTM forced:** supplier recruitment, listing review and quality control, payouts, dispute handling, and a two-sided growth plan.
- **Leading indicator:** share of active customers installing at least one third-party listing.
- **Dies of:** being started before the ecosystem exists, and being taxed hard enough that suppliers route around it.

## 9. Embedded / OEM licensing

- **Sold:** the right for another vendor to ship your component inside their product - per device, per instance, or as a revenue share.
- **Prerequisite:** a component that is hard to rebuild and boring to own, plus a licensing and compliance function.
- **Economics:** few deals, large, slow, with long renewal cycles and heavy negotiation.
- **GTM forced:** partner-style business development, technical due diligence support, contract and audit machinery.
- **Leading indicator:** signed evaluation agreements and design wins in the partner's release cycle.
- **Dies of:** a permissively licensed near-equivalent that removes the need to sign anything at all.

## Non-models

- **Sponsorship and donations** fund maintainers, not payroll. Treat them as sustainability instruments and route them to funding-side guidance.
- **Consulting and implementation services** buy time and customer intimacy, and cap growth at hiring speed. Legitimate as a bridge, dangerous as a destination.
- **Training and certification** are a real revenue line, rarely a primary model, and they demand their own defensibility work before anyone pays for a credential.

## Stacking rules

- Combinations that work:
  - Hosted open source plus enterprise support.
  - Open core plus hosted.
  - Consumption plus a committed-spend floor.
  - Any model plus a training line once the first one is proven.
- Combinations that fight each other:
  - Open core plus source-available (two boundaries the community must track).
  - Consumption plus seats on the same value (the customer optimises against you).
  - Marketplace take-rate plus first-party competition with your own suppliers.
- One primary, at most one secondary. A plan with two primaries is a plan where the decision has not been made.

# Model fit scorecard

Use this to eliminate archetypes fast, then to score the survivors. Fill it in writing - a test answered in conversation and never recorded is a test that gets silently re-answered later.

## Contents

1. Constraint elimination table
2. The five paid-boundary tests
3. Scoring sheet
4. Value metric checks
5. Never on the paid side
6. Reversibility ladder
7. Validation experiment per candidate

---

## 1. Constraint elimination table

Answer the three constraints from step 1, then strike out what they forbid.

| Constraint answer                                                   | Archetypes eliminated                                           | Archetypes favoured                                     |
| ------------------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------- |
| Customer must run it themselves (compliance, data gravity, air gap) | hosted SaaS, hosted open source                                 | open core, support/LTS, dual licensing, OEM             |
| You operate it and customers accept that                            | -                                                               | hosted SaaS, hosted open source, consumption            |
| Already published under a permissive licence                        | dual licensing (no forcing function)                            | open core, hosted open source, support/LTS              |
| Already published under strong copyleft you own entirely            | -                                                               | dual licensing, open core                               |
| No copyright ownership (community-owned, DCO only, foundation)      | dual licensing, source-available                                | hosted open source, support/LTS, consumption            |
| Nothing published, no intention to open anything                    | open core, hosted open source, dual licensing, source-available | hosted SaaS, consumption, OEM                           |
| No credible hyperscaler-absorption threat                           | source-available                                                | any open model                                          |
| No sales capacity and none planned                                  | support/LTS, OEM, dual licensing                                | hosted SaaS, consumption, hosted open source            |
| Near-zero cost to serve a user                                      | hosted open source (nothing to sell)                            | consumption is weak here; seats or open core fit better |
| Heavy per-user infrastructure cost                                  | generous free tiers of any kind                                 | consumption, hosted models with caps                    |
| No ecosystem of third-party builders                                | ecosystem take-rate                                             | revisit after platform adoption                         |
| Individual developers only, no organizations                        | open core, support/LTS, dual licensing, OEM                     | hosted convenience tiers, small consumption plans       |

A constraint that eliminates every archetype means one of the constraints is wrong or the product is not a business yet. Say so rather than forcing a fit.

## 2. The five paid-boundary tests

Per surviving candidate, answer yes or no, with one line of evidence each. A "no" on any of the five is a blocking failure, not a weakness to compensate elsewhere.

1. **Organization-only.** Is everything on the paid side something a company needs and a solo developer does not? Governance, scale management, guaranteed response, compliance evidence, hosted operation. Anything an individual also wants gets rebuilt upstream.
2. **Defensible without hostility.** Could a motivated contributor build the paid part upstream in a weekend, and would they want to? A boundary that only holds because you refuse pull requests is a fork with a start date.
3. **Observable trigger.** Can someone see the crossing from free need to paid need - a second team, a production deployment, an audit request, a volume threshold, a support escalation? Name the signal and where it is read.
4. **Cost-to-serve covered.** What does one free user cost per month, in currency? What does one paying customer cost? If the free number is unknown, the model is untested.
5. **Licence-compatible.** Does this work with what is already published, with no relicensing? If it needs one, treat it as a separate, irreversible decision with its own approval.

## 3. Scoring sheet

Once a candidate passes all five gates, score it 1-5 on each dimension. Scores never rescue a failed gate, and the total is not the order:

- Value half of the efficiency ratio: willingness to pay, margin, defensibility, expansion.
- Effort-and-cost half: time to first revenue, team fit, community cost.

The ratio is what re-ranks the default order in the skill's step 2 for this specific company. A high total carried by four value dimensions and one on team fit is an expensive model wearing a good score.

| Dimension             | 1                                                        | 5                                                          |
| --------------------- | -------------------------------------------------------- | ---------------------------------------------------------- |
| Willingness to pay    | buyer must be convinced the problem exists               | buyer already budgets for this category                    |
| Time to first revenue | multi-quarter enterprise cycle                           | self-serve within days                                     |
| Margin                | resells infrastructure at thin markup                    | software margin                                            |
| Defensibility         | a permissive competitor removes the need to pay          | switching means re-architecting or losing compliance cover |
| Team fit              | requires a function you do not have and cannot hire soon | uses strengths already on the team                         |
| Community cost        | erodes trust or invites a fork                           | community is neutral or benefits                           |
| Expansion             | flat revenue per customer forever                        | revenue grows as the customer succeeds                     |

Record the two lowest scores as the risks that go into the memo. A candidate winning on total while scoring 1 on team fit is a plan to hire, not a plan to sell.

## 4. Value metric checks

The billed metric should satisfy all four:

- The customer already counts it for their own reasons.
- It grows as the value they receive grows.
- They can forecast it before the invoice arrives.
- You can measure it accurately and explain the measurement in one sentence.

Common breakages:

- Seats on a product driven by automation or agents, where usage rises without headcount.
- Raw infrastructure units the customer cannot map to their own outcomes.
- A metric only you can measure, which turns every invoice into a dispute.

## 5. Never on the paid side

- Basic authentication hardening. Charging for it is the "SSO tax", catalogued at sso.tax (the actively maintained `robchahin/sso-wall-of-shame` list) on the argument that "security shouldn't be a premium feature" and that SSO is "a core security requirement for any company with more than five employees".
- Security patches for the free version. Withholding fixes turns users into adversaries and attracts CVE-driven press.
- Features the community contributed. The most cited cause of a hostile fork in this market.
- Data export and portability. Lock-in read as a trap is punished harder here than in any other B2B segment.

## 6. Reversibility ladder

This ladder sequences the experiments. It does not re-rank the shortlist, which the skill's efficiency order already did. Prefer the reversible experiment first.

- **Reversible in a quarter:** price points, packaging, free-tier limits, adding a hosted option, adding a support tier at the top.
- **Reversible with effort and cost:** opening a previously closed component, entering a cloud marketplace, restructuring the value metric on existing contracts.
- **Effectively irreversible:** any licence change on already-published code, closing a previously open core, and any public promise about what stays free forever.

Irreversible levers have to be pulled early to matter at all, because everything already released stays released. Pull them deliberately, with the fork and procurement consequences written down, or do not pull them.

## 7. Validation experiment per candidate

Every candidate carried into step 2's short-list needs one cheap test with a success criterion and a date, run before the company is rebuilt around the model. Suggestions by archetype:

| Candidate          | Experiment                                                                                                                | Reads as a pass when                                                                       |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Open core          | Publish the intended boundary as a written statement and offer an early-access paid tier to the largest known deployments | a named organization asks to buy before the modules exist                                  |
| Hosted open source | Waitlist page with an indicative price and a migration promise, promoted to the self-hosting audience                     | signups convert to paid pilots, and the pilots' unit cost lands inside the intended margin |
| Support/LTS        | Sell three paid support contracts by hand at the intended annual price                                                    | all three renew intent at 90 days without custom engineering promises                      |
| Dual licensing     | Add a commercial-licence enquiry page and count inbound over a quarter                                                    | enquiries arrive unprompted from organizations that cannot comply                          |
| Consumption        | Instrument the metric and shadow-bill existing free users for one month                                                   | shadow invoices are within the users' own forecast when shown to them                      |
| Marketplace        | Recruit ten suppliers by hand                                                                                             | buyers install without the platform brokering each match                                   |

An experiment nobody can fail is not an experiment. Write the number that would make you drop the candidate, not only the one that would confirm it.

---
name: devtools-business-model
description: Chooses the business model for a developer tool - proprietary SaaS, open core, hosted open source, support and LTS subscription, dual licensing, source-available, consumption metering, marketplace take-rate, OEM licensing - and the go-to-market each one forces. Use whenever a founder or exec asks how a developer tool should make money, whether open core or a managed cloud fits better, where the line between free and paid belongs, whether to open-source the product at all, or why adoption is high and revenue flat, and on any monetization, revenue model or commercial open source question - even if they never say "business model". Not price points, packaging or free-tier limits - use samber/developer-relations-skills@devtools-pricing-strategy.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# Devtools Business Model

You are a commercial strategist for developer tools. Decide, with the founder or exec, what gets sold, who signs, and what has to be true for the money to arrive. Name the go-to-market that choice forces.

Developer tools fail at value _capture_ far more often than at value _creation_: the software gets adopted, deployed and loved, and nobody ever has a reason to sign anything. Hold every recommendation to that test, name the moment a user acquires a reason to pay, or the model is a wish.

Produce a model decision with its consequences and a validation plan, not a pricing page, not a launch plan, not a licence.

## Typical invocations

- "We have 12k weekly downloads and zero revenue, how do we monetize this?" → run the full workflow; expect the paid-boundary test to do the real work.
- "Should we go open core or sell a managed cloud?" → start at step 2 with those two as the candidate set, and still test both boundaries.
- "A cloud provider just launched a managed version of our project. Do we relicense?" → step 1 constraints, then the reversibility ladder in step 5; relicensing is a decision of its own, not a step.
- "What should stay free forever?" → step 3 alone; output the always-free list and the reasoning behind it.
- "I maintain this library alone and companies use it, how do I get paid?" → not this skill: one project's maintainers with no company behind them belong to `samber/developer-relations-skills@oss-monetization`.
- "Fill in a business model canvas for our CLI" → refuse the framing before filling anything: say what a canvas leaves out here (the licence already shipped, where the software runs, whether any boundary can hold) and run steps 1-3 instead. Produce the canvas afterwards if the user still wants one.

Whatever the entry point, the deliverable is the memo in step 6, constraints, rejections with reasons, one primary model, a paid boundary, a value metric, a GTM consequence, a leading indicator, risks with signals, revisit triggers.

## Interview

Ask one question at a time. Offer multiple-choice options where you can. Stop as soon as you can name the product surface, the buyer and the licence position; confirm the rest as you go.

**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What is the product, and what does someone install or call, a library, a CLI, a server they run, a hosted API, a platform others build on?
2. Who runs it in production: your infrastructure, the customer's, or both?
3. Is any of it open source today, under which licence, and how much of it is already published? (Anything already released stays released.)
4. Who adopts it, and who would actually sign the contract, the same developer, their engineering leader, a platform team, procurement?
5. What is the revenue today, if any, and where does it come from?
6. What does a single active user cost you to serve, roughly, near zero, or real compute/storage/egress?
7. Could a well-resourced cloud provider or competitor run your software as a competing managed service? Has anyone started?
8. What can you meter reliably today, requests, seats, builds, data volume, active devices, nothing yet?
9. What stage and what constraint: runway, headcount, existing enterprise contracts, investor expectations on growth shape?
10. By what date does revenue have to exist, this quarter, this year, before the next raise?
11. Do you want a one-off win (a first paid logo, a number for the next board meeting) or a compounding asset that is worth more every year it runs?
12. What is your effort ceiling: which functions can you actually build or hire inside a year, SRE, support rota, field sales, billing engineering, legal, and would you make a commitment you cannot walk back?
13. What is off the table: hiring a sales team, moving to a source-available licence, supporting self-hosting, or anything a public promise to the community already rules out?

Answers 10, 11 and 12 re-rank step 2's archetype menu; carry them there instead of re-asking.

- A date inside this quarter promotes the models that bill without a signature, consumption metering and hosted SaaS, and deletes embedded OEM and the marketplace take-rate, neither of which produces revenue that fast.
- A compounding mandate promotes open core and hosted open source, both worth more per customer in year three.
- An effort ceiling with no support rota deletes support and LTS.
- No SRE function deletes hosted open source.
- No billing engineering deletes consumption metering.
- A refusal to make unwalkable commitments deletes every licence change.

Record the answers. If your harness has persistent memory, store the product surface, buyer, licence position and refused options: every downstream pricing, GTM and launch decision reuses them.

## Step 1, Fix the constraints before exploring anything

Three answers eliminate archetypes before brainstorming starts, and getting them wrong invalidates everything below. State all three out loud before proposing anything.

- **The licence already shipped.** Published releases stay licensed forever. A model that needs a licence the project does not have requires relicensing, consent from every copyright holder, and a fork risk with documented precedent (see the outcomes in [references/model-archetypes.md](./references/model-archetypes.md)). Treat this as the only genuinely irreversible lever.
- **Where the software runs.** If compliance, data gravity or air-gapping forces customer-side deployment, hosted models are out, and support, licensing and open-core models are in. If you operate it, hosting is monetizable.
- **Who signs.** An individual paying by card and an organization surviving procurement buy different things. Almost every model below monetizes organizations. Individuals monetize as convenience: small amounts, fast churn.

## Step 2, Brainstorm the model space, do not jump to an answer

Enter brainstorming mode explicitly and say so.

Widen first: walk the nine archetypes in [references/model-archetypes.md](./references/model-archetypes.md) and mark each one _possible_, _blocked by a constraint_, or _premature_. Name the constraint that blocks each rejected one, a rejection with a stated reason stops the idea from being re-litigated every quarter.

When the question is really "which part of this should be free, and where does value move to", map the stack: the component everyone needs and nobody wants to own drifts toward commodity, and the money sits one layer above it. Use Wardley mapping for that reasoning, created by Simon Wardley at Fotango in 2005: it positions components on a value chain against an evolution axis.

- Apply it when the product spans several layers.
- Skip it when the product is a single component.

Rank whatever survives that pass by value returned per unit of founder effort, effort meaning the functions the model obliges you to build or hire, the standing obligations it creates, and how hard the commitment is to walk back. Say the efficiency order out loud rather than leaving it implied by row order, and lead with the top of it rather than with the cheapest row. Each line below is descending on its own axis, highest first.

- efficiency: `consumption metering > proprietary hosted SaaS > dual licensing > open core > hosted open source > support and LTS > embedded OEM > ecosystem take-rate`
- value (revenue the model reaches without adding people): `consumption metering > proprietary hosted SaaS > open core > hosted open source > ecosystem take-rate > dual licensing > embedded OEM > support and LTS`
- effort: `ecosystem take-rate > hosted open source > support and LTS > open core > embedded OEM > proprietary hosted SaaS == consumption metering > dual licensing`
- compliance cost: `dual licensing > ecosystem take-rate > support and LTS > embedded OEM > proprietary hosted SaaS == hosted open source == consumption metering > open core`

Effort in magnitudes:

- Dual licensing: near-zero engineering, wherever the CLA and full copyright ownership already exist, an enquiry page and a lawyer on call.
- Hosted SaaS and consumption metering: each about a quarter of engineering to operate, meter, cap and bill.
- Open core: a standing job of two release trains plus the telemetry to find who runs the free one.
- Support and LTS, hosted open source: standing jobs made of people, a support rota and an SRE team.
- Embedded OEM, ecosystem take-rate: standing jobs of business development, supplier operations and payouts.

Justify the effort tie: hosted SaaS and consumption metering both run a vendor-operated service and differ only in what is billed off it, neither escapes a function the other has to build.

Justify the compliance tie: hosted SaaS, hosted open source and consumption metering all hold customer data, so all three carry the same data-processing agreements, security reviews and residency questions. Open core sits lowest because the customer runs the software and nothing leaves their perimeter. Dual licensing tops the line because copyright provenance has to hold up under an adversary's lawyer.

Source-available is deliberately absent from these lines. It creates no buyer of its own, it protects whichever model sits under it, so ranking it as a peer would be false precision. Treat it as a modifier on hosted or open-core revenue, decided in step 5 with the irreversibility that goes with it.

What this order starves: hosted open source and support and LTS. Both are standing jobs made of headcount, so the ratio buries them, and both are the only way to monetize the buyers who will never send data out or never cross a feature boundary: the regulated, the air-gapped, the ones who buy assurance rather than features.

- Promote hosted open source when self-hosting genuinely hurts and the buyer accepts hosting.
- Promote support and LTS when the paid boundary can only be made of indemnification, backports and a phone number.

Delete rather than demote, and say which:

- Nothing meterable today deletes consumption metering.
- Deployment that must stay customer-side deletes hosted SaaS and hosted open source.
- A permissive licence already published, or copyright the company does not fully own, deletes dual licensing.
- No two-sided liquidity today deletes the ecosystem take-rate, which is almost never a first model anyway.

This order is a default, not a law: it shifts with context and with who executes it. Re-rank it against what you already know about this company before presenting it:

- A team that already operates a service promotes hosted models, because the expensive function is already paid for.
- An existing enterprise support organization promotes support and LTS for the same reason.
- An AGPL codebase with a signed CLA promotes dual licensing to the top, since its prerequisite is the rarest one on the page.

Then present two or three candidate models, never one, in that order. For each, cover:

- What is sold, who signs, the prerequisite that must be true, what it gives up.
- A validation experiment: the cheapest test that would show the model working before the company is rebuilt around it, with a success criterion and a date. A pricing-page test, ten qualifying conversations, a paid pilot with three deployments, or a landing page for a hosted waitlist all qualify; "wait and see how adoption goes" does not.

Close with your recommendation and the reason, and let the user pick before you detail anything further.

Refuse a business model canvas as a substitute for this step. A canvas fills nine boxes without ever asking what has already been published, where the software runs, or whether any paid boundary can hold, the three inputs that actually decide a developer tool's model.

## Step 3, Put every candidate through the paid-boundary test

A model is only as good as the line between free and paid. Test whether a boundary can hold at all: that is what makes a model viable. Answer these in writing, per candidate, using [references/model-fit-scorecard.md](./references/model-fit-scorecard.md).

Designing the asset-by-asset shape of an open/closed line is `samber/developer-relations-skills@open-source-company-strategy`'s job once the model is chosen.

1. **Organization-only?** The paid side must be something a company needs and a solo developer does not, SSO, RBAC, audit trails, multi-tenancy, compliance evidence, guaranteed response times, hosted operation. Anything an individual also wants gets rebuilt by the community.
2. **Defensible without hostility?** Could a motivated contributor build it upstream in a weekend, and would they want to? If yes, the boundary is a fork waiting for a trigger.
3. **Observable trigger?** Someone must be able to see the crossing, a second team, a production deployment, an audit request, a volume threshold. A boundary nobody can see is a boundary nobody sells against.
4. **Cost-to-serve covered?** Compute the marginal cost of a free user. Infrastructure-heavy free surfaces can make growth actively expensive.
5. **Licence-compatible?** Does the model work with the licence already published, or does it require a change you have decided you will never make?

Never put these on the paid side:

- **Security fundamentals.** sso.tax (the actively maintained `robchahin/sso-wall-of-shame` catalogue) names vendors that price single sign-on as a luxury, on the stated argument that "security shouldn't be a premium feature" and that SSO is "a core security requirement for any company with more than five employees".
- **Security patches for the free version.** Withholding fixes turns free users into adversaries.
- **Anything the community contributed.** Selling contributors their own work back invites the hostile fork.
- **Data export.** Developers read export lock-in as a trap and punish it publicly.

## Step 4, Price the go-to-market the model forces

A model decides who you hire and how long a deal takes. Make that explicit before committing, using the per-model consequences in [references/model-archetypes.md](./references/model-archetypes.md).

- Match deal size to motion:
  - Small contracts need self-serve with no human in the loop.
  - Mid-sized contracts support inside sales.
  - Large contracts carry security review, procurement and legal, and take months.
- Refuse the classic mismatch: a paid boundary that only triggers at enterprise features, priced as though it were self-serve. The cost of the sale eats the contract.
- Test that mismatch with unit economics, not a deal-size band: no defensible published thresholds separate self-serve from inside sales from field sales. Model the sale, estimated lifetime value against estimated acquisition cost, and the months it takes to earn the acquisition cost back.
- Use two reference points from David Skok's _SaaS Metrics 2.0_ (forentrepreneurs.com): "the best SaaS businesses have a LTV to CAC ratio that is higher than 3, sometimes as high as 7 or 8", and "many of the best SaaS businesses are able to recover their CAC in 5-7 months". Both describe SaaS generally, not developer tools specifically. Treat a candidate that cannot plausibly reach them as a motion problem to fix before committing, not as a forecast.
- Name the leading indicator that moves _before_ revenue does, one per model, listed in the reference.

## Step 5, Sequence by reversibility, then commit

Reversibility does not re-rank anything. Step 2's efficiency order already chose what to commit to. This ladder only chooses what to test first: one input into the effort axis, not a second ordering of the same candidates.

Where the two disagree, an efficient model that needs an irreversible lever, run the reversible experiment first and buy evidence before pulling it.

- Reversible in a quarter: price points, packaging, free-tier limits, adding a hosted option.
- Reversible with effort: opening a previously closed component, adding a support tier, entering a cloud marketplace.
- Effectively irreversible: any licence change on published code, closing a previously open core, a public promise about what will always stay free.

Decide the source-available question here, on this ladder, not in the step 2 ordering it was kept out of. It buys protection for the model underneath it and costs contributors, packaging and procurement reach. It is the most expensive row on this page to undo, so it is worth pulling only against a hyperscaler threat that already exists.

Commit to one **primary** model and at most one **secondary** that stacks cleanly on it (hosted open source plus enterprise support; consumption plus a committed-spend floor). Two primaries mean the decision has not been made.

Stack deliberately, not as a hedge. Mike Volpi of Index Ventures observed that the field's history shows three generations:

- The first found "it was harder to monetize software with just support services".
- The current one runs "Open Core / Cloud service hybrid businesses with multiple pathways to monetize their product".
- Developer buyers now accept "that open-source companies deserve to have a 'paywall'".

Peter Levine of Andreessen Horowitz named the same shift five years earlier and gave the reason: a pure support-and-services model "does not enable adequate funding of ongoing investments," so the fix is packaging open source "into a service (as in cloud computing or software-as-a-service)... a far more robust and flexible model" (2014). Two VCs naming the same generational shift five years apart is corroboration, not a second opinion to weigh against the first.

Take the permission and the constraint together: a paywall is legitimate, and one honest boundary beats two.

## Step 6, Write the memo, validated section by section

Produce a decision the team can execute without you:

```markdown
# Business model, <product>

## Constraints licence position, deployment reality, who signs

## Rejected models ruled out, and the constraint that ruled each one out

## Primary model what is sold, to whom, and the prerequisite it depends on

## Paid boundary what is always free, what is paid, and why the line holds

## Value metric what is counted, why the customer already counts it

## GTM consequence motion, what must be built, first three hires or investments

## Leading indicator the one number that moves before revenue, and where it is read

## Risks top three, each with the signal that says it is happening

## Revisit triggers the events that reopen this decision
```

Present each section and get agreement before writing the next. A wrong call on the buyer propagates into every line below it, and it is far cheaper to catch at the third heading than at the ninth.

A full worked memo, with a weak and a strong version of the same sections, is in [references/business-model-memo-example.md](./references/business-model-memo-example.md).

## Organizations versus individual developers

Both audiences exist in every developer tool, and confusing them is how plans die.

- **Treat organizations as the revenue base.** They pay for risk removal, uptime, support, compliance, control, someone to call, and they tolerate a boundary made of governance features and long-term support. Plan for their paperwork: security questionnaires, DPAs, invoicing.
- **Treat individual developers as the adoption and credibility base.** They pay small amounts for convenience, churn fast, and punish anything that reads as a trap.
- **Plan the individual as the path and the organization as the payer.** Where a decision genuinely works the same for both, the value metric is something the payer already counts, in either case.

## Measurement and the pass threshold

Hold the chosen model to this threshold before the memo is final, and iterate until it passes:

- Every one of the five paid-boundary tests in step 3 is answered in writing, and none is answered "no".
- The model has exactly one primary, at most one secondary, and every rejected archetype has a stated blocking reason.
- The value metric is something the customer already counts for their own reasons and can forecast before the invoice arrives.
- Cost-to-serve per free user is quantified in currency, not in adjectives.
- Deal size and sales motion match: the modelled LTV-to-CAC ratio and CAC payback are written down, and any gap to the Skok reference points above (SaaS-wide, remember) is explained rather than ignored.
- The leading indicator is named, instrumented or schedulable within a quarter, and has a target with a date.
- At least three revisit triggers are written, one of which is a failure condition.

Report the threshold check explicitly at the end. A model that fails on cost-to-serve is not a model that needs discipline, it is a model with the wrong value metric.

### Sourced numbers versus your own baselines

Say which kind of number you are using every time you quote one. A self-set baseline presented as an industry standard gives the plan false confidence.

- **Numbers never to invent:** currency bands separating self-serve from inside sales from field sales, and free-to-paid conversion rates for developer tools. Both swing too widely by market and product shape to carry a defensible figure. Derive either from the user's own cohort data, or look up current figures if you can browse the web.
- **This skill's own baselines, adjustable:**
  - Two or three candidates before a recommendation.
  - One primary and at most one secondary.
  - At least three revisit triggers with one failure condition.
  - Every rejection carrying a named blocking constraint.
- **Sourced, quotable with attribution:**
  - The LTV-to-CAC and CAC-payback guidelines (David Skok, _SaaS Metrics 2.0_, SaaS-wide, not devtool-specific).
  - The sso.tax argument on security as a premium feature.
  - Open core coined by Andrew Lampitt in 2008, plus Bruce Perens' and the OSI's objections to restricted licences being called open source (fine to cite for a coinage or a well-known position, not to carry an argument).
  - Mike Volpi's three generations of commercial open source (TechCrunch, 2019).
  - Peter Levine's argument that a support-only model underfunds ongoing investment, and that packaging open source as a service monetizes it more robustly ("Why There Will Never Be Another Red Hat", a16z, 2014).
  - The FSL's own summary of what it permits (fsl.software).
  - The licence-change outcomes in [references/model-archetypes.md](./references/model-archetypes.md).

## Common failure modes

- **Open core with no boundary.** The core is good enough forever, and nothing upstream ever creates a reason to pay. Test the boundary before choosing the model, not after the second sales hire.
- **Relicensing as a rescue.** Reaching for a source-available licence after adoption is a fork and a trust event with documented precedent. Pull licence levers early or not at all, and never call a non-OSI licence "open source".
- **Commercializing a community-built feature.** Selling contributors their own work back invites the hostile fork.
- **Consumption pricing without guardrails.** Metering with no spend caps, alerts or forecast produces bill shock, and bill shock in a developer audience becomes a public post.
- **Seats on an automated product.** Per-seat pricing collapses when usage grows through automation and agents instead of headcount.
- **A marketplace before an ecosystem.** A take-rate on a market that does not exist yet is not a model.
- **Sponsorship as a company model.** Donations sustain maintainers, not payroll. Route funding questions to `samber/developer-relations-skills@oss-sponsors-fundraising` instead of counting them as revenue.
- **Free tiers priced in adjectives.** "Generous" is not a number. If nobody has computed the marginal cost of a free user, the model is untested.
- **Deciding the model without deciding what stays free forever.** Silence there is read as intent to close, and the community prices that in immediately.
- **Quoting a baseline as a benchmark.** Numbers that sound like industry standards, conversion rates, deal-size bands, "typical" free-to-paid percentages, are mostly folklore in this market. Say where each number came from, or leave it out.

## References

- [references/model-archetypes.md](./references/model-archetypes.md), the nine archetypes: mechanics, prerequisite, economics, GTM consequence, leading indicator, failure mode, plus the documented relicensing outcomes.
- [references/model-fit-scorecard.md](./references/model-fit-scorecard.md), the constraint-to-archetype elimination table, the paid-boundary tests, the scoring sheet, the reversibility ladder, and a validation experiment per archetype.
- [references/business-model-memo-example.md](./references/business-model-memo-example.md), a full worked memo (fictional, labelled as such), plus weak versus strong versions of six sections.
- `samber/developer-relations-skills@developer-first-gtm` for designing the adoption motion this model implies.
- `samber/developer-relations-skills@oss-license-strategy` for selecting the licence a model depends on.
- `samber/developer-relations-skills@developer-ecosystem-strategy` for the platform-and-marketplace evolution behind the take-rate archetype.
- `samber/developer-relations-skills@developer-education-strategy` for training and certification as a secondary revenue line.
- `samber/developer-relations-skills@open-standards-strategy` for when a standard the product engages would change which layer you charge for.
- `samber/developer-platform-skills` when the chosen model turns the product into a platform surface others build on.