I'm working on RailsBilling - it's a Ruby gem for fast Stripe subscriptions integrations. It allows you to implement subscriptions in your app in hours, instead of months.
You see, Stripe is very powerful, but also very complex. Coding a straightforward subscriptions implementation will take you a couple weeks at best.
That is without handling all those edge cases like: prevent starting a paid subscription without a billing card on file (yes, you read that right)!
The gem is ready, I'm currently working on getting the website up. If you're working with Rails and need a solution for subscriptions get in touch at [email protected] - I'd love to chat!
I'm working on a paid Ruby gem for bespoke Stripe subscription integrations. It cuts down integration time from +6 months to less than a day, and handles many Stripe API pitfalls.
Stripe has a "developer friendly" and "easy to use" reputation. But, since 2019 the EU regulation has stepped in and made things more complex with 2nd factor authentication for payments (3DS/SCA). This made payment integrations way more complex. Integrating Stripe subscriptions now easily takes 6 man-months (I'm being very optimistic here).
Also, there are some basic scenarios that are hard to get right:
- Creating a paid subscription and ensure a customer always has a card on file (this one is almost impossible).
- Upgrading a free ($0) plan to a paid one.
- Upgrading paid plans, eg $10 to $100/month and ensuring immediate payment.
- Guarantee customer Tax ___location, keep the flow simple.
I made a video analyzing Stripe integration of a successful SaaS company (+$100M valuation). I first paid $30, then upgraded to their highest $2000/month plan - for free!
The gem I'm working on is intended to be used with Ruby on Rails apps. It covers all the above mentioned hard cases, and irons out many more Stripe API kinks. And yes, it handles the basic-but-impossible "ensure customer always has card on file if they start paid subscription".
After buying the gem you can hand-off the task to the junior developer (it's that simple). They follow the integration tutorial: follow the steps for Stripe dashboard config, do the local env config, done.
The product (Ruby gem itself) is ready. I'm now working on the web app, tutorials etc. If anyone wants an early, guided access, please email me - contact is in the profile.
Interesting. I built a recurring billing startup and was always wondering how Stripe dealt with those edge cases...
As a note, I watched the video, the company name does become visible at least twice, once from 6:33 in the header pane and URL and also at the very beginning (Company Insights pane -> below "Powered by AI" the AI repeats the company name)
Interesting idea, getting Stripe to work perfectly in production for a global product is not as easy as it was, it really takes a while to fix all edge cases.
Sometimes it's not about the "edge cases" and handling Stripe quirks. The main design consideration for global Stripe integrations is SCA/3DS or "payment confirmations".
If you implement something, then add SCA/3DS "payment confirmations" later on, I think it's impossible to fix that.
The main pain point I remember from my biggest integration was getting all the webhook events right. There was also a thing about the order in which the events were received sometimes.
Replacing ascii with similar-looking unicode characters is an old trick. There's a bunch of these characters out there. You can use it in the code to prank your colleague developers - April 1st is nearing!
I've never been pranked with unicode characters, but I've had a situation at work where a consultant from Japan unintentionally used some "japanese space" characters in a translation file, and that broke our app. Since I have my vim plugin running all the time it didn't take me a lot to see what's going on.
Lots of apps have helpfully started turning two dashes (—-) into some sort of Unicode long dash that is more aesthetically pleasing, while also breaking command line tools.
What you’re seeing is the result of software being more typographically conscious and replacing the incorrect characters we got used to typing in our keyboards with the correct ones. Same reason why " is replaced with “ and ”.
But you’re right that is annoying in a programming environment.
Heh, I kinda don't like these typing replacements (also, "smart" quotes).
If I type `--` it's because I want `--` (or even `-------` but some software† insists on changing that to a sequence of en-dash), especially I can type them easily on macOS:
- minus key: minus char -
- Option+minus: en dash –
- Option+Shift+minus: em dash —
Similarly, opening and closing single and double quotes are on bracket keys.
† yes there are OS-level settings for that (at least on macOS) but other software do it in addition to the SO, and you can't disable it plus it plays badly with undo.
Indeed “smart” quotes are a nuisance and it’s a small tragedy that curved quotes go typically unused. I gave myself a dedicated `“` key to make it the default in everyday use.
That's one of the reasons I abandoned Google Docs for keeping notes on administering my home computer lab. I use Linux so much of what I did involved typing commands in a terminal window. I would copy the text into document and later copy back to a terminal. It often didn't work due to the way Google transmogrified the text in ways not obvious to the eye.
I now use Markdown (and store notes on a private server) so commands can readily be replayed.
I’m sad and annoyed that Google Docs somehow manages to disable the Mac text substitutions feature (which has custom entries I want to use for frequent, difficult to type things at work) when you’re typing into a document.
The accidental crap can go a long way. I recall someone using a superscript ‘O’ as a degrees symbol in a medical report. This then got converted to a non—superscript character and rather changed the meaning. Extra unhelpful was that they wrote the word ‘degrees’ after the attempt at the symbol too.
Hi HN! I'm Bruno, the founder of https://linkok.com. linkok.com is a modern broken link checker.
I got the idea before the Covid pandemic: at the time I was looking for a better senior developer job. I sent a couple dozen job applications with my resume website, and I only got a couple job interviews, and no offers. I gave up and stayed at my old job. A couple months later I was optimizing my website. I checked for broken links and the results were bad: from 12 links total, 4 were broken. That's more than 30% broken links - no wonder I couldn't find a new job!
Since then I realized broken links are a problem for pretty much every website out there. If you have a website, you likely have broken links too. And the existing solutions don't cut it. Most online broken link checkers are old, and have outdated interface. Advanced SEO tools (ahrefs, semrush etc) can do broken links checking, but are too complex and expensive for regular people.
Under the hood linkok.com crawls sites using Async Ruby, which has proven great for this type of work. I love how easy it is to work with (when compared to threads). It also made some advanced features easy, like request retries. Async is a somewhat underused in the Ruby community. If someone has more questions about it, I'd be glad to answer.
My goal for linkok.com is that it should be easy to use (think: blogger moms), and it should be accurate and powerful enough for enterprises. linkok.com is free forever for small sites (up to 100 internal pages) and charges a fee for bigger sites. It's also completely free for open source, educational and non-profit websites. This is not automated yet, reach out at [email protected] and I'll set you up.
You may find this interesting: I worked on this project for 3 years! By far the hardest part was billing - integrating with Stripe properly took me almost 1 year (Stripe is very hard). I also shaved a couple of yaks, highlights: implemented postgresql and redis high availability, I run things bare metal servers (Hetzner).
I'd love to hear your thoughts, feedback and ideas! Looking forward to your comments.
Congratulations on shipping, the site looks great. I've been working on a desktop app in the same space (website health/administration). It's been a similarly long journey. I've found marketing to be an uphill battle. It's a crowded marketplace, which in many ways indicates a healthy ecosystem, but difficult to crack nonetheless. Having a focused audience (e.g. bloggers) will help there. If you ever want to discuss marketing or talk shop, definitely reach out (ben at hn-username dot com)... maybe we could both learn something.
I'm not sure I've the best antibot solution, but it's handled through some crawler options exposed to the user. Out of the box, I use a (fast) http crawler with my app's user-agent. It is not at all resilient to antibot. I direct users who are encountering issues to first try a user-agent override, and if that doesn't work, to next enable javascript crawling (think headless chrome), which is slower and heavier, but clears up a lot of issues. I don't have a strategy for aggressive antibot (captcha/etc.) other than to tell the customer to dial it back on their website.
Edit: I've seen antibot SAAS providers, which claim to provide workarounds at a cost. You route traffic through their network, and they have teams that are constantly tweaking things to keep the requests working, much like scrapers adapting to website redesigns. It would be a treadmill to do on your own. There more info on this at https://substack.thewebscraping.club/ In my case, selling single-user perpetual licenses, it doesn't make sense.
Yes, I thought you played with those apps and their proxies to get around anti-bot protection.
I also don't have anti-bot implemented right now, but that's my next step. I mean, my app "has one job" and it's not doing it well because of anti-bot protection...
I think with the distributed nature of a desktop app (running headless chrome), outside of cloud infrastructure/IPs, the internet is generally less defensive. It has bought some leeway, but I definitely should look into proxy support.
I had to recompile assets and the site was running at up to 20rpm, and it stalled. Back online now. The navbar prices are updated every 3 minutes, which takes 2s, and caches are 50ms until the update. I want to put the updates in a background job, but it isn't crucial yet.
> Does it come down to fundamental language differences?
No, I don't think there's anything fundamentally different.
Ruby 3.0 implements a "fiber scheduler" feature that enables "colorless Async". Fiber scheduler is an obscure Ruby feature, but the end result is brilliant. It was also a huge amount of work.
Side note: Fiber scheduler was implemented by the same guy who created Async Ruby - Samuel Williams. This guy is the mastermind (and master-coder) behind this project.
