Blacksmith CI Billing Controversy: Invoicing Free Trial Users

Blacksmith Invoices Free Trial User for $1,000 Overage

Blacksmith, a YC-backed drop-in replacement for GitHub Actions, has come under scrutiny after invoicing a user for over $1,000 in usage fees despite the user being on a "try for free" plan that required no credit card for signup. The incident highlights a significant departure from standard SaaS conventions, where free trials typically act as a hard cap on service usage.

In this case, the user reported that after exceeding their free minutes, they received warnings to add a credit card to avoid "disruption to service." However, Blacksmith support later clarified that "disruption" did not mean the service would stop, but rather that the account might be flagged for review or suspension. Instead of cutting off the CI workflows, Blacksmith allowed them to continue running and accruing charges at published rates, eventually resulting in an invoice for $1,081.45.

The Conflict Between Convention and Terms

Most SaaS users expect a free trial without a credit card to be a non-billing event—either the service continues for free or it stops working once the limit is reached. Blacksmith's approach shifted this from a pre-pay/capped model to a post-pay/invoiced model without explicit user consent for the transition.

Key Points of Contention

  • Ambiguous Communication: The term "disruption to service" was interpreted by the user as a service outage, whereas the company viewed it as an administrative flagging process.
  • Terms of Service: Some observers noted that Blacksmith's terms implied the right to bill was contingent on providing payment information, suggesting a potential contradiction between the company's billing actions and its own legal terms.
  • Industry Standard: Commenters argued that applying post-pay pricing to a conventionally pre-pay service is a "dark pattern" or a "scammy move," as it relies on user assumptions to generate revenue.

Blacksmith's Response and Justification

Greg, a product lead at Blacksmith, responded to the controversy by stating that the company has never actively pursued these invoices if the user felt they did not receive value. He explained the logic behind the policy:

  1. Reducing Friction: By not requiring a credit card upfront, Blacksmith aimed to support more free users and OSS projects.
  2. Avoiding Build Failures: The company believed that shutting down CI workloads entirely would be too harsh, as it would fail builds and require manual code changes to resolve.

Blacksmith committed to two primary fixes: implementing a "Wallet" feature that allows users to explicitly choose whether to suspend runners or allow them to continue running after the free tier is exhausted, and improving the billing/metrics view for better visibility.

Community Perspectives and Alternatives

The discussion revealed a deep divide between pragmatic developers and those who view such billing practices as a breach of trust.

"I can understand not wanting to kill someone's CI in the middle of active development, but then the product needs a very explicit consent step before converting free minutes into debt."

While the original poster decided to continue using Blacksmith due to the performance advantages over GitHub Actions, other developers suggested several alternatives to avoid similar billing surprises:

  • Self-Hosted Runners: Using a VPS with tools like Woodpecker or orchestrating Firecracker VMs on AWS.
  • Alternative Runner Services: Mentioning providers such as Depot, WarpBuild, Namespace.so, and Avrea.
  • Runs-on.com: A service specifically for managing GitHub self-hosted runners on AWS with budget alerts.

Takeaways for SaaS Providers

This incident serves as a cautionary tale for SaaS vendors regarding the "trust budget." When a service breaks the convention of the free trial hard cap, it risks significant goodwill loss, even if the intent is to provide a better user experience (e.g., preventing build failures). To avoid this, providers should:

  • Use explicit consent: Require a proactive "opt-in" before transitioning a free user to a paid, invoiced status.
  • Clarify "disruption": Avoid vague terminology in automated warnings; explicitly state whether the service will stop or costs will accrue.

Sources