Startups need to bother about scaling and automating ops at the right time. Can't be thinking about scaling ops from day one. Choose a reasonably sensible setup/framework that will help postpone large-scale automation.
BTW, don't put ops on a pedestal. In one of the startups I worked with, the ops dept became powerful to the extent of dictating what software could be hosted. Ops is important especially when you start growing, but make sure they don't supersede the dev team.
I don't think dev and ops should be separate at all. Most people's instinct seems to be that once things are big and rolling you should spin new development off from the day to day maintenance. To "Get the developers out of firefighting mode". I think that's when bad things happen. Ops can't really make any fundamental changes and dev is too out of the loop to know (or really care) what the real problems are.
I think the solution is to have the dev team spend lots of time making make things run so smoothly that they can run it themselves with just a few helpers to handle what little work can't be automated.
I agree that an ops dept. without dev inputs is not good.But the developers usually have little or no say in this. Once you get past the 2nd/3rd round of funding, you will notice management acting like, well, "management".You get an ops dept, and worst of all a 'HR' dept.
BTW, don't put ops on a pedestal. In one of the startups I worked with, the ops dept became powerful to the extent of dictating what software could be hosted. Ops is important especially when you start growing, but make sure they don't supersede the dev team.