trevormarvin
commented
6 years ago I envision the core management to be a (internal) website, thus it is platform agnostic. The POS piece of hardware initially becomes only a kiosk for checking in and other end user functions. If built in a generic way, anything with a touch screen could utilize the software developed for it. This could allow relatively cheap kiosks to be made from RPis and touch screens, like that 7" official RPi one I have. USB card readers are not expensive, and that proxcard thing is not bad ($) either, thus a POS terminal is not that daunting of a proposition for the $ conscious organization.
There may be reasons I don't know about for wanting to keep them together, but I don't see any negatives (aside from having two separate apps) to splitting them.
Reasons for doing this include that as the POS may be an ill-suited device to handle a single monolithic application†, a monolithic app not living on the POS can't access the card reader, and you can pick different languages/frameworks for the POS front-end (possibly some that aren't even web tech‡, though I don't plan to push that particular angle).
† If something goes wrong with the POS terminal you probably still want to be able to internally administrate memberships and details. You can live without the POS for a bit if you can still look up details manually when people come in.
‡ I can imagine the POS being a tablet with a audio-jack mag-stripe reader, if you don't have an existing ex-retail POS. A lot of food trucks, restaurants, and other locations like Porter's the Caterpillar Cafe, and Growler Guys use a tablet tablets for their POS. Though I doubt "real" POS terminals will be hard to find for now...
If the service/management end is different from the POS-end, I don't mind trying to help write the latter though I'd probably pick something other than django/Python (as I'd be faster at writing what we wanted).