Emerge Interactive: Digital Product Agency

Today business leaders across every industry are taking a step back and revisiting everything they do, from internal systems to customer interactions both online and in person. Teams are tasked with creating and delivering digital transformation solutions that empower employees, engaging customers, optimizing operations, and transforming products and services.

While the ask in many cases is simple, delivering a successful digital product internally or to market is an entirely different story. You need a way to quickly test your ideas, validate them and ensure the intended impact. This is where a minimum viable product (MVP) comes in.

MVP (Minimum Viable Product) is a term that is thrown around a lot these days, but is a widely misunderstood concept with a plethora of different definitions that range from the smallest possible experiment to test a specific hypothesis, to the tangible realization of a product vision.

At Emerge we define MVP as the best solution that meets the needs of the target audience, with the least amount of risk, while conforming to all the known constraints. It’s the first step towards achieving your long-term digital product vision. This thinking is based upon decades of experience and influenced by industry thought leaders like Marty Cagan and Eric Ries:

Marty Cagan defines MVP as the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; we can deliver it when we need it with the resources available. This is also known as valuable, usable, and feasible.

Eric Ries in his book Lean Startup defines MVP as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Many organizations use the term MVP to mean the lowest cost option of delivering the product, or a reduced feature set with less functionality, or version one of a complete product or service solution. With so many different interpretations, your team, like many teams, may find themselves challenged to manage expectations, scope, and resources effectively. 

The first step towards a successful MVP is aligning on the definition and your intention. 

What is a Minimal Viable Product (MVP)?

One of the best ways to understand MVP is to see the concept visualized.  The following image by Henrik Newber illustrates agile and lean product development: 

The illustration captures the essence of iterative and incremental product development using the metaphor of a car. Taken out of context however, some significant assumptions may be made that could steer you down the wrong path. It is also imperative not to be fooled into thinking that “minimum” means “easy”. Determining an MVPs top priorities, identifying the core feature set, and asking the right questions along the way is an important part of the process. Let’s breakdown what each part of this illustration represents. 

• The top row illustrates a common misconception about iterative and incremental product development, that is often the reason so many projects fail.  It focuses on the components in an incremental way instead of the problem to be solved (a.k.a job to be done). Let’s look at this from the user’s point of view. If you deliver a wheel to the end user does it address their need or problem? Is it a valuable, usable, and feasible solution? What insights or feedback could the user provide that would help inform the development of a better  product? With each iteration, you are getting closer to delivering a solution, but still addressing the end user’s need, or problem. This approach is another way of looking at delivery of a complete product. It’s not until the fourth incremental delivery that a solution is viable to the user. This approach, while agile, doesn’t allow for the opportunity of user feedback to refine the solution. This opens your product up to risks like user (market) adoption challenges, design, and technical debt, to name a few.  
  
  
• The middle row illustrates another common misconception about iterative and incremental product development when it comes to defining and delivering a successful MVP. In this example, we start with the same contextual metaphor of a user who needs a car. In this scenario, the focus is on the problem, getting someone from point A to B as quickly as possible. Each iteration (1-4) highlights a possible solution. This approach allows you to validate, and invalidate your hypotheses, to define the solution space, to quickly develop proof of concepts and prototypes. 
  
  To be clear, a Proof of Concept (POC) is the pilot project or experiment, which demonstrates an idea, product, service, process, design concept, or integration point (i.e. software to hardware) to ascertain its feasibility. It does not, however, directly address whether this thing is valuable or usable for a user. 
  
  A prototype is an early interaction, model, or release of a product built to test a concept or process. There are many methods of prototyping and when and how it can be applied to the product development lifecycle. A prototype may be used to determine if a product is valuable, usable, and feasible early in the process depending on the approach and the stage of the product development lifecycle.
  
  Let’s look at this approach of the middle row from the user’s point of view. If you deliver a scooter to the end user, does it address their need or problem? No. Is it a valuable, usable, and feasible solution? No. So did we solve the right problem for the user? Is each iteration an evolution of the product or a different product altogether? While this approach allows for user testing, feedback, and refinement of the solution, it doesn’t address the fact that our user needs a car. Although a valuable approach to define the appropriate solution space for the focus of your product team, this does not deliver on the intention of an MVP.
    
