[greg-m]

Hey folks - Greg here, I do product at Blacksmith.

I want to say upfront - we've never pursued these invoices. If someone feels they didn't get value from the service, we've eaten that cost and always will.

There's a bit of an implicit policy decision on our side here that we did a bad job of communicating - I want to clarify that, and then talk about how we can fix it.

First, we wanted to let customers start using Blacksmith without a credit card. Very few infra startups do this today - CC validation is great for anti-abuse - but doing so has let us support a much greater number of free users.

Many of these free users have turned into full OSS sponsorships (most recently ccusage, and before that, OpenClaw) or large paying accounts, and we haven't wanted to cut those users off from trying us. It's a real pain point to find a credit card to put down for your company or OSS project's CI spend before you've even tried the service.

Second, not having a credit card on file means we don't actually know when credit card-less users intend to continue past their free trial.

Shutting down users CI workloads entirely seemed harsh, especially because doing so would fail builds and require a code change to resolve. If users could start without a credit card, we weren't going to then hold their runners hostage. Instead, we decided to just eat the cost for the small number of users who either abused our services or did not actually mean to use the service.

This worked, mostly - though every month we have gotten a number of support cases with users confused about their invoice. If they didn't intend to use the service past the free tier, we've voided out the invoice, and often given credits against a future bill if they intended to use the service, but were surprised by the behavior.

We have a lot to improve about our billing mechanics - but because our retention rate for these users has been so high, we have assumed great support could catch and resolve the ambiguity.

That said, there's two changes we can make now:

1. we clearly missed the mark on supporting this specific case - we should have offered to void this bill entirely given the surprise factor here.

2. We're prioritizing up making progress on a Wallet implementation that will let folks choose to suspend their runners rather than let them continue to run after they use up their free tier.

We also just launched a new billing/metrics view so users have better visibility into their free tier and Blacksmith usage.

I'm sorry for the bad taste this has left in everyone's mouth - I'll be hanging out here and on greg [at] blacksmith [dot] sh if you want to talk about your account specifically.

[emacdona]

I appreciate you stepping in and clarifying. Thank you.

But honestly, this feels like damage control. This is (to me) clearly an innovation on a dark pattern that is basically just "accepted practice" nowadays, namely the "subscribe by default; make it hard to opt-out of said subscription at signup time".

That's why I think people are upset about this. By not taking a credit card, you made it feel like it wasn't an implementation of that dark pattern (yay!) -- however, secretly, it was!

If the intent is to be customer friendly, it's so perfectly clear to me what the answer is. OPT-IN. In other words, a checkbox:

"By default, when your free credits are consumed, all of your runners will be de-provisioned. Instead, if you would prefer that your runners continue working, check this box and we will invoice you for usage in excess of your free credits."

But honestly, you did more than I expect of most service providers today. You sent an email; you actually told them how many credits were left in the free tier. AWS, for example, can only give me an _estimate_ of how much cost I've accrued. They can make no promises about the rate at which I'm expected to accrue new costs. And, unless I've taken great care (by, say, terraforming every resource in a given AWS account), "turning off my cost accruing services" is not a simple matter. If I understood the article correctly, there was, at least, a "single action" they could have taken to immediately stop accruing costs.

[greg-m]

Thank you for engaging!

Yeah, I hear you on the inversion of expectations and I think you're exactly right about how this affects perceptions of the product.

Candidly, right now, we're more likely to land on an opt-out rather than opt-in here since getting your builds to actually run again requires a code change. I think there's a full blog post to write about why we think this is the right default, but we're still thinking it through.

Regardless, we need to make the choice loud and visible, and our miss was making it too hidden. We'll close that gap.

[kmoser]

> I want to say upfront - we've never pursued these invoices.

At first glance that sounds admirable, but the flipside is that it implies Blacksmith knows they're being shady: if you know you're not going to pursue it, why did you invoice the customer in the first place? This sounds less like you're forgiving a charity case and more like you're waiving an invoice because the customer identified it as unethical to begin with.

[greg-m]

Hey there -

I partially disagree! We issue an invoice because the customer did consume the services - a lot of folks appreciate that, since it gives their AP team a real cost to work from instead of a ballpark of us vs. GitHub.

My "we never pursue these" comment wasn't about us knowing the charge was shady - it was to clarify we have no strategy of chasing people/litigating over invoices they weren't aware of, which came up a bunch in the thread.

I do agree that pushing surprised customers through a support ticket is wrong, and that our in-product language compounded that issue. Controlling this belongs in the product so we can hit the mark on trust - we're building that now.

