Hi! I have a side project (that I haven't infiltrated with Claude Code yet, lol) that I need to dust off and get back to work on. It's essentially a B2B SaaS product where I needed to solve the usual suspects: multi-tenancy, SSO, RBAC, passkeys, sessions, and letting customers self-configure their IAM. Since it's a side project and I'm not paying for anything yet, I went ahead and integrated with WorkOS.
My project is built in Elixir, so I implemented the flows where my application has no login screen UI. I just push all unauthenticated users straight to WorkOS. WorkOS and their AuthKit (hosted login page) handles the heavy lifting (User/Pass, Passkey, MFA, SSO, etc) and sends them back to my application with a JWT. I check if the user exists, and if not, just-in-time provisioning kicks in on my side and we're done. Tenant identified, and tenant user authenticated all wrapped up in a single JWT.
Why WorkOS?
Simple... I don't want to be responsible for any authentication headaches. I don't want to self-host or duct tape a bunch of different components together. I'd rather put as much of that control in the client's hands (or WorkOS's if they don't have their own IAM). Plus, I like what WorkOS offers. Documentation is solid, though I still need to figure out their Fine Grained Authorization (FGA) product, formerly known as Warrant. In the end, nothing lives on my side except workos_tenant_id, workos_user_id, and my application data. The tenant has full control over their IAM, all the features of WorkOS via their own admin panel and ultimately who can access my SaaS application.
How's it going so far?
I have exactly zero customers except my development tenant. Everything works as expected so far. Maybe I'll have a different story when I get a customer willing to foot the bill for all the WorkOS bells and whistles in production. But implementation has been smooth, and AuthKit works great for dev/testing as a hosted login page, one-click testing SSO flows, etc.
If I had to re-implement, would I still choose WorkOS?
I probably would've done the same deep research you're doing, hoping to find that needle in a haystack. As a bootstrap developer, I'd try to avoid the paid options and figure out the open source/roll-your-own route. But if I had a plan to afford the paid ones, I'd probably evaluate WorkOS against other paid options properly.
Epic is a electronic health record (EHR) software used by many hospitals and clinics. It's not the only EHR there are many but it's probably the most known. Doctors usually type patient notes, diagnoses, prescriptions... everything goes in Epic and your team of providers can gain access to see that info.
I'm also in the process of building a product mostly in Elixir with minimal JavaScript. I just completed the WorkOS integration, now putting more effort into the actual product itself which is a extended workforce management SaaS.
What is your tech stack?
Backend: Phoenix
Frontend: Phoenix LiveView (with Preline UI)
Database: PostgreSQL (I want to use neon.tech soon for tenant db isolation)
Auth: WorkOS (for B2B SSO)
Cloud Provider: Fly.io (tbd)
Why did I choose this tech stack?
I've loved elixir for a few years but I've yet to build a functional SaaS with it yet. I've built one-off apps, and even stock algo bots. This time I'm going to try for something bigger which means I get to use Phoenix and LiveView to make a fast web app.
As for PostgreSQL we'll it's PostgreSQL and WorkOS seemed to be my biggest risk since I had no experience with it's platform or SSO OAuth2. However, WorkOS has tons of features that makes B2B SSO painless for me and potential customers. No real reason for fly.io yet.
Do you think your choices had any impact on your success or failure?
Same with any other loan product the bank doesn't care if it's a scam, only cares about collecting that glorious interest payment or fees associated. Plenty of people buy bad used cars with loans that span over years and that used car may fail months after purchase. Guess who doesn't care... the loan provider/bank.
Still the point is Affirm was the wrong target for their chargeback and the OP should have contacted Affirm to potentially resolve the merchant not delivering the goods or a refund of the loan.
I agree it does read like the OP triggered the entire issue with payments using a chargeback originating from Chase, regardless of the support/platform issues with Affirm.
I don't believe charging back the loan provider had any outcome to getting their product/service.
Wow, I use this same USB switch and also use two monitors for everything. Right now I manually switch my main monitor and just gave up on switching the monitor above it.
Since I got in a lot of debt with credit in the past. I don't have much credit now and majority is being paid off. So my financial setup is rather simple, always slide the debit instead of the credit.
Charles Schwab is my main bank <3, broker and 401k investment holder (employer forced).
Local credit union finances my car loan (almost paid off), my secondary checking/savings and my only credit card.
CashApp for any type of sharing/transfer of funds.
YNAB does all the budgeting. (I've become better at spending money that I have!)
So pretty much NordVPN pokes TorGuard into suing and now... NordVPN gets to put TorGuard in a body bag and call it a day as they've always wanted. Mission Accomplished.
My project is built in Elixir, so I implemented the flows where my application has no login screen UI. I just push all unauthenticated users straight to WorkOS. WorkOS and their AuthKit (hosted login page) handles the heavy lifting (User/Pass, Passkey, MFA, SSO, etc) and sends them back to my application with a JWT. I check if the user exists, and if not, just-in-time provisioning kicks in on my side and we're done. Tenant identified, and tenant user authenticated all wrapped up in a single JWT.
Why WorkOS?
Simple... I don't want to be responsible for any authentication headaches. I don't want to self-host or duct tape a bunch of different components together. I'd rather put as much of that control in the client's hands (or WorkOS's if they don't have their own IAM). Plus, I like what WorkOS offers. Documentation is solid, though I still need to figure out their Fine Grained Authorization (FGA) product, formerly known as Warrant. In the end, nothing lives on my side except workos_tenant_id, workos_user_id, and my application data. The tenant has full control over their IAM, all the features of WorkOS via their own admin panel and ultimately who can access my SaaS application.
How's it going so far?
I have exactly zero customers except my development tenant. Everything works as expected so far. Maybe I'll have a different story when I get a customer willing to foot the bill for all the WorkOS bells and whistles in production. But implementation has been smooth, and AuthKit works great for dev/testing as a hosted login page, one-click testing SSO flows, etc.
If I had to re-implement, would I still choose WorkOS?
I probably would've done the same deep research you're doing, hoping to find that needle in a haystack. As a bootstrap developer, I'd try to avoid the paid options and figure out the open source/roll-your-own route. But if I had a plan to afford the paid ones, I'd probably evaluate WorkOS against other paid options properly.