If I understand it correctly... you just joined a startup, and judging by the term "hot startup", I get the idea that everything is happening at once, at all hours of the day. All the good, and all the bad. Duties change for some people every moment of every day, even during the off hours. Higher ups are no doubt pulling 25 hour workdays, 8 days a week. Figuratively, of course. (Honestly, if it's possible to do that, don't share lest bIg CoRpOrAtIoNs make employees work like that!)
First, it seems you come from a background that's a bit different than software development. Combine this with it being your first job, and no doubt this can be intimidating.
One thing I've found is that some of the "simplest" code ends up being the most annoying to contend with when something breaks - whether it breaks immediately or sometime down the road when seemingly nothing has changed.
So first... who is "we"? Who did a root cause? You're vague and as some other answers here imply, it seems there's a lot more to it than you've said - did you really run a root cause analysis? Did you see what exactly caused the issue? Did you even confirm that it's something that you even looked at, or had reason to look at but skipped?
Secondly, the phrase "pretty much" is really, really dangerous, in my experience. "Pretty much" means an assumption. "Pretty much" simplifies something immensely. It can be really powerful and useful to create concise, simple language, but you can pretty much not use the phrase "pretty much" when asking things on this site. Detail is key. Yes, I used that term just now. It's pretty much a matter of knowing when it's useful - I'm not asking for information so there's nothing to elaborate on, and the comment wasn't intrinsic to your question.
That said, what exactly are they saying, or doing? Are they treating you differently because of a mistake 2 weeks in? Did you mis-represent your skills and they thought you were a 10 year veteran developer (with 50 years experience in a 2 year old technology, lol) or are they aware that you're still pretty green and came from a different background? Are they acting like you should have known this "old software" like the back of your hand? What were their ACTUAL expectations? On one hand, I read this, and I get the vibes that you deal with ADHD and RSD (Rejection Sensitivity Dysphoria), like I do. I develop a tool at my job that helps improve the workflow of my actual job, and my team uses it. When something goes wrong, even after I test it, I feel this overwhelming feeling of crushing blame, that my co-workers are judging me, and I let them down. I feel like I'm to blame for any mess up (even if it's Chrome that crashed on an underpowered virtual workstation and not my code that was at fault), and suddenly I'm going to be sent packing, with a small box filled with my stuff on the desk. Granted, I'm not officially a developer, but the feeling is very real. Yet I remember how much praise I get for the tools I create, realizing... hey, mistakes happen. And we fix them.
Are your peers treating you (and the situation) like a child? Or, are they handling this like an adult, accepting that mistakes happen no matter how critical of a job it is?
Assuming your peers actually function like adults with a level head, I feel you should do the following:
Take responsibility. This doesn't mean you're at fault. This means you're going to be responsible for fixing the issue, whatever happened. Maybe it WAS an error on your part. Maybe any other veteran developer would've done the same stuff you did and wound up in the same spot as you. Who knows - but you now found a bug, and it's now time to fix it.
Are you at fault? Who knows. Look deeper, or don't look at all if you might get lost in self-thought. Discuss with your peers and see what happens.
What you're supposed to do... is treat it like a learning experience. You're not going to know everything. Even if you knew everything about the programming language and best practices, doesn't mean you know what has to happen HERE. Programming is a mess. Nothing is always perfect, and I found that just because perfectly written code is clean and might run great, doesn't mean that's what you'll be writing in production, or what you'll be debugging. It's not unusual to fix one thing that suddenly breaks somewhere else. It's a mess. Understand that this will probably happen again. Make sure your peers realize that this might happen again with ANYTHING. You might check everything that can be reasonably expected to happen (and everything that shouldn't happen but might), but the moment you deploy your code, something breaks anyway. All you can do is find the issue, fix it, move on. If the company your at actually has good people, you shouldn't be in any trouble.
The ONLY exception I might make is that in rare cases you're in a job that accuracy is key, even from the beginning. I've been in two such spots, but there was still a period that you could make mistakes if you were new. If you had prior experience, they were less lenient, but still somewhat accommodating - so while I could see things being worse if you're in this kind of company, I'd be inclined to believe that this is the exception, not the rule. And again, make sure people aren't acting like adult children.
