What possible advantage would "real" devops infrastructure provide? Unless you're doing something so far out if the ordinary (or infrastructure is your advantage) there is zero value in building your own early on.
You're suggesting they find a CTO/architect/php developer, all in one... That's not reality.
Do not take external money. The longer you can bootstrap the better. I know you've heard this a bajillion times, and I know the allure of a few mil in the bank. It's not worth it. Hold off as long as you possibly can.
We've used Google's AppEngine to scale. It's not the easiest env to work with, but at 30+ staff and millions in revenue we have yet to hire a sysadmin (ie. overhead!). When load increases we just get charged for more resources.
Sounds like you have to parallelize: start MVP rebuild, and do mitigation on current platform. Four years in we are on the fifth major rev of our core processing system; point being that things change and you need to prepare for ongoing evolution.
Exactly what you heard. Some VC's wanted the entire eng team to move to SV (not trivial if it's more than just you and cofounder) but we managed to not go there.
If you have an existing company that's been around for a bit you may want to look into L1 visas.
So... who is your customer? The card holder? The issuing institution? How much would YOU pay for this, and how likely would YOU be to give a reminder app banking access?
I'm not saying this isn't worthwhile, but as described, it's not that appealing.
So Higher Ed MOCC platforms need improvement. The original title is overly broad.
Having said that, your experience and criticism reflect many people's experiences. Just a little while ago there were some posts here about the Stanford NLP online class and the (perceived) difference in value vis-a-vis the "real" Stanford class...
You will also need a bunch of other things. To really get the benefit of automation in SF, you'll need the enterprise version. Then there are Gmail plugins (we use cirrus insight), billing platform integration, etc. etc.
Getting SF configured so it makes sense for you will take time and $. There are also a number of little gotcha's, like inability to gracefully deal with email aliases. Might not be a problem for you, but we find that a number of people use vanity email addresses, personal Gmail, etc. to communicate - and SF becomes exquisitely painful suddenly.
In short, unless SF solves a serious sales process automation problem for you, don't go there.
Ah - also, analytics. You'll want the Good Data analytics on top, especially if you're in SAAS space. Good stuff and greatly increases the value of SF.
Personally I think this one is over the top. Much prefer a more clinical version of these:
- technical explanation of the timeline & events
- what we're doing to make sure this doesn't happen again
- how we're compensating customers who were affected
- brief mea culpa/ personal apology (proportional to degree of inconvenience!!)
Keep the first three language-neutral and easy to read, and reserve emotional stuff to the end. People know you had a bad day, and how you went about resolving the issue will convey the effort you've put in.
Balsamiq will have other outages in the future, it's the reality of IT. What sort of pictures will they need for when the next outage is 3 days??