By now you’ve learned WTF a tech stack is and, after consulting with your engineer, you’ve discovered that they’re building the app in Ruby on Rails. Or Python/Django. Or Python/Flask. Why do they always come in pairs?
if (new Date().getMonth() === 0) console.log("Happy New Year!");
A framework isn’t required to build applications. One could write a web server from scratch in Python without relying on Flask or Django. However, for traditional applications, this would be reinventing the wheel. Frameworks can save engineers a lot of time, and many frameworks have become quite mature, meaning that developers are assured that it is generally safe to use and won’t contain very many bugs – probably a lot fewer than if the developer rewrote the same functionality from scratch. This frees engineers to focus on the code that makes your particular use case unique.
You might also hear the terms library, package, and module. These all refer to pieces of code that perform a specific function, typically for a more targeted use case than a framework. Like a framework, a library (and the similar terms) is written in a specific programming language and is usually only used by applications that are written in that language (there are exceptions to this). Your engineers might use a library that is written to interact with Google Maps, a library that facilitates image resizing, or a library that helps them query the database they have chosen. Unlike a framework, in which engineers typically choose at most one per application, a single application may use lots of libraries.
Choosing a programming language and a framework are both big decisions. Both are hard to change later. Changing programming languages requires a complete rewrite of the codebase, plus a big learning curve for engineers who are more experienced in the old one. Changing frameworks isn’t quite as bad; some of the code may be salvageable when swapping frameworks that use the same programming language.
Your engineer can tell you which programming language and framework they are using and why it was chosen. Each has pros and cons and is better suited for certain environments. Unfortunately, at many startups, the language and framework are chosen by the contractor who builds the MVP, and the future staff engineers run with it because switching is so much work. If you’re just starting out and are planning to build your MVP with contractors, keep in mind that even though it’s just an MVP, you’re making a huge technical decision that your future engineers are stuck with unless they rebuild the app from scratch.