Let me say from the outset that I agree. So this criticism really is friendly criticism. Also: I have little hope, though I want to hope. So...

1) The concept of ERP is flawed.

ERPs are basically trying to solve the problem of documentation. Remember, ERPs were developed by IT. And they're what happen when IT people try to solve a problem using IT tools and IT methodologies. Now, is there some good there? Yes. Steve the Secretary can't quit and take his 20 years of experience out the door with him. "Where do I find <x>?"is never[1] a question post-ERP, because the process is well-defined.

Think of it this way. You already have a business (program). But you have a problem in that the founders are getting old, or workers are getting old, or things aren't being done consistently (no commenting). So with this massive program, you're going to cull through the processes people are already doing (source code), and evaluate them (optimize) and then implement a consistent approach (document the new code).

Guess what? That's hard to do with 20,000 lines of code. Now do it with a thousand employees. Oh, and make sure they remember that "one person" they call once a year to make sure your biggest customer gets their fruit basket every Christmas.[2]

"Well, all this sounds like a good idea!" you're saying? Sure, in a sense. But here's the flaw: just like good code, a good organization needs documentation from the very beginning. And that's my first criticism: don't get into the business of going back and documenting things that should have been done. Get involved in being involved from the very beginning. Of course, that's harder to "sell" -- small businesses have smaller ERP needs because there's less of an enterprise. So you'll make less profit. What makes me hope against hope: your solution could grow as the organization grows.

2) Big business is better than small business

There's a reason most ERP customers are big businesses: they have a lot to lose with knowledge leak.

But that's not the real reason. The real reason is that they're most able to benefit from the ERP while minimizing the cost of implementing the ERP. How do I know this? Big businesses usually get big because they have good business practices. And they're good at communicating those practices to employees. That is, they have good procedures and good documentation -IN THE FIRST PLACE-. So the process of encoding that is, while not without incident, not as hard as it could be. A small business that stays small because of the high training costs they incur every time someone moves on, or who doesn't follow procedure well so is unreliable, or what have you--THEY'RE the ones that have the most to -gain- from an ERP, but they're also the ones least able to bear the costs of documentation. If you're following the analogy, large enterprises already have some documentation, but have some poorly-documented interactions or classes. On the other hand, many small businesses have far LESS documentation - either because they don't need it ("Only 100 people, we can communicate it!) or they're just bad at it.

All that to say: the people you're marketing to are least able to meet the needs of the requirements / planning phase. That's a problem. I think there are solutions, but your post makes it sound like they're (smaller enterprises) are the EASIER customer, and I don't think that's necessarily (or even often) true.

3) ERPs are not modular

ERPs are almost the perfect example of the corporation existing to protect its own existence. "We've got a good thing here," says someone high up, "Let's keep it that way." ERPs -sell- themselves as being modular and adaptable and nimble. "Nimble" doesn't need a multi-million dollar budget, a hoard of consultants, and two years.

Say your HR department figures out a method of processing applications that increases processing speed by 10% with no degradation in quality. Without an ERP, the head of HR (maybe) checks with their VP and then tells everyone below them to change, and that's that. Good luck making that change post-ERP.

And this is the downside to the upside I mentioned above. Steve the Secretary can't quit, but Gillian the Genius can't get hired and have a brilliant insight that rapidly streamlines processes. (Which, I suppose if you really think about it, is what enables ycombinator: large organizations with non-malleable standards need to outsource innovation. Lucky us!)

The plus side: although the cost of inter-departmental interaction change goes up, the intra-departmental change is (comparatively) easier.

I think your system could benefit in modularity, especially if the ERP were "in the hands" of the people. But that, of course, increases risks.

The bottom line: if you build for modularity (really build for it, not in the "The salesperson told me it was modular" sense) from the beginning, it would be amazing. But you have to really build for it. And I know you get that, but I don't think I can say "really" enough times here.

The BEST of luck!

[1] If you listen to marketing. There are still problems with finding things post-implementation, but I will concede these types of problems are significantly reduced. The -real- loss now is, "How do I get <x> done when the ERP doesn't want to let me?" - and THAT answer is far more valuable, in my opinion, and far less often documented.

[2] Dramatization (barely)