Tech Stack Doesn't Matter...
Your tech stack (languages and frameworks you use to build your software) doesn't matter to you. It is nonetheless one of the most important choice you'll have to make.
Why it doesn't matter
I may be a bit controversial here. Especially because during my whole career, I have built software in some capacity. Desktop application, website, SaaS platforms, back-end scripts, APIs, ... I have built all. I am supposed to have a strong opinion on what to use, which programming language is the best, the platform I should choose to host my tools, ... Or it looks like most people do.
And yet, I don't really care. Of course, I have preferences. As has anyone in any domain, but because I tend to focus on the end goal, I am not too held up on what I want to use.
Any tool can do anything and everything another one can.
The way I see software is a tool to achieve a goal. In that context, how the tool is built doesn't matter much as long as it works.
Let me explain better with an analogy.
If I want to travel from Hong-Kong (where I am) to Miami (where I wish I could be spending the weekend). I have multiple options. And each with there sub-choices. I could go by plane, car, boat, train, walking, ... or even a combination of two or more (which is the most likely). Of course, some are better suited or more convenient than other. In that case, a direct plane to Miami seems to be the most obvious choice. But there alternatives, different options based on different choices. Now, if I am in Everglades City (cool place to visit), on the other side of Florida, would my choice be the same? Likely not. Technically, all those means of transportation can bring me there. Each with its pros/cons. And you may choose one or the other depending on what's available, the circumstances, what you enjoy the most and your risk tolerance level too.
It is the same with your tech stack. Each programming language can help you build anything. It will be more or less straightforward or easy depending on what you choose but they can all deliver what you want to achieve. Each has its pros/cons areas where it shines and areas where it may not be the best choice.
However, even if it doesn't matter, I still have preferences, tools and languages I would choose over another depending on the situation. Either because I like them more, know them more, or they are more suitable.
Software can be complicated
Even though I don't think it matters, I believe the tech stack must be chosen carefully. It can ensure that your project runs smoothly.
One of my past colleagues wrote an article about doing software development in startups that I would recommend reading if you want to get deeper into the subject. I don't necessarily agree with everything, especially in your context, where you're not trying to build a startup but optimize your processes.
Another point that this article should make obvious is that there are a lot of things to consider when building a software startup. Starting small allows you to avoid some of those pains. It also allows you to rip the benefits of software and automated processes sooner.
Own the decision
Developers will tell you what to use, never let them decide for you.
While in most cases, it doesn't matter, you still need to be aware of it and make sure that it matches your expectations. When a developer stops working on a project. You're the one inheriting it and having to deal with the maintenance, finding a replacement, ...
You can ask your developer(s) for their preference or suggestion, but make the decision yourself about what to use.
You should choose wisely
Both because anything can build anything and because software can be complicated, it is important for you to choose your stack wisely. Here are some criteria to consider.
What do you already know ?
Do you or any of the people involved in the process have a programming background? Some skills that can help immediately?
That should be where you start.
If you decide to build in-house, it will be much faster for you to build on with the skills you already have. They won't have to learn something new.
If you don't, you'll be more effective communicating with whoever builds your software. To both provide more pertinent input but also sniff out any nonsense a 3rd party can tell you.
Learning is nice, but, in most cases, your goal shouldn't be to learn a new tech. It should be to deliver value to your customer in some way.
How easy is it to find people knowing that technology ?
What's the talent pool around a specific language, environment, ... You want to be able to find someone to work on, maintain, fix what you build easily. Some tools may sound appealing because they can make building things faster, but in the long-term may become a liability. Try to make sure that finding help when needed will be easy for the expected lifespan of what you're building.
During one of my internship I had to work on adding features to an information system built using a proprietary platform. It worked well, kinda, may have sped up development, but any person making changes to that system first had to learn the internal language to make anything significant. You can choose a less known tech stack but know that this will introduce more training time later as the likelihood of finding someone familiar with it diminishes.
What are the industry standards ?
Depending on what industry you're in, there may be some technology or tools that everybody use.
For example, in finance, most institutions build tools using java and/or C#. One of the reason being that they are both backed by bigger companies (Oracle and Microsoft) that are involved in maintaining and building the language, tools and features around it.
So, if you are in finance, or you find what those language offer appealing, it may be worth it sticking with those as you're more likely to find people with industry knowledge to work on them later.
See what you value and what you consider important in the future to make your choice.
What is the recommended technology ?
Even though you can build anything with pretty much anything, some tools or languages are more focused or easier to use in a context or another.
For example, if you need to build some AI model, I would recommend using Python instead of something else.
Same, if building a desktop application, I wouldn't recommend PHP that is better suited for websites.
You can use whatever you want but don't need the headache.
How is the technology community ?
That relates a bit to 'how easy can it be to find someone to help'. But it is also quite different. Languages and tools can be widely used but without a vibrant community (and vice versa as well).
A vibrant community can be helpful to answer your questions and solve issues when you need.
One caveat though, don't let the hype blind you.
It is often better to opt for more established languages and frameworks rather than brand new ones that may not be around for long. So, do your homework and make sure that you choose a good balance.
What can you buy ?
Here as well, I am a bit controversial if you look into the software development crowd. People will say 'I can build it in a weekend' about anything and everything. Don't listen. My belief is :
Unless it is differentiating technology core to your business, buy or reuse as much as possible.
You are leveraging other peoples work. People who spent time, energy and money developing something and making it available. They can provide some support and maintenance. However, choose those ones wisely too (same questions above).
How much does it cost ?
Some choices will cost money, they will cost in salary, in tools, in support, ... Make sure that you choose both based on convenience and on what you can afford now and later.
Some other will cost you in time. Time to set up, time to understand, time to maintain, ...
You may be able to find free tools for most of things you want to do. That's great! It also involves more risks of abandonment. You may have to replaced it later. Pick and integrate with care.
Make sure that you also understand the cons of what you are considering and ideally how easy it would be to swap out for something else.
Making tech stack decisions can be a daunting task. But, I would say, don't overthink it.
See what solutions exist for what you are trying to achieve.
See what are the pros/cons of each.
Pick the one that seems to fit the most for now and later.
If in doubt, stick with the basics. Choose what is the most common or suitable.
If something seems risky, try to limit how much you depend on it and increase its swappiness level. (Making sure you could change it in the future if needed).