我们餐馆需要一个点餐网站，具体需求如下：
需要自己独立域名的网站，中英文双语，客户可以切换语言；
支持电脑浏览器，手机浏览器，最好还能在微信上使用；
订单能够自动打印出来，最好能够直接打印到厨房打印机；
能够生成销售报表，最好能够在手机上查看订单和报表，还能打印报表；
方便注册，最好可以用手机短信验证后直接注册；
客户可以用现金见面付款，信用卡，微信或者支付宝付款；
一次性开发预算不超过$3000或者按照订单分成长期合作；
我公司有类似符合要求的产品，请问你的餐馆地址在哪？
帮顶，3000美金不够
我们做这个，但是你这点钱不够
开发一个这些钱可能不够，但是可以开发者可以卖给多家呀？域名变一下，各家菜的内容不一样，其它的不都是一样的吗？
这样的系统从设计到开发至少100K。
已经有了研发好的产品，给客户上系统成本vs报价至少要到1比3才能有利润
3K的价格光够一个普通员工一周的工作时间，一天了解他们餐厅需求，一天设计具体方案，一天上完系统客户验收，就剩两天工作时间了……
按我自己当年做consultant的报价，3K就够我给他们干两天活……
模版还有佣金呢，这一次性的怎么可能这么便宜，大集团都是定制的
“外卖入单系统”
我用 Google 查一次，这是第二个高处的搜索结果：
http://daloben.co.uk/index.php?r=site%2Fproduct&id=30
我过去常看 “华商报” 和 “英中时报” 的时候，上面不是很多开发好的系统在卖？哪用3000英镑！
外卖入单系统和餐厅下单网站是两码事{:5_129:}
不同功能的网站开发成本上系统成本差别很大。
比如一个简单的网站下单系统，可能到Wix网站套个模版几天就能弄好，连数据库都用不上。
但楼主要用户注册，销售报表生成，各种支付都支持，这个必须要有后台数据库挂钩，还得有网站界面，用户界面，管理员界面以及第三方支付插件，复杂程度比前者多了不止一个层次的。
对于外行来说，两个网站可能看起来复杂程度一样，但其实后台复杂程度完全不同。
比如我自己的网站吧，我们的主网站是www.smartpostcode.co.uk,这个从设计到连接域名，我就是拿wix模版一天做完。
我们的subdomain， webapp那块，app.smartpostcode.co.uk我自己写的，不算后台架构数据库什么的，光网站前端就花了我整整一个月。
我一个朋友，自己做中介的，想找人做个类似rightmove的网站，这个比楼主的要求还要简单不少，收到的报价是50K+
我十几年之前的毕业设计就是类似这个方向，可复用的信息管理/处理系统，当初还是基于win app的。
从软件角度，复杂度跟工作量楼上基本说的都差不多了，概括起来就是一句话，这个预算就是做梦，加个0都不见得做的下来。从运营角度，这类系统面向的对象是中小型商家（e.g.没钱没技术做自己系统的），所以即使有那么一套系统能用，运维部分恐怕商家也未必能够搞定（网站不是挂出来就不出问题的，没有sla保证的裸奔网站会出什么问题只有你亲自经历了才会明白;P），这样算最佳运营方式其实应该是托管，那么就不可能是一个一次性的费用，而是类似于subscription，或者楼主提到的按比例分成。
这种持续收费方式的挑战是，subscription的话，中国人的心里普遍会觉得贵/亏，甲方会觉得不划算（感觉就是一直在交钱），按单抽成的话，如果下单量少，抽成不足以cover服务部署运营的费用，乙方肯定也不会答应。所以我觉得最佳的方式应该是base rate + 按单抽成，base rate cover运维（+乙方的少量利润），按单提成的部分则作为乙方的纯净利润。这样甲乙双方都会有动力去想尽办法尽量提高销量的:lol
“用户注册，销售报表生成，各种支付都支持，”
销售报表生成，外卖店现在也有了吧？感觉难点就是 “各种支付”吧。
“我一个朋友，自己做中介的，想找人做个类似rightmove的网站，这个比楼主的要求还要简单不少，收到的报价是50K+”
哪个中介要是想自己家做一个 rightmove 一样的网站，估计当时是睡糊涂了吧。
那就加个零，10倍的。你做好了，可以卖给100家呀！
po主说3k是含带了这个一个bespoken项目的前提的，如果是现成品让他决定是否购买，你觉得他还愿意出这个3k的价格么？以我对中餐馆老板的认识，我觉得未必有人愿意出这个价买，更别说我提到的用年费的方式了，能接受这种运营/支付方式的未必会很多。
就算真有，去找100个客户，并且维护这些客户关系也是要时间/成本的啊。可能这事真的有市场，有盈利空间，但起码不是这么简单的计算啊。
我个人觉得报表生成其实没太大意义，因为除非所有订单都通过这一个接口实现，否则统计的只是部分营业额啊，电话单，上门的单的部分怎么算？
支付反而简单，目前市场主流的支付服务商无非那么几家，每家的API实际都已经非常成熟跟规范了，真正实现这部分，连同测试代码跟接口文档，顶多也就是3-4天的工作量，加invoice/receipt跟VAT稍微麻烦点，但一周以内支付肯定做出来了。
你说的是单机软件系统，我说的是集成了这些功能的网站，这是两码事。
网站类产品开发，难度跟交互方数目交互程度成正相关。
比如光网站订餐的话，这个是很简单的。但要加用户注册，用户界面，难度就会增加很多。
而且用户界面要显示历史订单吧，否则用户注册有什么好处。这样难度就又加了。
楼主要做的是多找几家问问，看这个预算能做到什么程度，把不相关不重要的功能给砍了，
对了 房屋中介自己带rightmove类搜索功能挺多的，
https://www.leaders.co.uk
https://www.purplebricks.co.uk/search/property-for-sale
rightmove的网站基本是十年前的水准了，没什么技术难度。
如果这些功能都在网站上集成了的话店面现金可以让员工通过管理员账户下单，order支付方式现金支付就好。
原来第三方支付还挺简单的，GDPR出来后，即使支付转第三方页面，也有cookie保留用户支付信息的问题。
现在GDPR出来不久还没人管，但过个几年估计就是个问题了。这个在传统PHP架构下我还没看到比较好的解决方案。