These three factors - quality, time, and cost are the same for software as any other product or service. In most cases, two out of three will be favorable (meaning high quality, done quickly, for a low cost). On many projects, quality and fast are not achievable, for any price, unless the team can quickly find and integrate good components.
To address this, a prototype may be developed quickly to demonstrate a concept, but the risk there is that the prototype will become the end product. That’s fine if the prototype is robust enough to work.
I think the best strategy for building a system where you need all three is to focus on the foundation or architecture, limit the functionality, and use that to build on. It takes money to make money, someone will have to be paid to develop the system. If you abandon quality in favor of time and reduced cost, you may attract enough interest to fund a new system, but you risk being labeled as a low quality provider, or being saddled with code that is difficult to work with.
Research and development prior to production engineering is almost always worth it. It can be skipped if you have alot of experience.
Often, regardless of the plan, version 1.0 of a system is almost entirely discarded and replaced eventually. This is an argument in favor of a rapidly developed prototype that looks okay and functions reasonably well, but is deliberately intended only for short term use. Another approach is to focus on the system architecture more heavily so that version 1.0 may be discarded, but the underlying architecture remains. This may be a better long term plan.
Web software seems to have about a 3 year lifespan. The technology is changing so fast, and the way people use the web is changing so fast, that even an excellent site needs to be built with an eye toward adapting to future requirements.