IOW, the pain you think they are feeling is not the pain they are actually feeling.
As someone also trying to bootstrap a product, I feel your pain, but it's not specific to developers.
I know personally that waiting 15 minutes for a test suite to finish is super frustrating, but people seem to have normalized it. I've also literally been hired to speed up people's tests, so it's not a problem that doesn't exist. Our current customers are also delighted with the speedups so I know it's a problem. But explaining that problem and why the status quo is bad to developers is especially hard. Btw I don't buy the "developers are immune to advertising" spiel, I actually created some of CircleCIs first ads so I have experience doing this. I just think developers are different and marketing devtools is different again (because of it's not a personal purchase and there are a lot of different stakeholders).
They probably don't notice that delay, because they are doing something else during that time ... Reading the next ticket, some git admin, replying to an email, checking slack, etc.
As a single example, I don't consider a 15m delay for a full test suite to be a problem. I've got plenty of 5m tasks to do that I can use to fill in that time.
I cannot think of any developer who sits and watches the tests for execute.
I think some developers don't care, and some developers really really care and I haven't found a good way of partitioning the set and focusing on the developers who care.
You need to find the target market where a 15m delay is a pain point i.e. partitioning the set.
I don't personally know of any Devs who consider that a pain point, so it might be a really small target.
Trust me, I am going through the same thing, and I'm constantly questioning whether this yet to be released product has a big enough target market. No good to me if the alpha users comprise the entire target market, so I'm ready to pivot the moment they say "this is great, but we don't have budget/use this less great free thing/can't get approval/will sign up next year/etc".
That's all code for "this isn't a pain point for us."
The uncertain "faster build time" would be nice. But is it worth raising it up and battling for it? Unlikely.
I think a different case can be made if you target the managers instead. "Make developers twice as productive" might be a better selling point.
Compliance, reporting, scaling with number of projects/growth, interop with existing tools, and lastly a good word from other people in the same industry are what's going go sell your product.
In enterprise CI there are a bunch of other tools you're going to be waiting on, and at least from what I've seen on the field companies will run stuff like SCA/SBOM every build and keep a history graph of when and whom added things. The developer themselves typically does not care for that, but the 'enterprise' does
And that's in big part because they have been burned before. Someone bought a Product[tm] that supposedly Solved[tm] a Problem[tm]. Which then failed miserably to do anything of the sort. Then, to add insult to injury, these same developers are burdened with the need to maintain the expensive and useless thing that they can't get rid of.
If you are trying to sell a devtool, it should have next to zero cognitive burden even in the pathological case. Moreover, you absolutely can not lie, at all, about what your tool does or does not do.
Oh, and once the tool has proven to be useless, ripping it out of the stack should be friction-free. Easy? Hell no. But necessary? Yes.
Turned off vimium and ublock and still the case. Don't think I have any weird js going on. Also happens in incognito. I'm on desktop.
I believe that in certain scenarios it will be much faster. But I would have to go evaluate if it works in my specific case and how much effort it would take to move from our current setup to a new platform.
Combine that with the fact that 15 minutes of tests really isn't that bad. I came from the semiconductor industry, where some simulations would take days/weeks, that was a really frustrating feedback loop.
The 15 minutes is only really frustrating in one case, where you are working on one high priority feature/bug fix that needs to be fixed and deployed ASAP. Those 15 minutes can be killer when you've got some bug crashing your server.
Maybe you could monitor incident post-mortems and attempt to sell to those companies. Chances are, in the incident report the time it took for the tests to run will be highlighted.
The bit in your welcome blog about local tests being unfeasible is interesting. Maybe there's a pain point around pushing untested code? Like wasting reviewers time.
Drop me a line if you want to chat it through, sounds like an interesting challenge.