E.g. the front end registration problem is due to a late requirements change in August that had the effect of preventing window shopping, plus we know there were changes ordered though the week before launch, and no integration testing until 1-2 weeks before launch, and that discovered it locked up if 200 simultaneous login attempts were made or if it had ~1,100 users on it.
So, yeah, those are scaling problems, but not ones we can necessairly blame the techies for, given that they didn't have enough time, and couldn't do integration testing (the government's CMS was the integrator and integration tester, now replaced by QSSI, the ones who did the "data hub"? I think it's called, which is supposed to be not so bad).
But also no, in that the fix-it czar's #1 declared priority is to fix the garbage 834 EDI transactions that are being sent to insurers. That includes incorrect data and incorrect transactions (e.g. multiple enrollments and cancellations for the same person). Based on that, the front end's problems have been a blessing in disguise, because the insurers are only getting a few hundred enrollees a week and that low volume allows the insurers to call each up and straighten out problems.
An estimated 16 million policies in the individual market, and an unknown number in Obamacare's interim high risk pool must sign up for new policies by December 15th or so or they'll suffer a lapse in coverage, which for many of the latter will be fatal. The only way to get subsidies is through the Federal system, i.e. the state exchanges use it for that (maybe with inaccuracies, but it's evidently working for the state exchanges that are working, but don't judge that for any given state exchange until you find out which are getting Obamacare and the much larger numbers reported to be signing up for Medicaid), and that makes sense to avoid fraud, since it results in direct payments from the Federal fisc.