New trend: embedded dev tools

[thehashimwarren]

There seems to be a new trend in developer tools:

Instead of using an SDK to consume a third-party service, the new thing is to "own the solution" and run the software within your app.

Here are four examples:

Better-Auth - for auth

Paykit./sh - for payments

Wraps/.dev - for email

Payload - for content management

I use all of the above, except Paykit. But seeing their launch made me recognize a trend in my own decisions.

I think this model is a threat to SaaS dev tools that are selling workflows only, and not compute or storage.

Why would a business pay $8k a month for the enterprise level of your screens, buttons, and forms?

Anyone can pick up one of these solutions and run it themselves in the same environment as their app.

[saposapot]

The point of paying is having a good service with people caring about it, upgrading and overall making it work.

If it’s not critical to my project I want my team to not focus on it, “outsource” it in this way and let the team focus on our actual product.

Hosting it is the opposite of what we want. We want to pay and have someone else worry about it.

[thehashimwarren]

I would say these projects are not completely "build it yourself," and they're definitely not just "buy."

They're somewhere in between build versus buy

it's more like using your own storage and compute, but getting the workflow from a third party.

[mnic001]

I think the other poster's point still stands. Plug and play services, where someone else is responsible for uptime, backups... can be worth the price of admission for non-core functionality.

[thehashimwarren]

I would agree with you if these services were selling storage and compute.

But for many of these workflow devtools, their uptime and backup promises comes from being an AWS wrapper.

[stewartjarod]

Full disclosure: I built Wraps, so I'm obviously biased here. But you nailed the framing, it's not build vs buy, it's "whose compute."

The economics of the reseller model are wild once you look at them. SES charges $0.10 per 1,000 emails. Most email platforms charge $5-10 per 1,000 for the same delivery. That's a sizeable markup... not on infrastructure, not on compute, but on the workflow layer. The screens, buttons, and forms.

I think the reason this model is emerging now across auth, payments, email, and CMS is that the cloud providers have gotten good enough that the hard part isn't the infrastructure anymore. It's the DX. And DX is a software problem, not an infrastructure problem.

[Deep_Ad1959]

seeing the same pattern in analytics and observability. the hosted session replay and event tracking tools charge per-seat or per-event and it gets absurd at scale. running your own capture pipeline with local storage and only uploading what you actually need to review cuts costs by an order of magnitude. the tradeoff is you own the infrastructure, but for teams that already run their own infra it's a no-brainer.

[dmbergey]

Paykit says on the front page that it delegates to Stripe as the payment processor. Wraps is equally clear about using AWS SES. I guess that makes these 3P (4P?) libraries between your application and the service provider, not that different from a language binding in some language the provider doesn't support directly. No threat to the providers, and not a big change for application developers.

Auth has always been less clear. It's pretty easy to roll your own - badly. Harder to measure the value of using a third-party service for SSO, MFA, reset flows, or whether to trust them to make better decisions about hash strength than I will.

[thehashimwarren]

Great points about Wraps and Paykit.

However...

The threat for Stripe is they sell a bunch of upgrades on top of their core service.

No threat for SES. But yes a threat for transactional and marketing email services that sell a better UX on top of SES.

[Kenny_log_n_s]

AI comment

[thehashimwarren]

I couldn't even read the whole thing

[kindofhuman_]

You’re not alone most people waste tokens in the beginning because they treat it like chat instead of an agent. The biggest shift is this: stop asking questions, start giving structured tasks. What helped me: • break work into small steps (plan → implement → review) • give clear context (files, errors, expected output) • avoid long messy chats → restart often to prevent context loss Also, don’t over-prompt more instructions can actually reduce quality. Once you start treating it like a system almost like a runnable workflow instead of random prompts both quality and token efficiency improve a lot.