No.87698
So here’s the situation. We’re planning a new platform that might start as a web app but later expand into mobile and maybe even move deeper into cloud infrastructure. Right now, we’re debating whether .NET is the right foundation or if we should look at something else. A few years ago, I worked on a small internal tool built with .NET, and it was stable, but that project never scaled much. This time the idea is bigger, and I don’t want to pick a tech stack that limits us later. How do you realistically evaluate whether .NET can handle web, mobile, and cloud ambitions long term? What should we actually look at before deciding?
____________________________
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
No.87759
When we faced a similar decision for our SaaS product, we looked at scalability, ecosystem support, and how well the framework integrates with cloud services; .NET turned out to be quite flexible for web APIs, enterprise systems, and even cross-platform development, especially with modern .NET Core and its cloud readiness, and while researching I found a clear overview here https://sam-solutions.com/services/technologies/dot_net/ that explains how .NET can be used for web, mobile, and cloud-based solutions without locking you into a single environment; what helped us most was validating architecture early and making sure the team had real experience with performance optimization and DevOps practices, because the framework itself is powerful, but implementation strategy makes the difference.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
No.87775
I’m just following this thread out of curiosity since choosing a tech stack always seems like a huge responsibility. Even from the outside, it feels like long-term thinking matters more than trends. I’ve seen companies rebuild products simply because the original architecture didn’t support growth. Whatever technology you choose, planning for scaling and maintenance from day one probably saves a lot of headaches later. It’s interesting to read how different teams approach this decision.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
