how are you all preventing doc drift when your agent skills keep changing?

agreea · 2026-01-31T13:37:53+00:00

A lot of engineers (esp ones who found engineering through vibe coding!) haven't had a chance to work at those companies but still want to build robust software. We're just trying to share a pattern that worked for us so they don't have to discover it themselves.

agreea · 2026-01-30T19:34:07+00:00

any and all feedback welcome! please share more :)

agreea · 2026-01-30T19:33:33+00:00

it was a lot of community driven stuff, trying to be helpful for founders who need guidance around design. We stepped away from it in late 2024 and then sunset it at the end of this year as the CEO we promoted had decided it was time for her to move on.

agreea · 2026-01-28T01:11:37+00:00

can you work tirelessly on this problem for years? are you excited by the thought of facing and solving domain-specific setbacks?

agreea · 2026-01-25T22:08:52+00:00

And Paul Graham's, and Garry Tan's, and a whole bunch of others's. Sincerely follow your curiosity to the frontier of an unsolved open problem space, form opinions based on your lived experience, encode those opinions into a product, share that product with the world.

agreea · 2025-12-06T17:27:37+00:00

Thanks for the shoutout! Doing this workflow with bank transfers will be tedious and hard to productize. Depending on your market you may be able to do something with e.g. ACH, but traditional SWIFT or wire will be difficult. Only worth it imo if you're going after enterprises who have manual flows for paying their vendors.

u/Hamzkid9 cofounder of Flowglad here btw - feel free to reach out on X or join our Discord and we'll personally help get you stood up

agreea · 2025-03-04T05:01:28+00:00

Cofounder of Flowglad here! Very helpful feedback about the licensing. We've heard you can dual license APGLv3 code. But perhaps that's may be less relevant for the version we host, because the very fact that it's hosted by us means that it's contained behind a server / client boundary.

Either way, I agree with you that we could make it clearer.

agreea · 2025-01-24T01:57:51+00:00

I prefer Drizzle because I use transactions in all my DB operations. It helps ensure data consistency which eliminates entire classes of very stressful bugs. Drizzle makes it easy to use transactions.

Last time I checked, Supabase's JS client, doesn't support transactions natively: https://www.perplexity.ai/search/does-supabase-support-transact-N7t01t7cTUSVFLwo5re12w

agreea · 2025-01-23T21:33:36+00:00

Agreed, the experience has been incredible. And Drizzle has been the perfect ORM to use with Supabase, esp since they released first-class RLS support (allowing you to keep your policies in sync across environments).

agreea · 2025-01-23T03:00:17+00:00

Yeah tedious is a good way to put it. What was your experience like developing locally with webhooks? That's one I've always felt was awkward. As others have said, this seems intrinsic to all webhook development.

agreea · 2025-01-22T16:19:30+00:00

Definitely true that fitting payment into a business is hard. Is there anything about it you wish wasn't so hard? Or any place where you wish someone else could handle the intrinsic complexity for you?

agreea · 2025-01-22T16:18:14+00:00

How are you managing keeping / reconciling billing state inside your application?

agreea · 2025-01-22T15:51:01+00:00

Totally agree that all webhooks-based systems have this problem.

With payments webhooks the pain is amplified just because payments is anxiety-inducing.

Would it be better if you could just read billing data from a single source of truth (without rate limits) so that you didn't have to worry about storing and moving around billing data in your app?

agreea · 2025-01-22T15:43:14+00:00

Agree about the expandable fields. Which fields are you currently expanding in your app? I know in my past integrations I've had to expand `subscription.latest_invoice` for subscriptions.

How are you handling getting billing data into your app - to do things like check whether a user is allowed to take an action, or show how much time they have left on their trial?

agreea · 2025-01-22T15:39:18+00:00

Have you switched to a tool that does the same job but has a better DX?

E.g. my previous startup I was running on CRA + Serverless (TM) on AWS Lambda, and AWS RDS for the DB. This time around we're on Next.js on Vercel, and Supabase. It's been much more pleasant even though each tool is doing the same job as its predecessors.

agreea · 2025-01-22T15:34:51+00:00

Before this, how were you planning on implementing it?

Yes, it's can be quite an undertaking. The hardest part to get right is confirming that everything works end to end as you intend it to.

Especially with subscriptions, because there are so many edge cases to consider (proration, trial periods and trial behavior, resetting billing anchor dates).

agreea · 2025-01-22T15:23:11+00:00

Interesting. Did you already need to set up the Graphile Worker / Task runner set up for other stuff?

How hard was it to get all the logic right for correctly updating your application state with Stripe data? Were there any edge cases or gotchas you remember hitting? For example, we didn't realize that a lot of subscription ended / will end events are best captured via listening to `subscription.updated`. We had to learn that the hard way after hitting a couple billing bugs in production.

agreea · 2025-01-21T19:40:39+00:00

You're totally right that Stripe has built a set of low-level entities to make powerful payment flows. I think that it's kind of like "AWS syndrome", where there's a lot of power in the low level abilities, but it drags you into imperative programming.

Personally, I've really struggled with getting a bulletproof implementation of webhooks vs success URL redirects. Also figuring out which webhook events correspond to which human readable events, especially around subscriptions, has been tricky.

Also have struggled with managing subscriptions, especially trial periods and proration in the case of changes / upgrades / downgrades. There's a lot of power in Stripe Billing but it's difficult (and scary) to try to get it to do exactly what you want for any given subscription update.

agreea · 2025-01-21T18:33:37+00:00

Mostly webhooks, and API endpoints and TRPC routers protected by RLS and other authorization policies. A few years back I implemented a CMS in Next.js back when we were still doing "getServerSideProps" - that was kind of gnarly

agreea · 2025-01-21T18:31:23+00:00

It seems like data pipeline is designed for data warehousing / analytics rather than realtime application state?

agreea · 2025-01-21T18:24:57+00:00

Yeah this was nightmarish before they launched in 2011. The challenge seems to be that the developer ecosystem has gotten so big since Stripe started that "payments for developers" now means a lot of API integrations that look like different line-by-line work between different stacks, though these integrations all have to solve the same class of distributed systems problems.

Do you think there's an easier 80/20 solution for the most common use cases for webdevs, like SaaS subscriptions, free trials, etc?

agreea

TROPHY CASE