101–110 of 230 posts
This is like a Stripe wrapper? Similar to Recharge Payments… the flow looks identical, well almost.
Recharge Payments looks cool, also seems more focused on Shopify stores?
Earlier quoted context omitted.
There's a lot of React devs out there who have never touched a server-side anything.
I feel like fullstack engineer was a BigTech manufactured title designed to save costs compared to hiring two experienced engineers, one in frontend and one in backend, but ended up leaving the fullstack engineers in a limbo state where they are neither good at frontend, nor good at backend, hence they require a bunch of (VC funded) tools to "simplify" their development life.
Now the title has been diluted to the point where it often just means “comfortable with JavaScript on both sides of the wire, plus maybe Mongo or Redis.” The original depth is gone, replaced by tooling and abstractions that compensate for the skills the term used to imply.
It’s a sad world.
-- actual (retired) full-stack engineer
I have an idea. Would be happy to get feedback + criticism. What if there was some standard API interface for payment processors? Basically AWS S3 API, but for payment processors. The idea being that migration between payment providers should be low friction and standardized. If you're in Stripe jail or banned, start using paypal (or something else) just by changing endpoints + credentials. Since Stripe is the gold s…
You can kind of get something that approximates this with a PCI vault or a payments orchestrator, but it's really hard -- maybe impossible -- to fully abstract away all the differences.
Earlier quoted context omitted.
I feel like fullstack engineer was a BigTech manufactured title designed to save costs compared to hiring two experienced engineers, one in frontend and one in backend, but ended up leaving the fullstack engineers in a limbo state where they are neither good at frontend, nor good at backend, hence they require a bunch of (VC funded) tools to "simplify" their development life.
There was a time when “full-stack engineer” actually meant someone who could run an entire application end-to-end—HTML/CSS, backend, databases, nginx, Linux servers, deployments, the whole thing. As Big Tech productized those environments and startups realized they could merge multiple roles into one salary, the title became increasingly attractive. People saw the compensation associated with true generalists and sta…
For what it's worth, the landing page is one of the most beautifully designed things I have seen in a long time. Congratz on the launch, didn't want to be so negative. I just hate that this is built on top of Stripe :(
Funny thing about the site: we deliberately tried to keep it single-page because we spent all of the past year building / testing the billing engine, data model, and SDK.
For what it's worth, the landing page is one of the most beautifully designed things I have seen in a long time. Congratz on the launch, didn't want to be so negative. I just hate that this is built on top of Stripe :(
I liked it too, reminds me of zed.dev...
Earlier quoted context omitted.
There's a lot of React devs out there who have never touched a server-side anything.
I feel like fullstack engineer was a BigTech manufactured title designed to save costs compared to hiring two experienced engineers, one in frontend and one in backend, but ended up leaving the fullstack engineers in a limbo state where they are neither good at frontend, nor good at backend, hence they require a bunch of (VC funded) tools to "simplify" their development life.
The web as a platform shouldn’t be constrained by two arbitrary, isolated boxes, because that’s not how it works. A software developer writing code necessarily has to get involved with stuff running on client and server devices and everything in between them out of sheer necessity, if they even want to understand how modern technology works in this space.
Earlier quoted context omitted.
It’s not very well hidden, it took me around 15s to figure it out from the main page. They are also trying to diversify (obviously).
The landing also doesn't clearly answer if they use their own stripe or we need to connect our own stripe account.
Currently you set up a new Stripe Connect account to get started. We tried the "connect existing account" flow and discovered that, maybe due to regulations or Stripe policies, we weren't able to debit the existing accounts.
Our Stripe flow is different from the run of the mill billing SaaS because we're involved in the movement of money (rather than simply using your Stripe key to steer API requests on your behalf).
We know that makes us look a bit like a fish with legs while we grow towards where we want to be.
For those who are wondering, like me, what is this? Is this a new alternative to Stripe? The answer is: no. This is an added layer of abstraction on top of Stripe.
Pretty much my 1st question when I see a new billing product. Thank you for answering that. I don't understand why products like these hide that fact or keep it hidden. A great product that requires connecting a payment processor can still be a great product but it is not an actual payment processor and that part needs to be clear immediately on your landing page.
The processing happens through our Stripe Connect platform, through which you currently have to set up a Stripe account. Over time, these details will be more abstracted away, much like Vercel is reselling AWS under the hood but doesn't require you to hand over AWS keys.
Right now, the reason this feels more like a "wrapper" than Vercel is that we haven't yet built out our own onboarding and KYC flow. We wanted to first deliver an amazing developer experience - something we're still working towards.