• The last row illustrates the approach to MVP (minimum viable product). Continuing to use the car metaphor, each iteration is a refinement to the solution that meets the needs of our prospective user. From the first iteration, a user is presented with a solution that meets their needs, providing a minimum viable product that is valuable, usable, and feasible. It is anchored to a strategy, not just an idea aligned to solving the problem, but producing the desired outcome for the user that can be iterated and improved upon.  Typically, the MVP is targeted to provide sufficient functionality and value to appeal to early adopters, enabling further iteration, and eventually scaling up of the product or service to the majority of the market. 

Benefits of the MVP approach 

The three most significant reasons new products and business’s fail are the lack of a market fit, running out of cash, or having the wrong team. At Emerge this amplifies the importance of implementing the right MVP approach, and maximizing the viability of your investment. Taking the right MVP approach was crucial to the success for one of Emerge’s recent clients: The initial digital product we helped to create quickly validated the investment and unlocked millions in previously untapped revenue.

If those aren’t compelling enough reasons or example, let’s explore five of the benefits in more detail. A minimum viable product can provide:

• Insights – Gather preliminary insights to validate if your product is successfully addressing a need or solving a customer problem. This also provides invaluable insights early in the process that can enable you to proactively pivot, dramatically shift focus, or even move on from the product while the investment is within an acceptable risk level.
• Value Proposition – Bring focus to defining the product’s core value proposition and differentiates it from alternative solutions available to the customer. By focusing on MVP, you are required to clarify the value you are building, and ensuring it aligns with your larger strategic vision. 
• Co-Creation – Involves customers as quickly as possible in the early stages of the process. It informs the prioritization of features and functionality on the product roadmap.  Co-Creation facilitates focus on continuous improvement of your product and building stronger relationships with early adopters, the refinement of your value proposition, and helps to inform decision making.   
• Rework – Significantly reduce potential rework, or abandoning features that go unused by quickly validating the product experience, value delivery, and market fit.  Great research, user experience design, engineering, and testing can’t replace feedback of a product in the market from your users. 
• Speed to Market – Increase the velocity at which you can deliver value.  Taking an iterative approach to product development lifecycle enables product evolution, focusing on essential elements of your product or service. It also allows you to refine the business functions that are essential to supporting the success of the product and unnecessary costs. 

Tips for Defining Your Digital Product MVP 

• Defining the MVP of your digital product or service starts by aligning everyone on your team. This includes the top of the organization to everyone working on the product or service.  It informs both internal and external team members on the why behind the product, the intended outcome of your MVP, and the known constraints (i.e. customer insight, time, money, capabilities, etc.). It is imperative to have this shared understanding from the beginning. With this understanding, information, and thorough product discovery process you will be able to identify the right approach to your MVP. 
• A successful MVP doesn’t always equal product market fit. When developing an MVP, you are targeting early adopters and it’s rare to get it all correct the first time out of the gate. It promotes validation and refinement of the fit. As you set your goals, confirm that you are clear about this, as it will help to manage expectations. 
• Don’t prioritize in silos. Each key discipline has an important point of view in the prioritization process. From product management, to design and engineering. All respective disciplines bring a different point of view and a different skill set that will inform the success of your MVP. 

Methods for Prioritization

There are many common practices that can be used to prioritize the features and functionality of your MVP. Regardless of the chosen approach, it is critical that the team not lose sight of your goal, the problem, the opportunity you’re addressing, the context of the user, and the intended outcomes. Here are three popular methods summarized:

• Priority Matrix: At Emerge we often use a prioritization matrix with small to mid-sized projects where we can relatively easily divide features into two oppositions: ‘important – unimportant’ and ‘simple – complex’. Each feature is plotted against two axes = ‘business value’ on a scale of 1 thru 10 and the estimated ‘level of effort’ on a scale of 1 thru 10. There are two important distinctions that should be noted: First, when we talk about ‘business value’ we’re talking about addressing a need of a user that if satisfied will increase revenue, provide a cost reduction, and will provide a cumulative benefit, or mitigate risk. Second, when we talk about ‘level of effort’ we’re talking about the time, financial investment, effort, risk, and complexity of delivering the need of the user. Here’s an example of what that can look like: 
  
  
  
  For mid to large-sized projects you will have to have a clear picture of the independencies of each feature, which is necessary when ensuring that you can fulfill user stories and target outcomes. This method, in combination with the Opportunities Solution Tree, can be exceptionally effective. 
  
  
