On the buy side covering software, how well do you truly understand the technology?

I mean you definitely need to dig into it but after 50 conversations with experts and advisors and industry participants, some of which you should find yourself, done over ASO years, you'll have enough of an understanding to be fine. Anyone can do it, it's not rocket science to understand what each one does and why it's needed. I mean take MDB for example, it's a document database. You should understand why that's important, what kinds of apps it powers, what came before that, what innovations are in the space, how it gets made, what people do with it, etc. YouTube videos can be helpful. It's as much of an understanding of past present and future as it is understanding the product. You'll never need to go deep into architecture, that's what you hire West Monroe for.

I am currently interning at a LO (I am a junior studying finance at a non target, will be at LMM IB in NYC this summer)  I "cover" a lot of the SMID cap software names. Would love to connect and talk about software with you sometime.
I am personally fascinated by the infrastructure/DevOps names (DDOG, SNOW, ESTC, DT, GTLB, FROG etc).

What has worked for me is understanding the purpose of the software, who uses it internally and where the software sits in the broader "stack."

Once I have those 3 figured out, I attend the product demos that some of these software sales folks host where they talk about how to use the platform on a day to basis. Another thing that I do to understand the technology is connect with software engineers on linkedin and ask them about the platform. This should help you understand the use cases and workloads that the software can address as well as the value proposition. 

There are also some software engineers that talk about the architecture of different apps/software on linkedin.

Here are some that I follow: 
https://www.linkedin.com/in/brijpandeyji/

https://www.linkedin.com/in/ginacostag/

I have only been looking at/covering software companies for 4 months now but I hope this helps!

Start with the customer and work backwards

How does the customer use the product, how do they perceive it competitively vs others, how hard would it be to rip and replace (time, money, user retraining, data migration, external integrations, etc.)? That is exponentially more important than understanding the 0’s and 1’s.

Don’t get me wrong, the underlying tech is important. You want to understand the underlying tech to try and discern how differentiated and easy to replicate a product is, but if it is characterized by high switching costs (which is the most important aspect of understanding software IMO), it won’t really matter. Think CRM platforms, really not all that hard to replicate the underlying tech, but extremely burdensome to rip and replace.  

Do you actually think the stock price of a company is based on how good their software is? 

For what it's worth, there are a lot of good system design / architecture breakdowns of modern applications on YouTube, Substack or Medium. 
 

If you Google around should be able to understand how different parts of the stack fit together inclusive of use cases for some of these more behind-the-scenes / platform-y companies. 

This is why MM > SM. Dumbass SMs trying to understand product and crap and company miss revenue by 1% and stock trades off 40% instead of knowing what Fking moves the stock. 
same idiots also “deep diving” into Coca Cola product flavor differentiation when it was obv short based on Ozempic thesis and tough comps. 

could anybody be kind enough to guide me to some software primers.

i heard about "stack" everywhere but have no clue where to learn about it from the ground up. 

Yes, you need to know your coverage and the value prop for each company. This falls under analyzing the product-market fit of the company's solution. It's pretty easy to do -- go through your expert call library and most of the time the first few questions are "who exactly is this used for?" or "how does this work?". 

As a research analyst, I usually start out on the model by building a fleshed out 5Y or 10Y historical to get a clean view of numbers and how different metrics tie to each other (after smashing 30+ or 50+ models you will find those correlations quickly). Then I do my vanilla projections for the out years based on those connections I made up in my head while making sure that my numbers tie up to management or industry expectations. If I want to know better about the product / business, I usually like to read Gartner, industry forums and the blogs on company websites (a relief that software companies like to do this as software is really the only sector that does knowledge-sharing). You can even read some Substack articles on your company, though you will have to end up digesting someone else's investing perspective. Having access to the thousands of millions of resellers out there is a big benefit to you but I would only rely on them for customer feedbacks and market competition stuff, since channel incentives vary by companies and those reps only jazz up their schpit based on where the stock chart is going / how much they are getting paid this quarter when getting asked about anything near-term (quota expectations). I then turn back to my model and make any lasting modifications I may feel necessary. I wouldn't stress out too much about any kind of "secret sauce technological differentiation" that software companies promote because software / internet are sectors where a rising tide lifts all boats. If advertisers are spending then all social media benefit in someway. If companies want to use datalakes then all alternatives data warehouses benefit in someway. Your decision to be bullish / bearish on specific companies will have to come down to numbers.

If this makes you feel better, a lot of the resources I just mentioned for software are borderline impossible to find in other sectors. Take hardware for example. You'd be lucky to find Gartner reviews if they have a subscription offering (usually not). Substacks are (relatively) easier to come by than Gartner but much lower quality than the software substacks cuz most people jazz up the same grandiose TAM / secular CAGR vision that management spills in their Investor Day. On top of that, it is impossible / I'd even say useless to actually model these companies because they sell to the channel, rarely directly to the customer. So the business trends that you did work (r.e. talking to the resellers) to find always lag by 1-3Qs which is enough to kill you in a pod with a streak of misses, and no management is going to handout favors to investors by warning them about a "potential slowdown in channel sales" when management themselves are desperately trying to shovel the channel to the last mile. What's worse, the bread and butter of hardware knowledge at large may not even be available in English. Koreans are the best in memory and panel technology. A stray on the sidewalks of Seoul may know better about panels than your pod colleague in New York covering CME. Despite all the challenges above it is absolutely critical to find the bread and butter technological differentiation in hardware because  missing out on a big transition or refresh cycle in hardware is enough to kill a stock for several years. That means your bets in hardware are absolute (not relative like software / internet where you can flip flop between stocks based on where numbers are trending) and being on the wrong side, even within the same vertical but with the wrong company, can cost your seat. That's why hardware folks tend to be "duration" focused because no one really knows what's going on for the next quarter and have to eat up management's slack vs having much more research flexibility in software and internet to make quarterly bets.