"If a nonprofit doesn't understand better than its donors where money needs to be spent, then it's incompetent and you shouldn't be donating to it at all."
Years ago, I had a startup that was building software for non-profits. We spent a lot of time around them, talking to them, etc.
This problem of incompetence that PG briefly touches on is rampant to a degree that most would never realize. Most large NPs are more inefficient than you could possibly imagine with their money (if you don't believe me, go look at how much of their money goes to administration and how much the people at the top are paying themselves). The SMB NPs (the group my startup served) were typically run either by narcissists who's real goal was to look good to other people, or they were very non-business/money savvy and driven by passion (in a negative way). Both of these lead to poor decision making, one way or the other.
The narcissists tended to do everything they could to look good while doing almost nothing (think: hosting galas to raise "awareness" or finding ways to be involved with big important people, without actually furthering their mission). They looked great in the public eye most of the time and could flaunt their "goodness" while secretly treating their employees like trash behind closed doors.
Example: the director/founder of one NP I know of that had a mission of helping pregnant women in crisis forced her 8 months pregnant employee to walk for miles through DC and do manual labor for her. She chewed her out in front of the whole team for saying she wasn't physically capable and made her cry, demanding that she do something that was technically her (the director's) responsibility.
The non-business/money savvy person who is driven by passion at least has good intentions, but they let that passion run wild without tempering it. This leads to knee-jerk reactions and doing things just to do them, without taking the time to play the long game or even determine if the action they're taking is helping or hurting. It's the classic "give a man a fish vs. teach a man to fish" problem, where they don't slow down to look closer, and so find themselves perpetually addressing the crisis instead of the underlying issue, or creating sustainable solutions.
The NPs that manage to avoid these are so exceedingly rare in my experience that it has turned me into a cynic. I just assume that there's incompetence at play, and even outright abuse.
Anyway, I agree with PG, I just had to expand on that point because it almost felt like a footnote when IMO it is a huge part of the problem: finding good NPs to donate to unrestricted. Otherwise, you have to settle for incompetence and restrict that incompetence.
For others who have the annoying keyboard issue being hinted at here (double key-press) and who, like me, can't be without their machine for weeks on end while they ship it off to get a new keyboard, I've been able to fix the issue by using Unshaky: https://github.com/aahung/Unshaky
For those that are interested in this concept, Cal Newport wrote a fantastic book about this concept of developing a passion rather than "finding" it in his book "So Good They Can't Ignore You". Very highly recommend.
The most effective way I've found to do code reviews is to create a pull request for the code you would like to have reviewed. Send it out to someone or a few people that you would like to take a look, get them to approve or reject it, and then take a look at their comments and see what you can do to address them.
Some guidelines for code reviews:
1. Build each other up. The purpose of a code review is to make sure the code is good, but also to help the team grow together. If growing isn't the focus, then code reviews can quickly become harmful.
2. Get code reviewed early, often, and in small chunks. No one wants to review a 1,000 line change spanning several sub-systems, and this is the quickest way to get people to just blindly approve or to discourage them from taking the time to review. Smaller changes make it easier to justify taking 10 minutes to look over the code and make some good, constructive suggestions. It also makes it easier for the person writing the code to implement the suggestions.
3. Don't take it personally. It can be easy to let our ego get in the way when reading someone's comment about our code - after all, we might be proud of it after having spent 45 minutes on the 10 lines that someone just said "could be cleaned up"! Keep in mind that code reviews are about growing and learning, building better systems, etc.
4. The review is about the code, not the coder.
5. Honesty is key. Don't be a jerk, but don't avoid making suggestions just because you're worried it might offend someone. That just makes the review pointless!
6. Be willing spend time with the reviewer if you wrote the code, and vice-versa if you reviewed the code, to go over the suggestions made. Sometimes a comment isn't enough to adequately explain something.
I could probably write more suggestions, but I think these cover the basics.
As for tools, I just use PRs. Create one, either add certain people as reviewers or put a link to the PR somewhere that you can ask for reviewers, and then await their approval/rejection/comments. Once you have approval from the reviewers, merge it. From there you can start to build out different processes/rules around it as you see fit, but it doesn't have to be complicated and doesn't require anything fancy.
I would recommend doing them more async as opposed to scheduling "code review meetings" however. These tend to be more wasteful and can introduce a lot more stress.
A lot of this comes with experience. 2 years is not a very long time to have been doing this. The longer you spend time in this sort of environment, the more things you'll learn and start to pick up on without necessarily needing to be told.
This goes for missing things as well as seeing refactoring etc as "work" - I used to think that too, but I've seen that as people gain more experience, that mindset tends to shift. Over time, you'll realize that it's better to refactor now than later when it will be much more painful. And if you're anything like most devs I know, you'll eventually begin to really enjoy refactoring because of how much more elegant you can make the code. There's something so rewarding about seeing a spaghetti string of code turn into a beautiful work of art before your eyes.
Another thing I'd like to note that I think is really important here is that having others review your code is a powerful tool. Even after many years of experience, I still get lots of comments on some of my PR's and you know what? That's my favorite thing to see! It took me a few years to realize that getting comments didn't mean that I was doing a bad job, it just meant that someone had caught something and there was something I could learn! In fact, I start to get nervous when I don't see people commenting on my PR's because it means that I'm shipping code that could have probably been improved.
It's also not just "smarter" or "better" programmers who are able to leave good, thought-provoking suggestions/thoughts on a PR that help the author learn something and improve their code. I've had juniors leave comments that taught me something or reminded me of something that I've missed, and I've also reviewed my manager's code many times and explained something that he didn't know - and he's told me the same thing about having reviewed HIS manager's code years ago.
The fact that you're already trying to be careful and diligent is awesome, keep that up. Just don't feel like you're not doing a good job just because you're not catching everything - that's the whole point of the code review.
I had a startup for a while and this was something I battled with a lot. It's one thing to have a little side project that no one knows about and that you can just pass off as something for your "off-time". When you start a company though, you make a public statement to the world in some form or fashion that you are building this thing and you believe in it's ability to make money. And not just that - you believe that it can and will be successful. People tend to start judging you right then and there. It's pretty difficult at times to handle that on its own - and then the doubts come, and the fears of how it will reflect on you if you fail.
"What if some technical challenge is too much and I can't get it to work?"
"What if I release it too early/ and no one uses/pays for it?"
"What if I never get past that first user or first 10 users?"
"What if people see me fail at this and then feel justified in thinking that I'm an idiot?"
They all boil down to fear of failure. The biggest thing to realize is that failure is the path to success and to reframe how you view it. Failure is the beginning, not the end. The end is defeat - when you decide not to stand back up again. And the people who are judging you? They are generally just insecure. I heard a quote once (not sure where it comes from) that says something to the effect of how the greatest treason a crab can commit is attempting to escape the bucket. If you watch them in a bucket, when one tries to get out, the others will pull them back down. That's how a lot of people behave as well - they will judge you for your failure and try to bring you back down to their level. Just realize what is happening, and reframe failure as a growth opportunity. You can't really lose then - if you fail, you've grown and learned something, and if you don't, well... Then congratulations, you've "won", so to speak.
It comes down to this: you will learn a lot from building a company, and those hard-earned lessons will only help you. Embrace failure and you are 10 steps ahead of those who run from it, because you're stepping into the arena and they're not.
"Best" is relatively subjective here, I think. Some people may agree that your approach is "best", but plenty of people would also prefer to keep as much of their logic in one place as possible.
Do the downsides still outweigh the benefits when you consider having multiple clients, especially when they might include mobile apps? If something changes about how I'm doing file uploading (eg. moving to a different file hosting provider), I really don't want to have to deal with the implications of making that change in multiple places, especially when it comes to a mobile app where you can't control what version people are running.
There are a few reasons you might want uploads to go through the server, and they basically amount to having more control. Imagine that you have an API that's being used by multiple sources - maybe a web app and a mobile app. The initial work to create uploads to S3 directly for each might not be too bad, but what happens if you want to change something later? Maybe you decide to move from S3 to something else, or maybe you decide that each upload should actually generate 3 different sizes of the image. If you do it through the server, this is all relatively simple. On the other hand, if you do it directly to S3, then not only do you have to change it in two places now, but you also have to navigate the issue of app versions - your original app version is uploading to S3 but your new one is uploading to some other hosting service, so how do you really get off of S3? And how do you keep them in sync? Definitely possible, but much more painful than changing a few configuration options on the server and migrating the existing data, etc.
Your assessment is correct that they are approaching you at your lowest. You said it yourself, albeit in different terms: they're trying to take advantage of you. This is a good sign that they're at least somewhat threatened by you and want to make you complacent.
It's not clear from your question what they've offered in terms of how many clients you'll get or how they'll decide that, but I'd imagine if you took the deal it would somehow work out that you got very few clients, those clients would be low quality, and you'd have a big loss in autonomy. When you give away parts of your company, you want to do it because you can see them giving you more than that back in value, not because it could help you barely scrape along (which is what it sounds like you're looking at with this deal).
Years ago, I had a startup that was building software for non-profits. We spent a lot of time around them, talking to them, etc.
This problem of incompetence that PG briefly touches on is rampant to a degree that most would never realize. Most large NPs are more inefficient than you could possibly imagine with their money (if you don't believe me, go look at how much of their money goes to administration and how much the people at the top are paying themselves). The SMB NPs (the group my startup served) were typically run either by narcissists who's real goal was to look good to other people, or they were very non-business/money savvy and driven by passion (in a negative way). Both of these lead to poor decision making, one way or the other.
The narcissists tended to do everything they could to look good while doing almost nothing (think: hosting galas to raise "awareness" or finding ways to be involved with big important people, without actually furthering their mission). They looked great in the public eye most of the time and could flaunt their "goodness" while secretly treating their employees like trash behind closed doors.
Example: the director/founder of one NP I know of that had a mission of helping pregnant women in crisis forced her 8 months pregnant employee to walk for miles through DC and do manual labor for her. She chewed her out in front of the whole team for saying she wasn't physically capable and made her cry, demanding that she do something that was technically her (the director's) responsibility.
The non-business/money savvy person who is driven by passion at least has good intentions, but they let that passion run wild without tempering it. This leads to knee-jerk reactions and doing things just to do them, without taking the time to play the long game or even determine if the action they're taking is helping or hurting. It's the classic "give a man a fish vs. teach a man to fish" problem, where they don't slow down to look closer, and so find themselves perpetually addressing the crisis instead of the underlying issue, or creating sustainable solutions.
The NPs that manage to avoid these are so exceedingly rare in my experience that it has turned me into a cynic. I just assume that there's incompetence at play, and even outright abuse.
Anyway, I agree with PG, I just had to expand on that point because it almost felt like a footnote when IMO it is a huge part of the problem: finding good NPs to donate to unrestricted. Otherwise, you have to settle for incompetence and restrict that incompetence.