• MoSCoW Analysis (a.k.a The Bucket Method): Another method we use frequently at Emerge is MoSCoW. The term is an abbreviation for the prioritization of features into four buckets categorized as: ‘must-haves’, ‘should-haves’, ‘could-haves’, and ‘won’t-haves.’ The MoSCoW method is a technique used in business analysis, project management, and software development to reach a common understanding with everyone involved. It clarifies the importance they place on the delivery of each requirement.  Based on its simplicity, MoSCoW has become a popular method to employ.
  
  Successful implementation of this technique is contingent on the clear and firm distinction of the four categories, and alignment on the importance of each feature through the iteration and refinement of your product roadmap. To avoid some common pitfalls of this method, you must have a shared understanding of the rationale for ranking priorities, and the method for reconciling competing priorities.  It is crucial that features requiring continuous improvement are always taken into consideration in this process.
  
  Must-haves are critical to delivering a successful MVP. Project delivery should be considered a failure if even one “Must-have” is absent. Without this feature the user can not achieve the intended outcome and its intended business value. For larger projects, MUST can also be considered an acronym for the Minimum Usable Subset.
  
  Should-haves are important but not necessary for successful delivery of your MVP. While Should-have requirements can be as important as Must-have, they are not vital. 
  
  Could-haves are desirable but not necessary and could improve user experience or customer satisfaction with a low level of effort. These items tend to have minimal impact if left out of the product. These will typically be included if time and resources permit.
  
  Won’t have (this time) are agreed upon as the least-critical, lowest-payback items, or not appropriate for MVP. These features are still important to document for the team’s proper expectations and understanding as they may be reintroduced later.
  
  
• The Kano Model: This alternative method worth considering is a powerful approach to prioritizing your MVP, evaluating your features based upon the satisfaction and sentiment of your target customers.  Professor Noriaki Kano first introduced the Kano Model in the 1980s, focusing on product development and customer satisfaction. 
  
  
  
  The approach classifies customer preferences into five categories based upon the response to two questions. How does the user feel if the feature is present? And how does the user feel if the feature is not present?  The approach promotes an understanding of the customers’ point of view in relation to a product’s features. The responses to these two measures will fall into one of five categories: Attractive, Performance, Indifferent, Must-Be, and Undesired. 
  
  If you are going to consider using this approach, I highly recommend you also read Daniel Zacarias explanation of the Kano Model as well as how to implement and fully utilize it. He provides an insightful overview and deconstructs the methodology and application of this approach step-by-step. 

Rock Your Digital Product MVP 

Establishing a shared understanding of MPV and the right approach enables you to prioritize the right things. You can proceed to maximize the benefits of your MVP approach at each iteration. With focus,  it is possible to more effectively navigate the entire product development lifecycle and make more informed decisions. 

Each prioritization approach has its place and can prove to be immensely beneficial. But, there are no shortcuts when it comes to prioritizing the right things. The process of gathering continuous feedback and refining your product or service is the core product management. This practice is not only about creating something customers need or even love.  It is a business practice that delivers outstanding solutions. 

According to Gartner, two-thirds of business executives believe they must accelerate the pace of digitization to remain competitive. Those leading are shaping their enterprise mobile app strategy to create digital products that improve the customer or employee experience.

This is why we believe you should learn more about how personalization, wayfinding, and location based services can transform your business’ digital products and applications. In partnership with Aruba Networks, the industry leader in wireless networking solutions for today’s experience edge, we will explore these opportunities and how to approach your initiative to deliver successful results.

Watch our webinar to learn from industry leader Nick Newton with Aruba Networks and our team at Emerge to discover how to:

• Deliver personalization for your employees or customers in your app
• Unlock user insights and apply that knowledge to your product roadmap
• Learn about the latest user experience strategies and technologies that can transform your business.

Fill out the form below and learn about the latest user experience strategies and enabling technologies that can transform your business!

As the owner of a digital product, you know that the requirements for your product will evolve over time. This creates a challenge in how to build a product platform that can scale over time to accommodate new features, different user loads, and changing technology standards. Frequently, this challenge is not addressed appropriately. Without a long-term product platform strategy, platforms will either need to be rebuilt from scratch prematurely, or they become stagnant and ultimately relegated to legacy products. This is often further driven by the pace of business transformation, accumulation of technical debt, and shortcuts taken during the original inception of the product.

