Congrats! I applaud that you are productizing a barebones MVP-level application. You have initial users, definitely pay attention to their feedback. Both for technical improvements, but more importantly for any tips on how you can market this.
As many other commentators have pointed out, you face an uphill battle. The incumbents have way more features than you do and they handle more use cases out of the box. They also offer support. Still it's important to not compete on price - you need to differentiate your service, find your initial market and aggressively pursue those customers. This is more marketing than anything technical.
Some constructive criticism:
On the demo:
1. It is not clear from the demo itself if the demo is for self ordering or for waitstaff ordering. I would like to know how my waitstaff will manage multiple tables? How do I switch tables?
2. How does my kitchen or food runners mark an order as done? I try to click on the order in the status page and it only opens the accordion.
3. How do I input my menu? What is the admin panel like?
4. If I run out of fries, can I scratch the item from the menu in real time?
5. Feels like managing each location in a different instance will be a pain point for multi-location customers. I would test this assumption with market research. If the market share of multi-location users is small, and multi-location management is painful I would recommend not targeting those customers until you get traction and can afford to fix the problem or handle supporting the customers.
On performance:
My load times for the status page were about 2s - which is still too slow. Given that pupdogg experienced 4s load times, I am guessing that your backend did not handle the HN traffic spike well. Definitely look for ways to speed this up - most of your app's traffic will be concentrated within a few hours.
On pricing:
I agree with the other commentators that the pricing makes no sense.
Right now you have a freemium model, tiered by # of tables.
1. Freemium is great when you can tier by feature offerings or when you can tier by resource allocation. For the former, a SaSS will offer Single Sign On for paying users only. For the latter, the SaSS may give a free tier for personal use, (e.g. a single user account).
2. When we delineate by seats (in your case tables), we are making a bet that as the customer scales up, our product will become essential to our customer working at scale so they see the value in converting to the paid tier. This has an assumption that our customers will scale up.
as fapi1974 pointed out, restaurants don't scale up like this. Their tables are, for the most part, fixed.
Restaurants with more than 10 tables will likely not try the product, and restaurants with less than 10 won't add more than 10.
Instead a free trial makes a lot more sense. Your product is not one-shot, it is recurring. If a customer does the trial and invests the time to input their menu and train their staff then there is a good chance they may convert after the free trial ends. (in fact you can and should track free-trial usage and an leading indicator of whether the customer will convert)
I would also think about unit pricing. $219 for 10 tables is very steep. $219 for 100 tables is a bargain. However, I would guess that the market skews closer to the 10 table capacity.
Final thought. Think about how this helps your customers. Does it save more than $219 a month? Does it increase value for their offerings (probably for event organizers) When you sell to businesses remember they are economic buyers - they need it to make business sense first and foremost.
Best of luck!