PostgreSQL supports up through 31 which would cause a login attempt to take about 1.5 days to process on the current server. I'll probably want to re-evaluate this on server upgrades to keep that time reasonably steady.
While the web shop won't have accounts for customers (at least at first, I'm willing to reconsider if people really want that), it looks like I do want to have a login/accounts for staff because otherwise I need to give a bunch of people on staff ssh access to the server (nobody wants that) or I need to leave the back end stuff needed for order processing open to the public (which is relatively safe for the level of access I'm exposing but still seems like a bad idea).
Unfortunately while working on that I failed to realize that I was running out of time with adequate staff for me to grab a lunch so I'm pretending that an orange cream smoothie is food.
Did more work on letting the shop's web site take orders. Today I was sorting out some of the back end stuff like getting the site to send an email to me and to the customer letting us know that the order exists. It took a few iterations before I was convinced that I wasn't creating a potential injection vulnerability through the customer email field ie you don't want to do something stupid like:
system("sendmail UNTRUSTED_INPUT_HERE < /path/to/message");
I don't mind if things are primitive at launch as long as there's a minimum level of functionality available.
It still feels like I might be able to launch online sales before the end of the month. The next thing to work on is the back end stuff around letting me/staff know that orders exist, generating shipping labels, taking the money, then generating the initial set of product pages, doing more testing until I feel reasonably confident that this will work for people, and then switching to live keys for third party APIs and linking the new functionality more publicly.
Author of Typica software for coffee roasters.