>We once more have no full-time managers whose sole function is to organize or direct the work of others. Everyone doing management here does so on the side, next to their primary work as an individual contributor.
i.e Their Product Manager will also contribute to the project and code directly rather than handing out task.
This isn't just a tech thing. In many other industry they are filled with people as manager but has zero idea how any work are accomplished. Without all these knowledge they cant judge and manage any team properly.
On the flip side the best developers are not always (or even often) the best managers. I like technical managers but as someone currently managing and still contributing code I can tell you that they are 2 very different mindsets. Switching between them has a significant context switching penalty.
The annoyingly self-perpetuating truth:
- There are a lot of JS devs available to hire
- The ecosystem is huge and generally up to date (although you may have to bounce to a new framework for the same task a year later)
- New tools like TypeScript allow you to keep making the JS choice with a cleaner conscience even though it’s just transpiled back into vanilla JS.
- The mainstream alternatives are either not as fast to write or aren’t generally as performant as Node.
You might be interested to a look at hawker.social. It combines reddit with features of Patreon (subscriptions) and discord (sub channel). You can also use it as a substack style publication!
Yes, this has been dramatically improved. Servers scale up in 15 mins or less nowadays. (I do some work with Cloud 66 and they are dedicated and passionate about their product)
There is no contract so he isn't entitled to anything. To be on the safe side, you need to make sure that none of his work is used by the company. Eg redesign the logo. If you must use it, find a way to pay him for it. Form the company with just you and the existing IP asap.
This is a bit naive -- agreements don't require written documentation to be binding, and there are lots of indicators that an agreement existed (listing him on the website for example.)
The real problem is that this relationship (and it's unresolved status) would need to be disclosed to future investors.
The best solution is to come to a reasonable agreement with the person about exiting them with some compensation for their work that is reasonable.
Walking away entirely is definitely possible, but it exposes the company to future liability, so it's worth cleaning up properly.
"Last time I checked the network requests, I noticed it was storing the card on Stripe, CCBill, and Securion, but using CCBill or Securion to process the payment."
Im curious about how to use Stripe to only store cards and let other processors make the charge. Would anyone have more info on this? Greatly appreciate it.
> how to use Stripe to only store cards and let other processors make the charge
1) Have the user submit their card info on your payment page
2) Simultaneously send the card info to the 3 processors
3) Then process the charge through just 1 of the 3 processors, leaving the others open to be used later
(At least with Stripe) the process of saving a credit card to Stripe and actually charging the card are 2 independent API calls. Nothing stops you from saving card info to your payment processor(s) without actually charging it.
To pull that off, they'd have to (technically) process the card info, which puts them in the scope for PCI compliance. By that point, I don't know why they'd send card info to 3 processors especially when they know, at that point, which processor they're gonna process it with. It would just make more sense to send it to the 1 processor the code ends up deciding to use.
With stripe.js, you send the cc info directly to stripe from the browser. Stripe returns an identifier which you can use in the future to charge the card.
Assuming other payment processors work similarly, you could easily send the credit card details to multiple payment processors directly from the browser to the payment processors, and then store the card identifiers from each processor (not the card number) in your database to charge it at a later date.
Stripe.js creates an iframe hosted by Stripe which sends the card information directly to Stripe. The merchant cannot see or intercept that card info, during or after transmission, and thus cannot send it to another processor (at least not using the same payment card input boxes).
Dont know about Stripe but Braintree has a forwarding API where the card details go to Braintree then Braintree forwards that data to another payment gateway you have signed up for, the other payment gateway sends a token to braintree which forwards that token to you.
Then you have an option to make the payment on Braintree or the other payment gateway using that gateway's token.
This is nice for remote companies. We went to the pain of trying to get a good price Kaiser group plan but found out that Kaiser doesn't operate in other states that we have employees in.
Thanks! We have definitely found we are a good fit for remote companies with employees in multiple states. If you don't mind me asking, what did you end up doing for your health insurance?
