Two of the core components of SaaS 2.0 products are actually related: API-first platform and rich, responsive user interfaces. Ever since Gmail made the first mainstream Javascript-heavy web experience that feels more like a desktop app, developers have been building open source platforms to make that type of “Single Page App” easier and faster to build. Single Page Apps reload only the portions of the screen that have changed, instead of the traditional way which refreshed the whole screen. And, these Single Page Apps work best against REST APIs, the same APIs that make a product API-first.
Now, there are powerful Javascript libraries like Angular (MVC framework backed by Google) and React (view framework backed by Facebook) that are popular with strong developer communities and a long list of additional open source projects that plug in nicely. By having quality, proven open source platforms, more apps are going to adopt them thereby applying more pressure to the legacy incumbents. The incumbents are going to have an incredibly hard time modernizing. Just like many software companies couldn’t make the transition from on-premise to the cloud, many SaaS companies aren’t going to be able to make the transition from SaaS 1.0 to SaaS 2.0, and it’ll be most apparent in the user experience.
Look for Single Page Apps to be a defining characteristic of API-first SaaS 2.0 companies.
What else? What are some more thoughts on API-first SaaS 2.0 Single Page Apps?
David Cummings on Startups 
In technology I think we’ve seen the pendulum between fat/thin clients swing back and forth several times. I think many companies are starting to realize the downsides of single page apps (fat clients) and have started to reconsider less complex clients (thin clients).
The problems that SPAs are trying to solve (rich user interaction, realtime information updates without page loads) are now becoming available to developers via other means. Technologies like Rail’s ActionCable or Phoenix LiveView (https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript) are making it possible to provide a rich user experience with a much lower investment in development/tooling/testing/qa-ing than having to maintain both a server side code base and a client side code base.
| And, these Single Page Apps work best against REST APIs, the same APIs that make a product API-first.
I’m starting to feel pretty strongly that “Public API first” has some pretty serious tradeoffs that companies fail to take into account before releasing a public api. Once a public api exists, it serves as a contract between you and your customers/prospects. Breaking that contract can inadvertently break customer/partner integrations which can result in upset customers. Maintaining legacy API contracts can significantly affect your products ability to scale/iterate/change with customer growth and needs.
I’m not saying don’t build a public api, but think carefully about the tradeoffs. Be very judicious about the information you expose, because your api contract is something you will likely be bound to for the life of your business