PaaS and services like Parse are the next normal. The work you're describing is called manual labor and where possible (aka the 99% use-case) it will be replaced by better technology.

I remember the same claims being made in the 1980s and 1990s about technologies like HyperCard, PowerBuilder and Visual Basic.

There was all this hype about how they were going to render C, C++, Pascal and COBOL programmers obsolete, because they'd let non-technical folks build production-grade software systems with ease in record time.

Of course, what ended up happening is that this didn't hold true at all. Most apps developed by non-programmers were quite limited and terrible. Anyone stuck with such apps often had to bring in actual developers anyway. Unfortunately, the developers were now stuck using rather limited technologies that often took longer to develop with than if C or C++, for example, had just been used in the first place.

Any serious software system will require lots of custom code, and this only comes about through the efforts of actual software developers.

I think PaaS's are a pretty natural next-step on the evolution of hosting which is a lot more specific and smaller in scope than "programming" - the stuff they abtract away from you is for the most part just a timesink and chore that has between negative (salaries & exploits & downtime) and limited (bang for your buck, ram, disk io) benefit to do yourself.

Parse takes that model another step forward and just addresses the most common use case - CRUD applications that an experienced developer could create in their sleep but haven't we done that enough times already?

There will still be occasion when your own server/s are the best or only option but fewer than today's developers want to admit.

Obviously, startups need to scale at some point, and to do that they need experienced backend engineers. However, when a startup is still searching for product-market fit and doesn't have an influx of users, it doesn't make sense to spend a lot of time and effort attempting to build a scalable backend that probably won't scale anyways. With cloud code and now integration with Express, there are almost no performance tradeoffs to using Parse for most early stage startups.

In certain situations yes, in general no.

Its just not that hard to do a 'serviceable' back-end behind a simple rest API. I mean how many hours is that really going to take you, especially when you consider in the case of parse users they already know what data entities their application uses? A REST API for a dozen or so already defined entities, maybe a weeks worth of work? And then look at what it buys you, actual control over your data, ability to move from parse and pursue cost cutting alternatives, ability to do in depth analysis of your data...

I absolutely think Parse has great value, but when the statement is made that in general it might replace back end engineering for startups... its just wow man. This is precisely why a person who understands the server side of a client server application should in general always be involved if the business is based around client server applications.

1 week is eternity for a startup. A custom backend not only adds time to the initial build of the product, but it makes iteration increasigly complex. What happens if you restructure the product and kill half your features? Rebuild the backend yet again?

The only thing that matters for a young startup is finding product-market. Parse makes that process more efficient than ever.

A person who understands backend engineering would understand the value that Parse provides.

Even a mediocre developer should be able to put together a workable prototype of a simple web app and/or API well within a single week, including setting up web servers, databases, and other basic infrastructure.

Experienced developers are often much faster and more efficient. This is especially true if they're using a language like Python that is quite suited to prototyping, and already offers so much pre-made functionality in the form of libraries and frameworks.

Many of us have learned to be very skeptical of these services that claim to allow software systems to be build rapidly. This often only holds true in a very, very small set of cases. Otherwise, the moment you try to do something unique or unusual, you'll hit one roadblock after another. It doesn't take long before the supposed "time-saving" or "effort-saving" service has wasted more time and effort than it would have taken to develop everything from scratch.

I just had this discussion with my friend today. While it is true that building a simple simple api from scratch is pretty quick, the hack-it-super-quickly api gets really hairy really quickly. Later you have to spend a lot of time refactoring to make the API scalable and easy to add endpoints and functionality. And usually you realize you have to refactor when the poop starts hitting the fan and the hacked together solution isn't holding its weight anymore.

That assumes three things. #1. Product category that fits Parse (obviously if you are dependent on machine learning built on postgresql, might not be a great fit). #2. A start-up that is comfortable with that level of dependency and lack of internal knowledge. #3. A startup who considers the bulk of their value to be in interface or first-move network effect advantage (else, company Z will clone their app using parse in a few weeks after all the hard learning is done).

EDIT: For the record, I really like Parse, and am a paying customer for two CRUD mainly products.