3 ms·

If I were you, I'd put all thoughts of "ERP Systems" out of your head. The complexity involved in dealing with ERPs is enormous-- as in, you'll need to manage

If I were you, I'd put all thoughts of "ERP Systems" out of your head. The complexity involved in dealing with ERPs is enormous-- as in, you'll need to manage a large staff of programmers to even get started. So: the question then becomes, should you build your Recruitment and Training app as a web app or as installed software? The first question: are there any advantages you see to the customers to one approach over the other? Surely, if you are about to build something, you know the market and have some target customers picked out-- what do they think? Would they be more likely to buy a web app or an installed app? Second question: where is your technical experience? Have you (or your staff) got more experience in building web apps or installed apps? In the absence of a strong sentiment from your customers/prospects, I'd suggest you stick with the platform you already know best.

ODosari 16y ago
Thank you Michael for your useful comment, I know how it's hard to do ERP System, however, I will start just with one of the Recruitment or Training and I consider Recruitment to be the first then will follow it with others components. I will develop them to be used as web app in both cases, if they are going to be as internet app or internal network in customer office, why will I start with Recruitment or Training? because I'm working in HR and I have enough experience in those fields and I know exactly what customers/companies need form both systems. Also, I add new features they are not found yet in any other smiler applications and it needs only 3 developers and 6 months of continuance work to build one of them (Recruitment or Training application). In addition, I'm addicted to programming and I use any platform that makes it easy for me to create my application. So, returning to my question which one is the better? Thanks,
- michael_dorfman 16y ago
  So, returning to my question which one is the better? I can't give you the answer to that question, nor can anybody else, as it depends on a lot of factors. What I can do, and have been trying to do, is to help you identify what those factors are so you can answer it yourself. You have HR experience; that's good. You say you know exactly what is needed for a Recruitment management tool. That's also good. Of course, before you start developing, you're going to want to validate your business idea. You need to do what's called "customer development", and make sure that the product you are designing meets the needs of others in the field, and not just your own needs (when you were working in HR). You'll also want to look at the competition. What other Recruitment management tools are out there? What are people currently using? By looking at these, and talking to prospective customers, you should be able to get a good idea whether having this app on the web will add value, or only add risk (in terms of security). Which brings me to my final point: being "addicted to programming" isn't going to help you. To create a piece of Enterprise software, you're going to have to know one platform inside and out. You're going to want to have already developed several smaller (non-Enterprise) apps on this platform. And, you're going to want to have a staff of developers that is already trained and comfortable on this platform. The recent mess with Diaspora is a good example of what happens when people try to build complex, enterprise-quality software on platforms they don't already know intimately.

ODosari 16y ago

Thank you Michael for your useful comment, I know how it's hard to do ERP System, however, I will start just with one of the Recruitment or Training and I consider Recruitment to be the first then will follow it with others components. I will develop them to be used as web app in both cases, if they are going to be as internet app or internal network in customer office, why will I start with Recruitment or Training? because I'm working in HR and I have enough experience in those fields and I know exactly what customers/companies need form both systems. Also, I add new features they are not found yet in any other smiler applications and it needs only 3 developers and 6 months of continuance work to build one of them (Recruitment or Training application). In addition, I'm addicted to programming and I use any platform that makes it easy for me to create my application. So, returning to my question which one is the better? Thanks,

michael_dorfman 16y ago
So, returning to my question which one is the better? I can't give you the answer to that question, nor can anybody else, as it depends on a lot of factors. What I can do, and have been trying to do, is to help you identify what those factors are so you can answer it yourself. You have HR experience; that's good. You say you know exactly what is needed for a Recruitment management tool. That's also good. Of course, before you start developing, you're going to want to validate your business idea. You need to do what's called "customer development", and make sure that the product you are designing meets the needs of others in the field, and not just your own needs (when you were working in HR). You'll also want to look at the competition. What other Recruitment management tools are out there? What are people currently using? By looking at these, and talking to prospective customers, you should be able to get a good idea whether having this app on the web will add value, or only add risk (in terms of security). Which brings me to my final point: being "addicted to programming" isn't going to help you. To create a piece of Enterprise software, you're going to have to know one platform inside and out. You're going to want to have already developed several smaller (non-Enterprise) apps on this platform. And, you're going to want to have a staff of developers that is already trained and comfortable on this platform. The recent mess with Diaspora is a good example of what happens when people try to build complex, enterprise-quality software on platforms they don't already know intimately.