Another common quandary today is the speed at which supported devices and peripheral applications (commonly referred to as application endpoints) must change. Traditional product design is device-centric, but today’s marketplace requires companies to be device agnostic. In the age of omnichannel engagement, a single platform may have to accommodate a myriad of endpoints, including responsive desktop websites, progressive web applications, native mobile apps, React Native apps, and smartwatch applications. This is equally true when we think about internal facing endpoints, such as CRMs and other business systems, extending across the entire value chain. It is critical that a modern product platform is built in an adaptable and scalable way to allow for any new devices and clients that will be introduced in the future.

I will outline three key paradigms that may be utilized when planning your product platform strategy for scale. Implementing these paradigms may increase your competitive advantage, business resilience, improve risk management, and increase your capital for growth.

1. Understanding the Lifecycle of the User Experience, Application, and Data Layers

When planning for the long-term, product teams need to consider that their applications are typically built in a way that allows separating them into discrete components, each with its own purpose and lifecycle:

• User Experience Layer
  The user experience layer of an application entails all the display logic as well as any endpoint/client-side application functionality. This is the part the end-user sees. It must adapt to the rapidly evolving browsers, devices, and UX paradigms. In the example of a ridesharing platform, this would be the driver and rider mobile apps, as well as any account management or administrative web interfaces. The life cycle of this layer is 1 – 3 years.
  
  
• Application Layer
  The application layer typically contains all business rules and logic, ideally embedded within an API-first architecture. This codebase will primarily live server-side. In the ride sharing example, this would be the logic that handles user authentication, assigns riders to drivers, calculates travel costs and durations, and handles the data transfer to all endpoints. The life cycle of this layer is 3 – 5 years.
  
  
• Data Layer
  The data layer contains the application’s data, which typically resides within a database or other data storage system. In the case of the ridesharing platform, this would entail all rider and driver data, ride history, and payment information. The data layer’s life cycle coincides with the business that it serves; as long as the data is relevant to the business, the data layer will need to be maintained and supported. Consequently, the life cycle of the data layer is often 5+ years. The most adept enterprises take the approach of data-as-a-service, consolidating and organizing their data in one place, then making it available to serve new and existing digital initiatives. This unlocks data from legacy systems to drive new applications and digital platforms, without the need to disrupt existing backends.

By looking at your applications from this angle the door to modularizing your scaling requirements opens. For example, having the foresight that the user experience layer will likely be replaced within a couple of years, you wouldn’t want to expend comparable resources establishing your user experience layer for scalability as you would for the other layers. Conversely, the selection of the data layer must allow for substantial growth and change in content, laying the foundation for your platform to scale.

2. API-first approach

One of the most useful developments in modern software design is the emergence of API-first software architecture. Historically APIs were created as an afterthought to existing products that were tightly interwoven jumbles of front- and back-end systems. An API-first architecture strategically decouples them from the onset. This allows teams to quickly create experiences and products which work across a multitude of devices and other end-points.

In API-first methodology, all components of the platform are primarily connected via APIs, using API calls for data transfer. Designing an API involves consulting with stakeholders to collaboratively design the API specification before determining and developing the various applications that will consume the API. A major benefit to this approach is that organizations obtain valuable feedback in the preliminary stages of the platform’s design. This is beneficial in developing a service that delivers value to all of the API’s eventual consumers across the platform. Further, it ensures that consistency is administered across the platform, which is crucial considering the variety of clients/devices that will potentially connect to the API.

There are two ways to approach API service design, each with its unique implications on application scalability:

• A single generic API
  A generic API is written in a way that provides access to the most data possible without imposing specific business rules on data access. This provides long-term flexibility by covering the data needs for as many business use-cases as possible. Typically, it is also easy to build, and in some cases may even be automatically generated depending on your data entity model. The downside is that a significant part of business logic is shifted to the client/device, making it more difficult to maintain consistency of that business logic across clients. The client essentially embeds business logic in the user experience layer.
  
  
• Specific APIs (microservices)
  By writing an API that covers specific business rules the application logic can be embedded in the API. This allows the client/device to primarily handle the user experience layer and remain a de facto “dumb” client/device. The drawback with this approach is that different clients might require the API to be modified to meet their specific needs, or new APIs to be created for new endpoints.

Ultimately, either approach may facilitate a successful migration to an API-first platform.  But, keep in mind that it is advisable to dialogue with your team at the onset to determine which API-first platform option best aligns with the projected long-term requirements of your platform.  

3. Five Pillars of Product Platform Strategy

When planning for a new digital product platform there are many technologies to consider. To ensure a solid foundation for your platform to scale from, we evaluate them in five categories:

