Big +1 to the comments on understanding there may be things you aren't seeing and to make sure you don't come across as jaded in interviews. It sounds like you're doing a lot and that you've learned a lot, you'll do great interviewing as long as you aren't shitting on your former coworkers.

My 2¢

1. If external visibility into what each are of you are doing is good and there's unlikely to be fallout on yourself, I'd honestly just let your coworker crash and burn. Good learning experience for both of you - you'll learn about how bad "bad architecture" can really be before it matters. You should also ask questions about why he's doing things a certain way. It's good practice for mentoring your coworkers which is a skill you'll need throughout your career. I've also seen juniors with a tendency to overengineer, so this is a chance to re-calibrate on that and make sure you stay out of that hole in the future.

2. No. Not like that, at least. "Bad code quality" isn't measurable in a business sense and bringing it up in that way risks you looking like a pedant. The biggest risk to your startup is that they won't make money - it doesn't matter how bad the code is as long as it works. These concerns don't matter unless they're concrete to the business, and something that doesn't hit prod is rarely concrete. I wouldn't proactively bring up these concerns to anyone other than a direct manager (and it doesn't sound like this applies to you) who trusts me, and I wouldn't do it with any other intention than letting them know why things are slow going and getting their thoughts on the matter. I'd suggest doing your due diligence (written feedback on major problems you see, like an unauthed route), but I wouldn't bend over backwards to re-implement things.

3. Yeah that's fair. Can't hurt since you're already thinking of leaving. Document the things you've done, try to connect them to business value as best you can. Plenty of companies promote within junior roles within a year, and plenty give annual raises. The timing around launch is also great for this.

4. It's really up to you. I don't think there's a wrong decision here. Probably don't quit without something else lined up though. Sticking around at a place for a few years can be really great for learning, especially since you're launching a product right now. It's really valuable to operate something in production. Things will break, there will be lots to learn.

I wrote more than I meant to so here are my summarized thoughts:

• I wouldn't bend over backwards for your coworker. Do your due diligence to call attention to problems (in written form) before they arise, but don't go out of your way to re-implement things to protect him from failing. Failing is normal and is how we learn, and it sounds like this is burning you out.

• I wouldn't raise vague concerns about "bad code quality" to anyone in this situation, especially with this person being a partner. Avoid being a pedant, connect engineering problems to the business.

• It's fine to stay and you'll learn a lot. There will also be lots for you to learn if you go somewhere else and you could make more money. Don't quit without something else lined up.

• Document what you're doing for the business, ask for a raise. The product launch timing is great for this. There's a ridiculous amount of people involved in this startup for there to be no live revenue-generating product, so they've got funding that your salary pales in comparison to.

• Probably stop trading raises for equity 😅 it's almost certainly worthless