Thanks for elaborating. To me, it looks like you could definitely use an experienced dev-background person to help organise the project. For example, login is low priority imo - it’s not needed until you’re going into testing. And I mentioned the project being US-focused since I noticed stuff like eligible_1099 in the table design - not a thing outside the US.

Also, I’m working on a project for a non-profit, and as part of it I’m doing an audit trail functionality. Ended up thinking real hard over what’s PII you actually need. Turns out, don’t actually need to store phone numbers, for example. Makes life easier. And for data anonymisation - if someone makes a GDPR request, then the email gets replaced with a unique hash + @redacte.d, and the IP gets salted + hashed, so that the same IP is the same hash in all entries. This is to ensure continuity in the audit trail, plus if someone gets banned for DDoSing, then does a data redaction request, then tries to access again, they can still be blocked since their IP still matches the hash (same logic as to how passwords work). I’m mentioning it since that’s the kind of details that are worth thinking about - however, it’s deep down the rabbit hole of details.

Speaking of details, if you’re thinking of mobile, then there’s also the decision of app VS mobile-friendly site. If you want an app, then it’s worth swapping to React right now, since React Native (the framework for creating mobile apps) has a larger community and is more mature. If you’re OK not having a native mobile app, then go with whatever, have fun 😁

I asked about the MVP and day to day useage since that can inform you about what order to implement things. As mentioned above, having a login page is lower priority when starting a project. For example, if based on your knowledge and the feedback from existing cooperative(s) shows that the most heavily used functionality is ex. inventory tracking, then it’s worth building a good inventory tracking system first, and grow from there. Is also why I mentioned forking an existing project - is a huge project, and if you’re going at it solo, it’s gonna be painful.

But, there’s also alternative to forking - copy-paste. Just like artists use references, developers can also reference existing code. So, for example, I don’t know if you’ve seen this sheet (from this post) for additional info how people think co-ops should work, but it’s another piece of info to consider. Though it’s Java, you can still take high level structure or direct code inspiration from Adempiere, they’ve been around long enough to make a bunch of mistakes. There’s also a fork of Adempiere, Metasfresh, which is worth looking at re: how things work. Also Tryton, though that one’s in Python. Mentioning Tryton since it also uses the party approach, and has an architecture that’s worth considering: modularity. Essentially, having the core functionality that ties everything together, and a whole bunch of “modules” that each contain their own logic, SQL, etc.

Which brings me to my last point: it’s great to work on a new project, but learn from my mistakes - think of what it would be like to maintain in 6, 12, 24, 60 months. If you tightly couple everything, all things depend on all other things, the system is going to be fragile, hard to maintain, and less likely to be used. With your background I’m sure you’re already familiar with trying to update something someone else created in a way that doesn’t make sense to you.

So yea, basically, I’m trying to caution you to KISS (keep it simple silly), and not overcommit, lest your project ends up the same way my uncountable exciting startings have ended - in some random dusty git repo, untouched for years, too big or hard or no longer relevant to finish 😅