First things first. We need a full time project manager who doesn't code. We don't have to hire someone from the outside. There are people like you or Sushil who can take on that responsibility.

Define the private beta scope and control the scope. No scope creeps admissible. Having to  dish out task/work every Monday morning randomly is so unproductive. We sprint for a week, stop, then plan and sprint again.

Have an overall project plan, share it with the team and have the project manager closely monitor it on a daily basics. Having everyone code is not going to achieve our objectives. No matter how many people you put on something, the baby will still take 9 months to come out.
Set a realistic private beta launch date. Create a detailed work break down and prioritize it. Make sure we estimate the work as best as possible. Every week we slip we remove the lower priority items from the scope(work break down) to meet the target date. Am not sure if we have done any kind of estimations for the work that we are doing. We set deadlines without really estimating the amount of work.

No asking status on the public dev chats .People get uncomfortable with someone on a public chat keep asking  what the heck is the person doing every few hours. No one likes to be micro managed. Very unproductive in my opinion. For status updates use private messaging and it should be between the project manager and the developer or whoever. I don't think the entire team needs to see where the heck a particular person is with his/her  task. Yes, it does matter to the project tracking and that's what the project manager role is for. Use the dev chat to have technical discussions and not project management or task assignments. Constant chatter on the dev chat does not necessarily equate to progress, rather it is counter productive and in my opinion it is definitely a distraction.

Have the detailed work breakdown structure and assignments listed on Google doc or etherpad or whatever tool is appropriate and have the PM update it daily so that it's visible to everyone as to who is working on which portion. Steven can look at this to gauge progress. I am sure he wants to see tangible progress and I think from his perspective being involved in the dev chat helps him with that.

Create a simple dashboard where we maintain the overall progress of the project. Visible to everyone and discussed during the scrum meetings( in my opinion).
Have everyone update the project manager the % progress made at EOD on the task worked on that day and have the project manager update the overall status for tracking purposes.

Everyone on the team is a A+ player and acknowledge them for that.  Let every individual be comfortable with their area of expertise and have them contribute accordingly. I have worked with Sushil for close to 10 years now and he is one of the smartest people that I have worked with. Last week he was asked to work on JavaScript and when he raised the concern that he is not very familiar with working on that there was a laughter on the conference bridge. I don't think I need to speak for Sushil, he can speak for himself,  but I felt that the whole conversation was unwarranted. We should avoid such uncomfortable situations.

We need to ask ourselves whether the daily SCRUM meetings are useful. I work at Amdocs as a solutions Architect and  am a certified project management professional but have not been exposed to the SCRUM methodology. The daily SCRUM status meetings in my opinion are not very productive with the way they are conducted now. I am not sure how useful it is for you currently in the overall planning of the project. As you said, we are constantly missing targets and we need to work out a strategy that helps us set realistic deadlines and better tracking of the progress being made.

With proper planning we can avoid being in the constant firefighting mode. I like the saying which is appropriate here, firefighters are sometime our worse arsonists.

Have Steven define roles and responsibilities. Sushil, has been hired as the VP of engineering. Have him take the lead on that. I am not sure what the heck he is doing trying to learn javascript. A total waste of talent in my opinion. Let him set the engineering goals for the team. Tim, has been hired as the interim CTO. Let him define the technology direction and take the lead in the overall architecture, technology stack of the product. It's not the CTO's responsibility to dole out tasks to everyone on Monday morning. Stay out of scheduling, status updates and task assignments. To be honest I am not very sure what your role is.  During the team introduction I thought you were introduced as the product manager, then you have no business managing the schedules and/or trac. Your responsibility should be purely setting the product direction,product details in consultation with the project sponsor (i.e. Steven). If your role is that of a "Program Manager" or "Project Manager" then you need to get more active in that role and step away from coding.

Quality Control: We need a testing and bug tracking strategy in place desperately. Currently we are using trac for development task assignments. We need to have someone test the product at every iteration and register bugs and have the project manager prioritize it, assign it and schedule it in the code drops. If we don't have the testing expertise then we should look to the outside and get a team that can help us with that.

Design: Before embarking on a major piece of functionality it will really help to spend  a day or two having the architects work on the overall design of the solution. We don't  have to start coding the moment there is a requirement. We are having solutions discussed over chat and decisions being made in haste. To me it's not good enough to make it work for the advisory meeting. We are designing and developing a product. If we are not ready then lets not make a hack and present it to the advisory board. We can make it look nice superficially but whom are we fooling here. There  were so many shortcuts taken, hacks everywhere to get things working for the meeting. I am not sure if that functionality was even shown at the meeting. Total disaster in my opinion.

Create a design template. Have the architects/designers write down the design of the solution. Doesn't have to be elaborate and shouldn't take more than a few hours but it is needed for posterity and overall understanding of the architecture. I can help with this. We are a start up and I realize the need to be nimble but we have to be smart nimble.

Review out development environments. We have a sandbox that has a commit hook on it. Every one checks in and Steven and everybody else wants to test on it. Not very productive. Sometimes I worry to do a check  into sandbox cause of the fear that I might break something and jeopardize some freaking demo. We need a staging area that gets updated based on code drops. Let the VP of engineering and the Project Manager decide the schedule of the drops into the staging area and the move to the production area. If things are broken on the sandbox I don't have to worry about a demo that might be impacted. All pieces of the software needs to be replicated on the sandbox, staging and production. Testing needs to happen on the staging area. It should not be linked via the commit hook. No product testing (other than those by the developers) will happen on the sandbox.