If so how did they justify a $120M valuation and plan to deliver returns on what can trivially be replaced by a form-filling browser extension?
I'm not saying this shouldn't exist - it actually sounds very valuable. But I see it as a one-off purchase for local software, not a SaaS from a bloated company that is on the hook for delivering returns to investors.
that was fast !
I don't think the idea is really that bad, and a form-filling browser extension would not be comparable to what they were trying to do here. The idea is pretty compelling in isolation - your random mom n pop ecommerce site can compete with Amazon on price for a lot of things, but it can't compete with convenience.
If I go to Amazon I can buy something with one or two clicks and be pretty certain that my card details aren't going to get stolen and the thing I ordered will probably arrive when they say it will just about.
If I go to a random ecommerce site I probably have to register, have to enter my card details and confront the possibility of getting ripped off. It's so much less convenient, so for most purchases I just go to Amazon, which is bad for a bunch of reasons.
What Fast was promising to do was to bring that convenience and trust to ecommerce sites, so that they could become more competitive with the Amazons of this world, get more sales, make more money, consumers save money, everyone wins.
Of course the problem is that they're only compelling when they're ubiquitous, and when everyone already has an account and everyone already trusts them. It's a bootstrapping problem, one that only really works if you burn a whole bunch of capital to get both consumers and suppliers signed up, or if you can piggyback off someone else's market penetration, e.g. Stripe, and even with that leg-up they weren't able to survive. All of this also ignores the existence of paypal, apple pay, google pay etc which do offer most of the convenience already.
The bootstrapping problem seems like something of their own doing, both because it's a server-side solution as opposed to client-side, but also because there's most likely rent-seeking and extra fees involved. Every merchant wants to make more money so they should've had near-complete coverage very quickly unless there's a significant downside for the merchant for participating in said system.
I ended up a shop.pay user without even really asking for it, and I like it so much that I click the purple button every time I see it as an option.
With apple and google pay and other similar platforms integrating directly with your browser this type of product seems like a crowded market with very little existing need.
Agreed on shop pay which also comes with the rest of the store. Even Bolt has the whole checkout flow at least
Not for nothing, there can be a lot of value in simplifying things that could be trivially solved on a small scale by a programmer in an afternoon. A classic Hackernews comment about Dropbox and rsync comes to mind... sure doesn't seem be the case for Fast though.
In contrast, a non-rent-seeking form-filler is no threat for merchants and is a win-win for everyone. In fact, it wouldn't even need explicit support from the merchant to begin with, where as Fast needs commitment from the merchant to integrate.
I'm kinda happy that their attempt to seek rent on what is essentially form filling went down the drain where such an idea belongs in the first place.