been using this for a while now. the dev has been doing great work up streaming fixes and the overhauled UI makes it a lot nicer to use than stock freecad
former head of eng at a crypto company. I don't have the time to look thru your docs atm but I'd like to.
off the top of my head: stateless is tricky. as I'm sure you know, AML typically includes at least a few rate-based rules. eg: validate that someone isn't evading checks by making several transfers which are all slightly less than the trigger amount. it would be hard to justify paying for a service like this without that kind of capability, depending on the price ofc.
would love to chat more about this though. I'll set a reminder to check the docs later. feel free to send me an email, username at protonmail.
Thanks, this is exactly the kind of feedback I was hoping for.
You’re right — the moment AML requires behavioural or temporal patterns (e.g., multi-transfer structuring just below a threshold), true statelessness becomes a limitation. My approach so far has been:
1. Keep the core engine strictly deterministic and stateless — single-event checks only (sanctions, IBAN/SWIFT, address heuristics, ISO reconstruction, corridor rules, schema validation).
2. Defer pattern-based AML to external systems that already maintain historical context.
The API exposes hooks for institutions to call those systems before/after my validator.
3. Avoid storing any identifiers on my side to completely remove PII liability — it keeps the surface area small but intentionally excludes behavioural AML.
So the design goal wasn’t to replace full AML stacks, but to provide a stateless compliance primitive that can sit at the edge without holding risk data.
If you have thoughts on minimal context retention that doesn’t compromise statelessness (e.g., cryptographic summaries, ephemeral windows, or client-side state patterns), I’d be interested to explore those ideas.
Happy to follow up whenever you get a chance to look at the docs.
notification sounds destroy my ability to concentrate so per-channel notification settings were a game changer.
I typically have busy but important channels muted with a carve out for @mentions, watercooler channels are just muted but I check on them a few times a day.
imho this is a non-starter for mass market payments.
let's say a customer has found your website and wants to buy something. they first have to install a third party wallet app, fund the wallet by buying coins thru an exchange, then use the app to make a payment to the merchant.
it's the same UX problem crypto has tried (and failed) to work around, but with extra friction since it still depends on local currencies and has an unnecessarily obtuse deposit fees formula that emulates physical coins.
Unless I'm missing something, this is a complete nonsense comment.
Obviously you have to install the app, that's true for any app. But you only have to do it the first time around.
Are you just saying that this payment app has the first time friction of downloading the app. That's the same for all apps. Are you just saying that friction exists, and is a barrier to entry?
I don't need to install an app to then purchase a subscription on pretty much any web app on the internet.
You want to make conversion as frictionless as possible. Making potential users install another app to make a purchase will lose you lots of potential customers and money.
- % changes aren't that informative without the raw value change
- filtering by country would be useful
- a sample set of well-known companies would be good for new people
- mucking around with scroll behaviour makes for a terrible experience. on my pixel phone, the site feels slow as all get out and some swipes to scroll move two lines while others fling me across half the page.
Thanks for the detailed feedback.
The raw hiring counts are already available, the percentage changes are just one view. I recommend viewing on a desktop for the best experience.
The other points you mentioned, like country filters, default well-known companies, and scroll behavior, are all great suggestions! I'll try to work on them for the next update.
I firmly believe that this sort of fixit week is as much of an anti-pattern as all-features-all-the-time. Ensuring engineers have the agency and the space to fix things and refactor as part of the normal process pays serious dividends in the long run.
eg: My last company's system was layer after layer built on top of the semi-technical founder's MVP. The total focus on features meant engineers worked solo most of the time and gave them few opportunities to coordinate and standardize. The result was a mess. Logic smeared across every layer, modules or microservices with overlapping responsibilities writing to the same tables and columns. Mass logging all at the error or info level. It was difficult to understand, harder to trace, and nearly every new feature started off with "well first we need to get out of this corner we find ourselves painted into".
When I compare that experience with some other environments I've been in where engineering had more autonomy at the day-to-day level, it's clear to me that this company should have been able to move at least as quickly with half the engineers if they were given the space to coordinate ahead of a new feature and occasionally take the time to refactor things that got spaghettified over time.
As I pointed out in the "criticisms" section, I don't see fixit weeks as a replacement for good technical hygiene.
To be clear, engineers have a lot of autonomy in my team to do what they want. People can and do fix things as they come up and are encouraged to refactor and pay down technical debt as part of their day to day work.
It's more that even with this autonomy fixits bugs are underappreciated by everyone, even engineers. Having a week where we can address the balance does wonders.
yeah that's fair, didn't mean to argue against them entirely. I've just been in too many environments where fixits or cooldowns or whatever were used in place of good hygiene.
this program was great. I referred one person (the maintainer of an open source music player for OS X that I contributed an interface redesign to) back in the early or mid 00s and they've been paying me for it ever since.
unlike OP though, I had set up those rewards to cash out automatically. so once a year $35 would appear in my PayPal account and an indie dev or content creator would earn a sale.
reply