Just looking at the numbers, I'd be hesitant. Perhaps others can suggest how the risks I see could be mitigated.
WebDirect is going to allow up to 100 concurrent connections (for which you'll need licensing on your server). This means that, if there are 200-300 sessions per day, they'd need to spread themselves out.
- Are the times that customers would log into the site truly random, or are they all likely to, say, log in at the end of the day, or even a couple of common times per day, and hit your server all at the same time?
- How damaging would it be for a customer to not be able to log in because all the concurrent sessions were taken up? Are they patient and understanding?
- How static is that "200-300" number? If this goes really well, are more customers likely to come on board?
- How are you going to ensure that your sessions get logged out? Are they going to get aggressively logged out when idle? Can you train them effectively and sufficiently to log themselves out explicitly, so that when possible they'll free up a connection even before they get automatically disconnected? Remember that unlike CWP, the session stays open until the user logs out or gets disconnected, so if the user forgets to log out, even a "quick in and out" can end up locking a connection until the user gets disconnected.
My opinion, just given what you've said and the concerns above, is that WebD isn't a good fit for this, and the extra work to do CWP may be warranted.
I'm reminded of the time years ago when I used IWP (which was pretty new, then) to set up a simple "sign up for our email list" page. Similarly, traffic was expected to be minimal, and things went along fine for a while... Then the client went to a (really successful!) trade show where they met a few thousand people and encouraged them to sign up for the email list. A huge portion of those people went home from the trade show (or even just back to their hotel rooms) and faithfully went directly to the web page. Things went, shall we just say, horribly wrong, and those potential clients were not very forgiving, nor understanding.
Having finally gotten over my general hesitation (OK, I'm a bit change-averse, myself ) and rolled out a few WebD solutions, I'm a big fan. For example, we're using it for a maintenance crew for one of my clients, to do work orders, and in a couple of days we set up a fairly complex interface, with a lot of rules, that had been challenging and error-prone with CWP for nearly a year.
Still, I don't think I'd use WebD for anything that could be remotely described as "outward-facing". You know how many internal users there are, and even if something goes wrong, you have a line of communication with them. With the outside world, you don't really have any effective control over traffic, and that line of communication is possibly not even established yet.
Still and all, just my opinions and concerns. I look forward to what others think. If there are ways to mitigate these risks that I haven't thought of, I'd love to find ways to expand our use of WebD into other scenarios.
you did not mention what version You're running. 'Unlimitted' might be a V13 - and with WebD 13, I don't think that this will be running fine.
it will be depending on Your setup as well (one machine won't probably be enough) and hardware
for WebD14, others will chime in
Thorough feature- and stress-testing is strongly recommended. Also consider testing with a limited number of known customers in order to gather acceptance information before doing the big rollout.
I developed a solution in WD and had some quirks with layouts that worked fine in FMP but encountered dead layout objects once called in WD. Testing, testing, testing.