I want to know what languages and frameworks should i learn in order to develop a vertical SAAS Service. This includes making an iOS, Android and a Web App.
Feature that i want to develop are - - Inventory Management - Dealer Management - Accounting - Payroll - Analytics (Important)
What language are you good at OP?
You can quickly mock up majority of your use case using PHP, ruby or even Node.
Create a monolithic app and stay away from microservices until you have clearly drawn service boundaries. I'd say (6 to 12 months) in production. You dont need the headache of the distributed overhead.
Just keep in mind that you should "write code that can easily be disposded or replaced, not extensible"
For generating client sdk's i suggest using swagger. Grpc is there but i have trouble grasping protobuf sharing at the moment
For user clients, i would go for react native.
You're better off using a 3rd party for analytics when you are starting up: if you have the money, I'd suggest using segment, new relic or even google. Else, do it with prometheus or kibana.
My 2 cents
Ruby on Rails provides huge bang for the buck with their integrated database ORM, as does Phoenix (what I used). Your scope involves a lot of referential data, stick to traditional robust SQL database system (Postgres for example). If you use a NoSQL db, you may be quicker out the gate (as it'll take any JSON you give it), but once you get to the analytics with lots of joins, it won't be as much fun (personal experience). Also, I would suggest using the server frameworks' rendering engine to get your MVP up and running, as you can then fast iterate between data model changes and visual representation (i.e. HTML output), and avoid front-end builds and all that encompasses. Phoenix is very snappy, and with something like Turbolinks can potentially be as snappy as a dedicated front-end app.
Personally, I needed very interactive front-end, so had to build a separate front-end using Ember. I found Ember with Ember Data provides a robust toolset that manages complex data. I also have experience with React and Vue, but keep in mind with their state management (e.g. Redux / Vuex) that you'll need to manage complex data relationships yourself. As far as mobile, don't think native, as you'll need to learn specific technologies to implement that as well (more time...). Grab a bootstrap template that is already responsive, and you can run the same web-site on an iPad (forget the phone initially). Good luck!
source: just finished a 2 year build of an investment-related accounting and analytics webapp
For the mobile apps - Xamarin. You will still write C#, just use a different way of thinking.
Having the same technology stack in web and mobile will allow you to reuse skills one day when you build a team.
Then i want to process and display all this data (related to Manufacturing, Sales, Marketing etc) on web, iOS and Android.
So essentially there will be apps for employee's working in the plant (for data entry) as well as for the managers and owners (to monitor everything and make decisions)
I want the web dashboard to look somewhat similar to - https://demo.baremetrics.com
And since i have no experience in building mobile apps i want to know what languages/frameworks would be best suitable to develop good/native looking apps for iOS and Android using web technologies.
Thanks.
Don't worry about keeping the vertical secret for competitive reasons. You either have the domain expertise to make it great or you don't. And anyone with the domain knowledge knows what they want, but likely don't have the tech skills to make it happen. If you have both, start with the tools you know and get going.
I went the web/bootstrap path for most of it. I'll do mobile apps this year.
Get customers first. I had customers before the project had a name LR a signup form or much of anything.
Got fast.
I'm quite confident a number of highly knowledgeable people have looked at your question but have been unable to answer for lack of context. Narrowing things down a bit would likely get you more focused answers.
With that said, the best tech stack is the one you already have in your pocket. You could argue that this is why having a good all-around knowledge of all of the major stacks is a good idea.
So what i am planning to build is SAAS service that provides all the feature's listed above and more, customised for an (unspecified for competitive purpose) industry. The web client is used for entry of data related to sales, stock, payroll. I am also making apps for various operator's inside the plant to upload data using their android phone's and tablets.
Then i want to process and display all this data (related to Manufacturing, Sales, Marketing etc) on web, iOS and Android.
So essentially there will be apps for employee's working in the plant(for data entry) as well as for the managers and owners(to monitor everything and make decisions)
I want the web dashboard to look somewhat similar to - https://demo.baremetrics.com
And since i have no experience in building mobile apps i want to know what languages/frameworks would be best suitable to develop good/native looking apps for iOS and Android using web technologies.
Thanks.
On the surface you're describing something that's been done many many times (kinda obvious). On the one hand this means you could find someone to work with to help you on this fairly easily, on the other hand you're looking at 5 figures easily... which is likely why you're trying to figure this out yourself, now I think about it :)
I'm hesitant to suggest looking at existing off-the-shelf solutions; I get the impression that finding systems that haven't rusted together in the areas you need flexibility is touch-and-go and hard to figure out in advance. It may go incredibly well, or you may end up maintaining a massive headache that's incredibly hard to fit-out for your needs. One possible idea that may work to some extent is finding open-source projects that implement some or all of the functionality you want; they may be useful for parts/ideas or real-world answers to "how did they solve this bit," or even better you may find they actually work for you (yay free stuff!).
While you may come up with extra defining/deciding context/requirements, the main decision point I'm thinking of is whether you consider it a must (or a huge-value add) for things to be partially functional if there's no consistent network connection. This applies to sales/management (on a train, or at exactly the right vortex point between a bunch of buildings, and cellular just dropped out?) as well as plant operators (hypothetical contrived example: a non-essential machine just went bezerk and is spouting so much RF the Wi-Fi just died). That said, generally supporting transient network loss is... hard; you need a database design that, at every point in read/write, can tolerate "another client may have committed an update but that data might not be in the query we just did yet," which the application design must be built with awareness of (it's so fundamental it can't be abstracted).
If "the plant Wi-Fi just died" disrupting operations is okay (for example, you have somone on-site who can rapidly diagnose a wide range of issues, you have spare APs and related kit available, etc), then you'll save yourself a lot of time by just developing this as a webapp. Others may argue for native apps, but if you do a webapp, you can target desktop (Win/macOS/Linux(?)) + mobile (Android/iOS) just by using media queries. Suddenly several thousand lines of Swift and Java disappear :)
With enterprise setups like this, you also get to call the shots on what you contractually agree to support Android/iOS-wise; you get to specify the minimum versions, and you can also check the user agent and throw warnings or blocking error messages for versions you don't like. This isn't a public Web site, so you don't have to work for everybody. And so you get to guarantee that certain Web APIs are available :)
In all fairness there is the AppCache and ServiceWorkers+IndexedDB can cache web apps for offline use, but I wouldn't rely on them because the storage areas they use can be cleared.
Now I think about it, you could build minimal Android/iOS shells that load your HTML/CSS/JS into a WebView with some simple caching tacked on to guarantee code availability in offline situations. That could work quite nicely, and the native codebase would be tiny. With this Wi-Fi dying isn't a problem but now you need to go back to mentally modelling eventually-consistent database schemas.
On the backend side, what sort of traffic volume do you intend to handle? Do you intend to have the backend be on-site? (You could do a managed on-site setup where you have (monitored) SSH by contract but the system runs on client servers.) This would distribute processing load across the sites. If you want to centralize everything then you need to think about how many clients you want - then double or triple that figure (and then maybe multiply it by itself) - and you should have a good idea of the sort of volume you need to be able to process. There's a reason all the "how we process 1.21 jigabytes of messages every second" posts on here are so popular! You may need to look into high-throughput, easily-shardable datastores.
Regarding those graphs... well... note that you're looking at the revenue the guy who built those graphs is getting! :D I can see there's a fair bit of intelligence in the graph displays, and fine-tuning a similar system with a quarter of the functionality is something that would take a bit. Certainly possible, but it would take a bit.
Unfortunately I have very little advice to offer in the area of actual Web development; I haven't explored the scene much yet. I know that there are a dizzying number of developer offerings available. Your best bet is to forge ahead trying them and see which one you like.
I'm not a developer myself (in that I don't have a software engineering position - nor the mindset for one, just yet); I just spend all my time on HN :)
I wonder how much more specific you could be (for the benefit of everyone) without giving anything away.
By the way, thanks for mentioning the Baremetrics demo - that's really cool that they're open like that.
You learn what is evolving, and you grab onto it, and evolve right with it. This is easy territory for flame wars and "whatever fits you"/"there is no best stack", but that's not the full picture.
Your survival depends on what you know, life is full of surprises, death in family, cancers, car accidents, addiction, breakups, and depression.
Imagine a warrior, ask him, "what is the best weapon?" and can you really imagine him saying "There is no best weapon", no, s/he would never say that.
You go on the most popular code hosting website, you sort by number of stars and begin at the top.
To give you a specific answer "iOS, Android and a Web App" in context of "Inventory Management - Dealer Management - Accounting - Payroll - Analytics" is Apache Cordova, (iOS, Android, and others), you use npm/node this way you will have one code base, you won't have to write the same code in multiple languages (just imagine scaling a live data sync requirement in one app and then standard REST in another -- keep it all in one language, or you will fail.)
"Inventory Management - Dealer Management - Accounting - Payroll" is all pretty simple (but, please explore ideas like http://vorpal.js.org/ just to develop your API before getting to G-UI, finish your programs in the terminal first.
Don't pretend programs are written GUI first, they are not. GUI is a leaky abstraction to say the least.) Don't fall for redux, relax and use https://github.com/mobxjs/mobx for actual GUI, (by the time you get to this part https://vuejs.org/ will rule)
And for your Analytics front-end D3, it is a departure from standard JavaScript but it has a lot of love inside.
Finally, remember develop commands/API first, get your apps working in the CLI and you will finish your program before starting it. Think about using the power of Unix (https://www.npmjs.com/package/commander), for the love of all that is mighty think about IRC, NOBODY! has time to learn to use your apps/GUI and NOBODY! ever needed to learn how to use Siri, so create a Command Line Interface version of your program and before you jump to React/Vue meditate over https://hubot.github.com/ and programs like Siri.
Finally, if I was facing your requirements, I would build a wiki/forum where your users would interact with bots. Over time I'd rip put some of the robotic guts and boldly go where humanity needs to be headed, I'd replace them with what I call Artificial-Artificial Intelligence, networks of Human Mechanical Turks where anybody could participate.
Neural networks are easy to train, but they are also easy to trick. Nothing will beat a random sample of Humans from across the world reaching a consensus on a tough decision.
In closing, People, Real Hearts, Human Minds, powering your network would share in your profits, and you'd do your part in battling what ails us all, World's Poverty.
If a mother in Rwanda and a Boy in India participating in your Mechanical Turk can find their way out of poverty, by helping your to detect fraud in your circuit. Then, you did your part, to help Humanity grow.
In almost all cases, the tech stack is essentially meaningless. This runs counter to what we frequently want to believe as engineers because there certainly are meaningful technical differences between languages and frameworks. These differences just don't generally translate to meaningful business results.
For example, I am aware of a SaaS company with fewer than five employees total that generates over $3M in revenue annually. The profit margins are mouth watering - total non-payroll expenses are high five figures/low six figures each year. Everything is developed with PHP and MySQL - it would be vilified here, but it's more successful than virtually all the SaaS companies mentioned on HN.
I cannot tell you how many YC companies I have worked with that use Python, Ruby, JavaScript, Go, etc. At this point when I'm on a scoping call with a founder, I can roughly map out when the company was founded +/- a year simply by listening to their technology choices. I have not seen any meaningful difference in whether or not the company ultimately went on to great success based on the tech stack. Instead, I have seen companies go on to great success based on proper identification of real pain points, product-market fit, marketing and ability to execute well while wearing many hats. (But do keep in mind that this is anecdata and subject to usual biases of statistical rigor, or lack thereof).
My advice to you is this: develop your software in whatever language allows you to think more about business decisions and less about technical decisions. Your aim should be to build fast, iterate fast and fail fast. Many engineers who start companies struggle with this because technical decisions are their comfort zone, but your company will succeed or fail based on how well you identify market opportunities and figure out what your users want. If you just happen to be most comfortable in an "academic" language or a really trendy one, go ahead and use it. However, if you're most comfortable in Python, but you fetishize functional programming or React + Node.js because of the Medium posts that pop up on HN, go with Python.
Practically speaking for you specifically - I would first revisit whether or not you actually need a web app and two mobile apps. Could you get away with a minimal web application and choosing only one mobile application to start? Maybe develop in iOS or Android first, observe how your potential customers use the app, address grievances and product a mobile app for the other platform in the next iteration.
As for the actual technical choices - if you know several ways of developing iOS/Android/web applications, go with what is most familiar to you unless you have clear and incontrovertible evidence that one technical choice is clearly superior. If you have to learn a new tech stack to develop one of these, then 1) don't focus on it now, focus on market validation and 2) choose tech stack with the best combination of stability and ease of use to get up to speed with that platform.
Good luck!
One more point: It's important to understand what parts of your app are capitalizable, and which parts are aren't. The really capitalizable parts are the ones you think bring real competitive value to the market you want to attack - the code that addresses your valuable SME and original ideas. So something to ponder: if you want to also develop a presentation layer, how valuable is it really to develop that layer internally when in the long run that work is not much of an asset, and is a time hole for development? No matter how skilled your team is with the latest js framework I can guarantee you that there's some team of kids out there who are much better with the same framework and can develop your UI at half the price. So create your mockups, define your inputs and outputs, and farm that shit out. Unload the UI headache while in startup mode.
