Overall, very simple and to the point but not worth $219/mo. In your DEMO, the "Order Status" page takes approx. 4.76s to load 205 orders...this seems like a very poor architecture decision or a poorly written SQL statement combined/rendering logic, especially in 2020. You are headed in the right direction though! To compete with the big guns, you'll either need better pricing or better features (including what others already offer). Make sure to do your market research beforehand or lineup a paying customer in return for significant discount. Best software is created when you have end-users using it and providing you direct feedback.

Two perspectives: I worked and coded out on alternative POS solutions right when iPad POS solutions became popular. But it's a dead end. It's too complex and resource intensive for an indie shop, it's not worth it.

For example, you may or may not have finally got this done, got it shipped, all those things are great. But your workflow and marketing are meant for tables. This is now dead on arrival.

Second perspective as a restauranteur: $219/mo is crazy expensive. I pay $300/mo to Revel and $180/mo to Clover for two different types of businesses.

With the $300/mo to Revel they process thousands a day and I have 24/7 phone support that within 2 min a live human handles my problems.

With the $180/mo to Clover they process hundreds a day and I have an easy to use, to easy to service system that I can hack into and custom build Android apps to do whatever I want.

Your $219/mo don't come close to delivering value like that.

Sorry.

We've been using uniCenta at our restaurant for 4 years (the open-source version). It's barely usable, all our employees hate it, the UX (and UI) gives the impression that all the people working on it have never actually used it themselves. It's dead-slow and sometimes you need to log into the mysql DB directly to clear some tables..

The reason why we use it? We're not in the US - there's not too much room for a commercial $$$/month solution for us at the moment and the switching costs (retraining people, integrating our custom reporting and monitoring) would be way too huge.

I'd definitely consider a different solution if I'd ever start a new restaurant (highly unlikely though - it's hell. Much harder than running a startup of a similar size :)) but I'd much prefer a % revenue-based approach (with an upper cap) than a fixed pricing model.

I have no experience with POS solutions, especially not for catering and restaurant. So tak my opinion with a grain of salt.

General: As the site came up in German, I assume you at least think of targeting this market was well. Germany made invoice copies for customers mandatory this year, on top of the already somewhat crazy requirements regarding auditability and compliance for POS systems. Quite a barrier for new systems, but from what I heard out of the local start-up scene here, there are not that many certified solutions out there yet.

I would talk to a tax consultant to get an opinion from that angle. And I would aim for official tax certification, that will make life for your customers so much easier and would be a true selling point.

Pricing: Kind of tied into the above, obviously a solution that gets tax authorities of your clients backs has some inherent value to them. For the upper range, 219 USD doesn't sound to abusive, depending on service levels and support. I would just add a couple of tiers between hte free version and the Pro one. And maybe limit functionality for the free version instead of tables, by limiting tables lacals with less than 10 tables will never convert to paying customers. And you are incentivizing toying the set-up to work with 10 "tables", depending on what exactly is a table.

I don't agree that a table based solution is dead on arrival, een if restaurants are forced to close. Sure, a delivery, contactless, solution would be great by now. But things will get to normal one day. And then an affordable, certified POS solution like yours will certainly have value.

Marketing might be an issue, so. But maybe the corony crisis akes care of that when a lot of competitors relying on VC money to get customers, well, leave the market.

On the pricing front, you may want to consider the fact that restaurants generally don't grow by adding tables. That means that with this pricing structure it will be very hard to move customers from free to paid. Your best bet is probably a free trial in this instance.

The linked page doesn't show the process clearly. Not sure about the target market, but it could be very helpful to show each step visually:

1) Print out QR codes for every table

2) Customer scans QR code

3) etc.

(or if that's not how it works, I didn't understand it either!)

I really like this, looks very nice! Well done!

Also I've heard that using establishment-provisioned tablets results in greasy screens, this solution alleviates that by using the patrons own devices :)

I have to say that I was in the early stages of designing something similar. Although POS is complex by nature I think most of these systems are pretty static. I'm curious if you had feedback from potential customers and how you got to your pricepoint. Feel free to reach out ralph.das[]gmail

Pricing for Pro looks a bit steep.

I maybe wrong though.

Adding a clear button to the product search might boost productivity.

Editing quantities from cart will also be helpful.

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!

How does this integrate with the inventory management restaurants require?

Great work. Let’s talk

I really like your pricing plan design. Hope it works well for you.

Thank you for your congratulations and taking the time to write such a detailed comment.

Yes, the demo is just the access point for guests, so changing the status on the status page is not possible. It's an information for the guest about there current orders. The interface for waiters is nearly the same, except they can choose the table at the beginning and are able to checkout orders on a table (mark them as paid).

Maybe a video with some examples would be helpful to understand the process.

Currently it is important for me to find real customers so I will definitely work on the pricing model. I also thought about different pricing models (like tauntz mentioned a % revenue-based approach with an upper cap). For starting this MVP it was important to keep it simple so I decied to use a fixed price per month. Maybe I should cut it to find real customers.