I'm a co-founder and CTO at Mercury. We have some amazing frontend UI (the onboarding flow especially) if you'd like to check it out, and our backend is 100% Haskell. AMA
We were a team of 3, with the CEO and myself technical, so ultimately it came down to just co-founder trust. Immad was somewhat skeptical, but after interviewing some amazing candidates who wanted to work for us to use Haskell, he's really liked it.
Development was pretty simple, I just created a yesod-postgres template and we got started with authentication. Are you asking about something specific?
Thanks for your reply. My question wasn't specific, more of a general approach, like how to find people and how to get started with development, etc.
So a small team with technically capable people with I guess little outside interference, that makes sense. I guess I was hoping for a good approach on how to make Haskell/ML/<other sane but not mainstream language> palatable to decision people who aren't all that technically inclined.
I hope so. A backend using Haskell sure would be a selling point for me. I shudder to think of the software that is currently used by many financial firms to handle backend interactions.
I also came across a post from immad [0] on hiring for startups, and it looks like you guys have a high bar for tech talent anyway so using Haskell shouldn't hurt. I wish you the best.
Yes it's definitely a more obscure choice. But a cult classic! It's worked out really well for us; the promise of "if it compiles it works" (mostly) holds out
I know of one other company and it's a small healthcare startup in KC that uses Haskell on the backend and Elm on the front end. I guess they just loved the concepts that much.
Jumping in for Max here. It was actually pretty tough for us to figure out how to name ACH as a payment method. One of our goals going into Mercury was to stay away from acronyms or confusing bank terminology as much as possible. Most banks hide ACH behind "bill pay" or use nonstandard terms like "electronic check" or "e-transfer" which are also confusing and don't describe the payment method clearly. We wanted to expose ACH directly but couldn't figure out how to get across what it was without confusing users further. Hours of debate in the office ensued.
Eventually we decided to just stick with the acronym after finding out pretty much everyone we talked to knew what ACH is.
The .com was unbeknownst to us one of the highest selling domains of all time. I’m sure the public lists I’ve seen are inaccurate, but it ranks at around 100 after selling for a little over a million.
I meant that as, why not pick a totally different name where the .com was available?
For a URL shortner or microblog, the TLD doesn’t really matter much. But for something like a bank it’s important. There’s also the long term problem of users typing the .com and getting sent elsewhere (again particularly nasty for a bank).
Once Haskell was decided on, how did you approach development?