1. Performance
   Depending on your platform requirements, the platform’s systems should have high availability while being cost effective and resource efficient. Modern cloud hosting environments offer a variety of solutions that work better for some cases than for others. Find the right combination, and you can achieve exceptional performance at a relatively low cost. 
   
   
2. Scalability
   Is there variability in your expected user load? If so, how well can the systems adapt to the changing user load? If you have a customer-facing application that will encounter heavier demand over time, this will be of more concern than if you are serving an internal, predictable user base. When you do need to scale the platform’s systems, you want to ensure this can be performed with minimal downtime.
   
   
3. Maintainability
   Over time, your systems need to be maintained to remain competitive with technology standards and security needs. Depending on the system operations (SysOps) and development operations (DevOps) capabilities of your team, you will want to carefully consider if managing the platform systems yourself is the right choice. You may determine that relying on a Platform-as-a-Service (PaaS) provider is a sage decision.
   
   
4. Compatibility
   As your platform grows how easy is it to add new applications and components? Adopting an API-first software architecture will further ensure modularity. In particular, a microservices approach lends itself well to adding future application functionality without the need to edit the core application code. This means new functionality can be added without the risk of introducing bugs into the existing application.
   
   
5. Security
   Following security best practices, such as the OWASP Top Ten, should be requisite, yet there are  a multitude of factors that come into play when approaching security for scale. For example, maintaining your own authentication system may make sense if you are starting out, but in the long run, do you want to be responsible for the personally identifiable information (PII) of all your users? Outsourcing such important responsibilities to a company specializing in authentication security, such as Auth0, could be a better choice for future scalability. When protecting against DDoS attempts and other hacking threats, a service such as Cloudflare can offload responsibilities from your team and future proof your products are they grow in popularity.

The approaches outlined in this article provides an overview of how our team at Emerge helps ensure our clients’ product platforms are designed and developed in a way that allows for future scalability. You can see an example of our product platform strategy at work in our case study for the Mercedes-Benz CLA Instagram Campaign. If you find yourself needing a hand with your digital product platform strategy, feel free to reach out.  We’d love to talk.

When creating a mobile app or web application, do you have a strategy for how the static content in the application is managed? An app can contain a myriad of static content that wouldn’t make sense to load dynamically from a database or server each time the content is viewed. Some types of content that fall into this category can include:

• Home screen content
• Inline content blocks
• Navigation labels
• About us page content
• FAQ sections
• Video sections
• Product information that isn’t stored elsewhere

This is a challenge our clients encounter regularly, and we love helping them solve this problem.

Why should you use a Headless CMS?

Traditionally, a mobile app or React application will have its static content embedded directly inside the application code. For apps geared toward traveling users or display kiosk applications that need to run locally, this is particularly true.  While embedding content is the most straightforward and easily implemented method, the downside is that any content update will require a code change, testing, and a redeployment. Options such as loading content from an XML or JSON file exist, but these still require some technical proficiency, and potentially a redeployment if the files are still embedded in the codebase, or a server setup to host the files elsewhere.

Our clients are better served if the content can be edited directly by the content owner responsible not just for the message but the users experience, be it the product manager, the marketing department, or someone at the helpdesk. Fortunately, a new breed of content management systems is specifically tailored to address this need. They’re called Headless Content Management Systems (CMS).

A Headless CMS provides a content management interface, much like a traditional CMS such as WordPress or Drupal. But instead of outputting the content onto a website, a Headless CMS makes the content available via an API to your web or mobile application. The application can then subsequently display content loaded in realtime from the CMS, or cache the content and permit it to be displayed offline without loading times.  This is particularly advantageous for large assets such as video files.

While there are both self-hosted and cloud-hosted products available, we typically recommend our clients look at hosted products (CMS-as-a-Service). These provide the benefit of eliminating ongoing management of a CMS installation and hosting. Forget constant version patches to your open source CMS; this is all automatically handled by the CMS provider. Ultimately, long-term costs and expended effort are minimized while reliability and security are maximized.

How to Evaluate which Headless CMS to use

When evaluating a Headless CMS for an app project, we typically start with the following criteria:

• How is content managed in the CMS, and how flexible is the data structure?
  Depending on the content in the application that our clients need to manage, we will want to find a CMS that allows matching the data types to the required content structure. If data types are complex and change frequently, we prioritize a user-friendly type of builder. If there are relationships between content types, we look for a CMS that has strong options in that area. This criteria is as unique as content requirements.
  
  