This isn't shady for most folks, since they're typically comparing us to known, expensive alternative. For those who are surprised by their spend (which given GHA's upper-bound pricing has been a minority) our reconciliation flow was for them to contact support, and my comment was to clarify that we don't have an intentional strategy to pursue folks for invoices they weren't aware of. It's clear to me that controlling this behavior belongs in the product so we can hit the mark on trust - we're working on adding that now.

[watermelon0]

Do you plan to refund all previous free trial customers, who didn't contact the support, and actually paid unexpected overage fees?

Invoices are legally binding documents in many countries, and even if that might not be the case in your country, not everyone might be aware of that fact.

> since it gives their AP team a real cost to work from instead of a ballpark of us vs. GitHub

Same could be achieved by showing the real cost in the web app and/or sending a report via email, without scaring them away, and possibly _extorting_ them.

[gblargg]

The terms state

> Alternatively, for larger contracts, You may request to be billed via invoice.

> By providing payment information, You authorize us to charge Your credit card for usage fees or, in the case of invoice-based contracts, agree to make timely payments as specified in the invoicing terms.

And at the top there's a Try For Free button that says no credit card is required. This strongly communicates that this free trial won't incur any costs until you add a card or agree to be billed via invoice.

A simple change of the text would make people a lot less surprised. Warn them that if they go over they will be billed. In the bill clarify at the top that they don't actually have to pay if they don't want to.

[greg-m]

Agreed - we've made this copy change to the free usage email now, and the change to add a toggle for preventing runs when you run out of credits is going through CI.

[explodes]

> I want to say upfront - we've never pursued these invoices

So those people who would feel guilty not paying are punished and those who prefer to try to cheat the system by skipping payment on invoices are systematically rewarded?

[inigyou]

That's how business works!

[baobabKoodaa]

The main issue is that you deceptively communicated what happens at the end of the free trial. You decided to use the wording "disruption", which implies that workloads will be stopped, which is the opposite of what happened. This is deceptive and predatory. I will never use your software and after this happened I am AMAZED that anybody else (particularly OP, but also anybody who read this post) will continue to trust you with their workloads. The way I look at this is: if you're willing to do deceptive and predatory billing, why wouldn't you be also willing to sell access to intelligence agencies or some other "grey area" party who wants to do supply chain hacks?

[inigyou]

This whole incident supplied them a lot more publicity. I had never heard of them before today. Since today, I'm more likely to use them, not less, because now I know they exist. I couldn't be less likely than zero.

[watermelon0]

Why would you want to use a provider, that resorts to shady practices, especially since there are a lot of alternatives out there?

[inigyou]

Who cares how bad the free trial experience is if the paying customer experience is good?

[watermelon0]

Technically, here the paying customer experience was the problem, not the free trial one, because they were automatically upgraded.

Generally, you don't want to award people/companies that don't respect you. I'm not saying that you shouldn't re-evaluate them in the future, but they will walk away with the wrong lesson if you just start throwing money at them.

[inigyou]

The problem here was with the free trial.

If you view it through a paying customer lens instead, then all you see is a paying customer who chose not to pay their invoice and might get sued. There's nothing strange about that.

All of the problem here was with the transition from free trial to paying customer.

[baobabKoodaa]

Personally I do care if I get hacked or if my clients get hacked. If you don't care, you don't care, I guess. For you it's enough that the "paying customer experience" (???) is good, whatever that is. Okay buddy.

[gblargg]

This story is also educating people so if they do use them, they know in advance how they bill so won't be surprised.

[baobabKoodaa]

Awful, but true.

[greg-m]

Hey -

First off, fair point on the free tier email. This fits in the same theme of clarity vs. trust for me: if we say disruption, but then leave your account enabled, that still feels deceptive even if it seems generous to us. We will fix.

On your last point - I just want to note that this isn't a money-maker for us. Runner bills can be large (as they were here!), and we explicitly wanted to avoid actual charges to the user in favor of not collecting for a good amount of usage. Again, there's a clarity/trust tension there that you're right to call out, but the end goal is that more people can use cheaper, faster runners.

We earn that trust today by being extremely easy to use and delivering on what we promise, and we need to add clarity to that list. Thanks for the feedback.

[madibo3156]

As a consumer, I can appreciate your focus on support. I get a monthly $0.00 AWS bill on an account I've lost access to. However, because I have no outstanding balance, support is unable to assist me (is their claim). So I enjoy one monthly spam email from them, which I neurotically read in case one month the balance for whatever reason exceeds 0. Still less stressful than trying to resolve the issue with them.

[gblargg]

> we've never pursued these invoices.

Reminds me of the company Tado, who was testing to see if people would pay by making them think they would have to even though they didn't. https://www.youtube.com/watch?v=tfAchfFXghc

[Arcuru]

I'm not so sure that Blacksmith is making the right choice around how to handle this signup flow, but I have very little sympathy for the person in this post. $1000 in CI is a lot of usage.

[greg-m]

I'd push back a little, the whole problem is that our flow let someone get to a surprising bill without it being obvious along the way.

Looking back at support cases we have typically seen this at much lower spend too, so it's definitely a clarity issue that we will fix.