/
Most of your clients are likely used to more traditional ways of working with content. Here are some tips on how to convince them to go with structured content.
Let’s say you’re convinced that you want to use Sanity.io for your client’s project because you enjoy the developer experience. That’s not always easy to communicate to clients, and great developer experience isn’t always their primary, or only, concern (and rightly so). Most of your clients are likely used to more traditional ways of working with content for their website and digital services. It’s not always easy to convince them of a different approach, especially if they aren’t familiar with it, or if they have had past bad experiences with similar services.
Your priority should be to understand what your clients are trying to achieve.
Your goal shouldn’t be to use Sanity.io. It should be solving your client’s challenges in the best and most efficient way. Of course, we would argue that using Sanity will, in most cases, let you do that, but as a means to an end. So before suggesting using Sanity.io for managing content, get a good understanding of what strategic goals your client has for the project. And then think about how using Sanity.io fits into that.
Be upfront about that Sanity.io comes with a different way of approaching content compared to traditional CMSes.
Sanity Studio comes with almost no assumption about how your content is structured, created, validated, and presented. This leaves you with a lot of freedom and flexibility. From what we have seen, the best projects entail some work on structuring content in a way that makes sense for the project’s team and organization. That prescribes a different approach than just filling out whatever templates the CMS has given you - or just thinking about a website as a collection of pages on which to put some text, images, and media.
That said, working with structured content is often more fun and fulfilling because you end up with something that is much more intuitive and familiar. It might also be useful to look at conversations within Content Strategy, and books like Designing Connected Content (Atherton & Hane, 2018).
Content modeling in code is as fast, if not faster, than web-based drag and drop.
Understandably, the code based schemas for Sanity Studio might seem complicated for people not familiar with coding, especially compared to drag and drop solutions. Be empathetic of this stance. The reason, however, we still decided to ship Sanity Studio like that, is because we think the developer should have a say in how fields are named and work because apps and services rely on them. We also wanted to empower developers by making it possible to check these schemas into git, to let them use npm modules and programmatically generate them, and to make it really easy to customize and extend studio functionality.
An effective way to convince your client’s that this is a great way to work is to sit and write a schema with them. Not only do they get a better understanding of how little work it takes to add new fields or to change something, in our experience, but they might also get inspired to learn how to do it for themselves.
sanity deploy and invite your client to show how fast you get changes to production.Even though Sanity.io is a SaaS, that doesn’t mean that your client’s content is “locked-in”.
Contrary to other traditional and headless CMSes, Sanity.io doesn’t lock in your content: The point with Sanity is to make it as easy and effortless as to take your content and use it wherever you need it. What you lose if you move away from Sanity is the unique capabilities in the real-time data store, as well as the no-ops experience and the great CDN-networks. Your content, however, is yours, and you can export, at any point, with only one command, all your documents, and assets
Working with a structured content approach is more efficient, creates for more possibility, and reduce bloat, and headache.
Sanity.io lets you work with content and create single sources of truth. For example, if you have a collection of products, you should be able to refer to these products in your marketing copy and be assured that if you changed a product name or some of its properties, this would propagate to wherever this product was referred to. You should never have to copy-paste the same piece of the product’s description to have it appear in different places (and hence make it difficult to keep consistent).
Structured content often means organizing it by what it means and not how it might be presented. If your clients are used to managing content by editing it inline on webpages, this might be unfamiliar to them at first, but in our experience, most people get intrigued when they understand the implications, like saving them work and creating new possibilities for how to work and present content.
Sanity.io takes away a lot of the “hidden costs” that come with traditional CMSes.
Even though you might find that some of the traditional CMSes are free or have cheaper licenses, you should account for the “hidden costs” that come with setting them up, extending them, and keeping them up to date and monitored. There is virtually no setup with Sanity; you’re ready to work on a new project within minutes. There’s no database or backend that you have to install or configure (however, your client can host the Studio on their custom backend if they want to). As long as you keep your authentication credentials safe, you don’t have to worry about your CMS getting hacked or taken down.
Where the advantage with Sanity.io and structured content shows, is whenever you need to redesign or re-use your content in another presentation. Contrary to traditional CMSes where you’re often constrained by a tight connection between content and a particular web presentation or limits in the APIs, you can pretty much get going without any refactoring with Sanity.io. If you do need to make some minor changes in your content, you can export and import your dataset and make a new branch of your Studio and work with it separately. When you’re ready to go to production, you can do so by importing and replacing the new documents, without any downtime.
With Sanity.io, you give your clients more freedom to choose who they want to work with.
Sometimes, clients can be initially worried about being “locked-in” with you, especially when choosing something that seems unfamiliar. While we hope that you'll have a long and happy collaboration with those you choose to work with, it might be useful to assure them that using Sanity.io doesn't require any particular skill or certification (like a lot of other traditional CMSes do).
If you’re building services for the web, there’s a high probability that you’re already using HTML, CSS, and JavaScript. With Sanity.io you don’t have to add another programming language to the mix, like PHP or .NET, to build the editor experience or use the data store. JavaScript is one of the most popular programming languages in the world, which in turn means that there is a big pool of talent that can work with Sanity.io.
Sanity.io lets your client have multiple editing environments in the same project.
Sanity Studio is an open-source Single Page Application built with React and you can deploy as many of them you want, either on your own server (using, for example, Express in Node.js, Apache, or Nginx), or on a hosted services like Netlify, Vercel, Digital Ocean, or Azure). This means you can create customized editorial experiences for different parts of your organization, and have it all work in real-time, without your client having to worry about document-locking or race conditions (where someone is overwriting someone else’s content without knowing it).
While other headless CMSes might try to push you to change tiers based on the number of content models or locales you may have, Sanity.io lets you add a credit card to pay-as-you-go for any usage over the quotas you may have of bandwidth, API requests, users on the project, or storage. You only have to change tiers based on your need for SLAs, support, or advanced features that are usually required in larger organizations. Furthermore, you are free to change between tiers at any point if your requirements change.
Saying "no" is essential for most projects to keep the focus on building the right things. However, 'saying “no” to a perfectly reasonable request because the technology doesn’t let you build what you need' is something we work to avoid. There’s no better experience than being able to say “yes” to your client’s request, knowing that you have a stack that is flexible enough to let you build it.