Gonna start work on a new ERP software product.
Gonna start work on a new ERP software product. This is my first SaaS product, so I really need some mentorship here.
Any advice or not to-do's? I'd really appreciate it. :-)
Gonna start work on a new ERP software product. This is my first SaaS product, so I really need some mentorship here.
Any advice or not to-do's? I'd really appreciate it. :-)
I have an experience with developing ERP modules with .NET and what I learned is to keep the scope limited otherwise it is not easy to handle.So start with very specific features and module [sales,or invoice etc.] launch it,learn from it and keep improving
Hi, if you are an indie hacker starting out you probably have no money, no employees, no time and no resources at all so DON'T start an ERP.
ERP means sales, billing, inventory, distribution, logistics, production, HR, etc. Choose one of these modules and start from there, and remember to think small, small is achievable:
https://www.indiehackers.com/justinvincent/post/ba92ca3bd0
Best of luck!
Great tip! thanks
Wow, you're game. ERP is a big, tough market.
Do you have customers lined up, or at least a plan to start having conversations before you dive into the actual development?
Yes, have been doing research and getting positive responses.
Can you be more specific about "doing research and getting positive responses"?
If possible, I'd like to share the benefit of my own initial (fairly misguided) attempts at talking to early customers.
It's basically all encapsulated in The Mom Test (which, unfortunately, I only read after I had learned everything that was contained in it). But the idea is that it's easy to get "feel-good feedback" in the early days. Superficially it all sounds good, but if you start digging, it actually falls apart under scrutiny.
It actually does more harm than good, because it sounds like everything is going swimmingly.
Yes, I ask some specific questions with my end users about the need for this product. Most of them are have the requirement. As you mentioned, i still need to dig more. Any suggestions that i can go deeper into it.
Also, THE MOM Text - Interesting and practical method! Thanks again.
Read the Mom Test. Seriously, everything I'm about to say is laid out very succinctly there.
Basically it comes down to asking only two types of questions - fact-finding questions and commitment questions
Fact-finding questions are designed to uncover the customer's problem and level of demand.
This means questions like:
Note I didn't ask:
This is because you don't want to second guess the customer's requirements.
Always start with the most basic customer "need" you think you've identified.
Commitment questions are where you're asking the customer to actually give something up.
This means never asking questions where people are always going to answer "yes" to make you feel good.
This is terrible (and the exact question I asked too many people). So many people will just say "yes", even though they have zero intention of following through, or if there is zero prospect of them deciding to buy.
They want to avoid confrontation/offence, so they say "yes" because they think (subconsciously or otherwise) that they can brush you off in future.
If you're asking those kind of questions, you actually need them to commit to something. You need them to have skin in the game. Maybe this is "Can we set up a meeting with your CFO?"., or "can I give a presentation to your procurement team?".
The best sign is pre-sales, but that's very difficult. Next best is commitment to a price - i.e. e-mail commitment "If this does what you say it will, we will buy at $15,000". They're not actually signing up to anything, but they've gone through the motions to calculate what it's worth to them (which is a good sign). This also helps figure out your pricing.
The trap is, it's easy to think that you're getting non-committal responses because of your failure as a salesperson. Ignore that feeling, it's completely wrong. All you need to do is talk to them and ask the right questions. If they're hesitant, it's because you haven't nailed the right demand yet.
Most importantly - do this all BEFORE writing any code.
Wow. You are so much help full.
Can we connect on email or anything? so we can discuss more.
Sure, feel free to drop me a note at nick [AT] lexico [DOT] io
Thanks!
I have a deep knowledge of ERP. And I am also a solution architect.
Will sure need your mentorship! What do think will be the obstacle in development, marketing and sales?
I would start with the community edition: https://www.odoo.com/page/editions
Use webservices to consume it into your vhost interfaces.
Use this as an MVP, and build upon this until you can go all on your own.
I've worked on several, and I think the industry is ripe for upset. Get ready for some scope creep if you don't narrowly define the features you can go live with.
I'd be happy to discuss with you and potentially work together.
Thanks for the tip. I am already choose my segment now. I totally agree with being specific with the feaures, which i am studying now.
I am planing to focus on the low end customers first. Keeping it very few feature which are necessary and important, later go for new ones or extra.
I am planing to make web app, Mobile apps for this ERP. And i got a suggestion that Angular will be a good choice for this platform.
What do you think?
You could go with Angular or React I think. I've got less experience with Angular but my instinct says it might be slightly less reusable and composable, which is two things you'll want if you intend to build multiple products on the same code base.
Take that with a grain of salt though, I'm shooting from the hip on that judgement and I could definitely be wrong.
Sure! Helpful Insights. So, Where should i start? What tools do you use for pre-research?
I'd start with a web search for open source ERP solutions. Dolibarr is supposed to be good. I've tried ErpNEXT (don't like it but functional) and Odoo (decent).
Get a feel for some of that functionality, but only as much as you can get in a couple hours. Then jump in and try to recreate or re-imagine one piece of that functionality.
The size of the endeavor is such that I'd expect to have to prototype a couple times to nail down exactly how you'll need it to work.
Are you bundling functionality into modules that can stand on their own? There the potential that you can provide a tiny piece that is fully functional as it's own product, then expand it with modules that would eventually turn it into a full fledged ERP. Then you can monetize sooner and get some customer feedback behind you before climbing the ERP mountain.
Also, plan at least an outline of the sales model early, how you sell and upsell customers could be tricky in this space. Demo's will be basically a requirement, so it should be included. The business side of this will be an undertaking overall but I wouldn't let that be a deterrent.
Great resources. Thanks. Will go through and try to get more insights.
Planing to go by phase by phase, means the functionalities are necessary, important and optional.
Also, i have to work on sales model, since it is still a early stage (idea generation phase). Do you have any successful sales strategy or models that would help in the long term. Like building network around the industry is one way to make sales.
suggestion of article or videos that will be more helpful!
This comment was deleted 8 years ago