I've worked in a startup which processed 10,000s of different transactions from various countries around the world, we dedicated a whole 0.01 person to handling it. I think they were up to around 7 o 8 countries when I left. Had one full time dev and me a few days a week.
As in it was checked now and then, and we had the occasional query once a month.
YAGNI for a business like meetup. I don't think you realize just how much off the shelf, fire and almost forget stuff there is out there now.
6 person crew generating $40M a year with no VC funding. It was all operated off the money that came in the door. It can be done.
And I once ran a python script on my local computer and had no scaling issues. I dont know what all these people are talking about nginx, load-blanancers, blah! heck, I just used python -m simpleserver and Viola! it worked! See -- everyone can run a global business right from their macbook with 0 FTEs! I did it! (Please dont mind I picked the easiest script and conveniently based my business in places where Stripe works!)
People who don't need 15 FTEs, or even one FTE to take pretty large volumes of payments from many countries in the world.
Another reply is talking about $40 million turnover without a FTE.
The latest revenue figures I can find for meetup is $15 million.
So it begs the question, are you the incompetent and inexperienced one for needing to overengineer, or are we, for doing it cheaply?
I can support a trillion of US/Canadian/European transactions with mostly the same effort.
I think a lot of technologists confuse deploying code with actually handling transactions, charge-backs, local tax rates, etc. Also, just because you are small enough to ignore local tax laws does not mean everyone is.
Move fast and break things is all fun and games until you get charged for tax avoidance.
Five years ago, it was difficult to comply with tax laws in every US state, county, and jurisdiction (now there are services) -- can you imagine doing this globally?
I think you've never actually done this, have you?
Because things dont scale linearly? I mean I can support JSON messages in 5min. Another five minutes and I can support XML. So I should be able to support all the historical mainframe message formats in 5 minutes each right? No...
You can throw bodies at the front end by having support staff, bodies at the middle end by writing extensive help articles/documentation, or bodies at the back end to ensure you have robust data and reporting for pre-empting issues.
In any case, you need to think about it, and it'll take bodies.
I think you're over-estimating that by a factor of at least 15. If you're happy to say "let's just use Stripe, we'll support the countries they do, their payment forms are good enough" then that's like...1 FTE for a couple months to build your payments system, and then basically well under 1 FTE there-after to maintain it.
You can absolutely find work for 15 FTEs working on payments (and more!), and you'll probably end up with a better solution too, but there's plenty of startups accepting payments globally with, effectively, 0 FTEs working on payments.
This is an honest question, because I'm starting to seriously question my beliefs (I honestly though it was difficult.)
What's a bit newer is that it's a solved problem for people in other countries too; 10 years ago or so I really wanted to process payments, but none of the easy payment processors supported my country (mostly Braintree and Stripe back then), so I had to go with eWay (awful) and a merchant account from my bank (double awful). The company I'm with now (same country) uses Stripe, and it's a massively better experience. (Not being a Stripe fanboy; they have some very strong competitors, I just happen to be familiar with Stripe.)
Keep in mind: It matters where you (the merchant) are. Accepting payments from someone in Africa when you're in the US is trivial; accepting payment from someone in the US when you're in Africa is much harder. You can see where Stripe is supported here: https://stripe.com/global (and most of their competitors are in the same or fewer markets).
Also, there's still a lot of pretty bad legacy payment processors around, and they're often a fair bit cheaper. So if your company has been accepting payments online for twenty years, it may still be a pain for you, I wouldn't know. :)
But yes, the mom-and-pop website in Topeka should be using Shopify or have paid a web shop to throw together something equivalent using off-the-shelf packages, and it should be using Stripe (or Braintree, Square, Adyen, whatever), and then yes, they can accept payments globally, and the experience will be really nice. It's not even any extra work; it just comes out of the box for "free".
If people in those places don't have credit cards, I'd wait for Stripe to add whatever payment method they do use. (They've already added systems like Alipay and Klarna that are mainly used outside the US.) In the meantime, they can email me and we'll work out if they can mail me a check or use Western Union, or maybe I'll just give them an extended free trial or something. There are probably not so many people in the world who (a) don't have credit cards and (b) are interested in my software-as-a-service that I wouldn't be able to manually help them on a case-by-case basis.
(Disclaimer: I have worked on a mom-and-pop e-commerce website, but it shipped physical products and didn't operate internationally.)
The small company focussed on their core service. The VC corp has to reach out to new markets, increase sign ups, please advertisers and produce shiny growth figured for investors.
For users of the Meetup site it should be slim and I want to spend as little time there as possible (i.e. get invitation mail, ideally respond by mail, done) Meetup however wants me to "engage" trying to convince me to go to more meetups, rate them, comment, ... do as many clicks as possible while not driving users away ... all these deceptions take time to do, to try out, to A/B test. A committed founder who uses the site themselves notices where users got trouble and works on that. Maybe not in a team of five but also not hundreds.
I'm not the GP poster but that sounds like a good deal. So collect a paycheck, nod during the corporate circle-jerk of design meetings for weeks while working on your own startup and side consulting?
BUT - i'm at a VC funded startup and can see how bloated these companies become whilst achieving not much. Our company got VC cash, then the VCs installed a CFO. First thing the CFO did was demote most of the engineering staff down to entry-ish level titles.
Then came product managers, program managers, directors of product management, senior directors of program management, VPs of product, and C-suite.
The Product:SWE ratio is 1:2 to 1:5 depending on the team. That is right, since we're falling behind on coding and quality, the obvious solution to hire senior people to go talk at conferences.
Meanwhile engineering headcount and QA headcount barely moved. When product timelines and quality suffered, instead of considering why SWEs were demotivated, they hired more Directors and more Product Managers to micromanage and oversee the efforts. Except the Product Managers are remote and we barely ever hear from them. We think they are product managing their own careers mostly, we see more activity on their Twitter and LinkedIn accounts than we see on Slack.
So what have people done? SWEs jet out of the office at 5, many are running startups on the side, some are consulting on the side.
Next thing you have a several-hundred-person-startup producing about what you produced with 50 people
Fuck me.