对于基于网络的在线软件应用程序，我们在决定产品开发方法时面临困难。
我们正在致力于在线 Web 应用程序的系统设计，该应用程序有可能作为 SAAS 服务提供。我们在做出以下系统设计和实施相关决策时面临着困难，而且还需要考虑很多成本。
方法A：
我们设计和开发一切时都会考虑基本要求，这些基本要求只是满足基本要求，解决手头的给定问题，然后启动它。一个足够好的系统，可以支持几百个用户，而无需过多关注微观优化一切。
我们根据客户要求通过添加新模块来添加新功能。
因此，简单的设计，单一的开发，在必要时通过升级基础设施或在需要时进行优化来扩展，并且可能在未来根据需要用全新的系统替换系统。
我们保留相同的服务器，但为客户帐户提供不同的数据库。同样，为访问单独数据库等的每个客户端托管不同的应用程序。当需要时，我们可以添加新服务器。虽然管理/维护和升级有点困难。
方法B：
我们研究完整的需求，以及可能添加的可能增加额外价值的功能（尽管我们仍然不确定哪些附加功能会增加多少价值？）并设计支持大量用户的系统（具有大量用户）一套硬件）从一开始。
我们推出了一款功能齐全的应用程序，从一开始就进行了很好的优化。
我们设计它以支持单个数据库和应用程序托管中的多个客户帐户，并在具有成熟SAAS应用程序架构的云服务器/负载平衡服务器上实现它。然而，这使得编码和维护变得非常困难。并且需要更多时间来实施。
请注意，
我们准备好了功能列表、用户界面以及我们可能使用的技术设置。我想了解解决这种情况的最佳方法是什么。
之前我看到另一个产品开发项目，功能齐全，但完成时间太长，甚至有功能根本没有被使用。此类项目的成本考虑非常高，我更愿意采用方法 A，因为这种方法快速、简单且可预测。此外，与第二种方法相比，我很快就会收到用户反馈，这可能会帮助我决定要关注哪些功能以及原因。此外，当需要时，我们可能会重写整个应用程序，重点关注类似于方法 B 的系统。
我想了解其他公司如何处理这种情况，以及实施此类项目的最佳方法是什么。
这是经典的大设计预先（BDUF）辩论的新版本：我们应该在实施之前完成设计并完善，还是应该增量设计？
我已经看到了很好的论据支持 BDUF 和 反对 BDUF。就我个人而言，我更喜欢中间点：有必要做一些前期设计 - 否则你的设计将通过迭代发生彻底的改变 - 但这个阶段不应该花太长时间，否则你只会有一个架构文档和无聊的程序员经过几个月的工作。
所以，我将采用一些方法 A 和一些方法 B。
这要看情况。
经验法则：
不要让您的客户等待太久，运送损坏或无法维护的产品，从而吓跑他们。不要把钱浪费在你还不需要的基础设施上。
方法 A 听起来很明智……如果您也可以采用敏捷 SCRUM，则意味着您可以在 Sprint 中与客户迭代合作，您将在每个 sprint 后开发并交付产品版本和功能。客户可以看到正在交付的较小的软件单元……并且客户常常会改变他们想要的新功能的想法。
因此，您始终有机会响应客户需求，并只构建客户需要的产品。