Where did I want to go with the API – scale it to the moon? No. So maybe it would have been better to stick with Xamarin or choose React Native at that point. This wouldn't be a problem if, because of limited resources, I wouldn't be required to learn it at some point. Behind its bold and shiny promises, Flutter suffers from many bugs and problems, but nothing has turned out to be a show-stopper. The outcome: Within a few weeks, we had the first version of the app up and running for both iOS and Android, which was great in terms of "time to market." The UI of our app had and still has its glitches, but those were and are neglectable for a B2B use case like ours.
#Retrospect website code
So I went with Flutter instead, which promised to allow us to build a more cohesive code base with less platform-dependent code needed than Xamarin. Xamarin.Forms was about to be discontinued soon, but dotnet MAUI was far from being production-ready at the time. However, I did not want to spend a large part of my limited budget on building two polished user interfaces, one for iOS and one for Android. The choice seemed obvious as a long-term dotnet developer who spent the last years building B2B mobile apps with Xamarin. I was looking for a pragmatic approach that was sustainable enough for the early stage of the project and sufficiently flexible to adjust while (hopefully) growing larger over time.
So I hired some folks to take over those tasks and went knee-deep into designing and coding the backend and the web app.
However, my design capabilities are limited, and I did not want to build the mobile app myself after being primarily in the mobile space for almost a decade. My goal was to bootstrap the product in its early phases with as little effort and resources as possible. Those client apps consisted of a mobile app and a web app right from the start. The platform's core is represented by a server-side application that communicates with client apps through an API. Think of a platform that allows businesses to interact with their customers regularly and in a more structured manner than, let's say, through e-mail. It's not simply forms over data, but at the end of the day, there is not much about it that would require sophisticated engineering – at least not in the early days when product/market fit has not been validated. The product itself is almost boring from a technological perspective. So I thought it would be a good idea to look back and see whether or not my assumptions back then would hold true over time. While some of those decisions were easy, I spent quite some time contemplating others.
From the start, it would require mobile, web, and backend components to make it work, so I had to make quite a few technology choices.
#Retrospect website software
Two years ago, I started out building a new software product. Technology Choices For My SaaS In Retrospect
0 kommentar(er)