• How is the data accessed?
  The most common data-access standard is via RESTful APIs, which provides a flexible foundation for most projects. In addition, some Headless CMS solutions offer SDKs or starter projects to jumpstart development, which can save time by providing CMS specific API connectors out of the box. Another rising standard is GraphQL, which reduces roundtrips between the app and the server. GraphQL also minimizes the amount of data transferred to the absolute essentials. If you are using third party tools and frameworks that are built around using REST, you’ll want to stick with a CMS that uses RESTful APIs. If your project is more greenfield though, GraphQL might be able to reduce your development effort and provide better performance.
  
  
• Can file assets be managed and served from the CMS?
  Some apps include media assets, such as images and videos. In that scenario, the CMS needs to include an asset management module, as well as the ability to store files through the CMS in a cloud storage environment. Different Headless CMS solutions have varying limitations on these parameters. We ensure that the offering is aligned with the app’s content requirements. We are mindful to assess limitations such as size limit per asset, total storage amount, and included bandwidth.
  
  
• How many records does the CMS allow?
  Some Headless CMS solutions have limitations on the total number of records that can be stored in the CMS. Depending on the specific use case of our projects this is something we are diligent to examine. One such example would be a database of property information that is batch uploaded into the CMS, which could consist of tens of thousands of records. Given that Contentful allows 5,000 records at the $39/month price level, and 50,000 records at the $879/month price level, this could be a deal breaker based on the project needs and budget.
  
  
• Is a content delivery network (CDN) built into the CMS infrastructure?
  If the content is accessed and displayed in realtime from the Headless CMS, having a content delivery network available can save a few seconds in lag time. This is particularly true if an application we are working on has a global reach. For example, Contentful is hosted in the AWS US East data center, so a CDN would accelerate load times for users outside of the continental US.
  
  
• How strong are the support resources and how big is the development community?
  Given the vendor lock that’s part of working with a Headless CMS, it is critical that we are confident the requirements of the application can be achieved with the selected solution. Having solid documentation and community support (Slack, forums, etc.) is key to this.
  
  
• How old and established is the company?
  The oldest players in the Headless CMS industry were founded in 2013, but it seems that there are new Headless CMS providers emerging every month. We significantly study a company’s track record before making a recommendation, and would only recommend a younger company if the technological benefits outweigh the risks.
  
  
• Is there a status page to shows uptime history?
  Building on the track record requirements, we look for transparency around platform uptime and frequency of issues. We’ll review a solution’s system status page for transparency of information as well as issue history. Good examples are https://www.contentfulstatus.com/ and https://status.graphcms.com/.

Our favorite Headless CMS solutions

Based on these evaluation criteria, the Headless CMS products that we are recommending the most to our clients are:

• Contentful
  One of the oldest and most established players in the Headless CMS industry, Contentful checks the boxes for most of our projects with ease. From our experience we consider them the current market leader, which is also reflected in the strong community support available. We particularly appreciate the variety of code repositories on their Github account, which includes SDKs for several programming languages.  As mentioned above, they do have limits on the number of content records stored in the CMS, which many other providers do not, so look out for that if you anticipate storing a large amount of data in the CMS.
  
  
• Prismic
  Like Contentful, Prismic is one of the older companies in the space. They offer a full-featured account for a single CMS user for free, which can be perfect for smaller or experimental projects, or anyone wanting to try a Headless CMS for their product. Even Prismic’s entry level paid account is only $84/year, undercutting most other mainstream competitors. Their team has also created a myriad of starter project libraries and SDKs that cover everything from Angular2 to .NET.
  
  
• GraphCMS
  This solution is the first Headless CMS to use GraphQL instead of a RESTful API. We consider GraphQL superior to REST, but it is still a newer standard and in some cases the interconnectivity with other systems might be a limiter. GraphCMS’ entry point on pricing is a little higher than the other providers listed here (starting at $588/year), but if GraphQL is something you can take advantage of, it very well can pay for itself.

If you would like to view more Headless CMS options, including open source and self-hosted solutions, headlessCMS.org is a great resource.

As you can see, headless content management systems have come a long way and established themselves well in the CMS world. Consider leveraging one of them to empower the content owners in your organization and reduce load on your development team for content updates. If you find yourself needing a hand on getting started with your mobile app or React application project or are considering a Headless CMS, feel free to reach out. We’d love to talk.