How (and why) to build an app in Contentful

Contentful needed an app. But wait, we’re getting ahead of ourselves. Let’s rewind.

Contentful wanted to launch an internal, operational planning framework that would require information inputs from team members across different departments and teams.  

The idea was that the inputs would reflect the internal hierarchy, and each would coordinate with others. Changes made to any single entry could trickle down, informing changes to those nested below.  

Once the framework was up and running, team members would be able to align their entries with each other easily, with a cascading effect from top to bottom

Simple. In theory. So, how would we deliver?

To automate or not?

One option for getting the framework off the ground was to build forms in Google Docs, distribute them to team members across Google Drive, and manually share every entry with the relevant colleagues and stakeholders. Anyone who’s tackled this kind of framework project can probably tell you that approach can involve risks — not least because it’s slow, complex, and prone to error. 

There was another option: build the framework as a centralized app that would store and update data automatically, and allow team members to navigate, coordinate and browse entries simply and efficiently.

The only issue: We didn’t have the budget, resources, time, or engineer availability to go through the app development process. What we did have was a clear understanding of the problems we wanted to solve — so we started to consider a different approach: Why not use AI to bridge the gap?

We could vibe-code in an AI-powered coding platform and then — here’s the really interesting part — use the Contentful digital experience platform (DXP) to host the app. 

Cards on the table: At that point, we weren’t entirely sure how the vibe-coding approach would play out, or how we’d run the app on Contentful. But we were ready to learn. 

The process that followed not only delivered beyond our expectations but opened up a new role for Contentful itself. 

Starting from scratch

As you might have guessed, the framework development story isn’t really about the app itself — it’s about how we built it. 

AI-assisted coding — vibe coding — is a way to lower the barriers to application development. People with domain knowledge (in this case, the Contentful platform), but not necessarily technical expertise, can work with AI agents to sidestep the technical heavy lifting as they build software. 

It’s worth double-clicking on this point: The development team members really were starting their coding journey from scratch. No engineers were helping out, and we weren’t sitting there with a coding textbook telling us what to do. 

We had our objective to shoot for, and we knew we’d be leaning heavily on the agentic capabilities of our AI tools and the Contentful platform to get where we wanted to go.

Let’s take a closer look at those tools and how we used them to make the app a reality.

Cursor

We chose the agentic code editor Cursor to do the AI-powered software-building work. We could interact with Cursor via natural language prompts, simply describing functionalities and what we wanted to achieve, and iterating on versions in the same way. 

Model Context Protocol

Since the framework would be using data held within our Contentful space, the app needed to be able to interact with Contentful seamlessly.

We achieved that with the Model Context Protocol (MCP). The MCP is a standardized, open-source framework that allows AI tools, like Cursor, to interact with external systems, like Contentful.

The Contentful MCP server was the bridge between the Contentful DXP and Cursor. It included all the context, permissions, access, and information that were required to support the agentic work that the code editor needed to do. That included access to the content model, capabilities to create content types and fields, and so on. 

Without the MCP, all that would have needed to be configured manually. 

The Contentful platform

In most development setups, building an internal app means stitching together multiple systems: a frontend hosted on a development platform like Vercel or Replit, a separate database layer, and so on. Each component adds complexity, overhead, and another thing to maintain.

With Contentful, that separation disappears. The application would live in Contentful’s App Framework, so it didn’t need a separate hosting environment. The DXP would be storing framework data and it would also be the interface we’d use to interact with it. 

The same went for access and governance. Rather than introducing a new authentication layer, the app would use Contentful’s enterprise-ready controls, including single sign-on (SSO). If someone had the relevant access to Contentful, they’d have access to the app.

The development process

This is where the power of a structured content model comes into play. 

In Contentful, content isn’t stored as immutable pages or documents; it’s defined down to the entry level. In other words, it’s structured into its smallest component parts: text, image, header, metadata, and so on. That structure makes it easy for AI agents to understand context: what an asset is, what it means, and how it relates to the assets around it.

Working with (and talking to) Cursor

We used that context to facilitate the vibe-coding process, literally explaining to Cursor what we needed to achieve: “Here’s what a framework entry looks like,” “Here’s how entry X relates to entry Y,” and so on, until the app started to take shape. 

Instead of working through menus and configuring fields manually, development became a conversation. We could ask Cursor what the content model should look like. We could show examples. We could explain how the hierarchy should work. We could refine the experience as we learned more about what we wanted the application to do. 

Cursor was able to take those prompts into Contentful (via the MCP server) and navigate a well-defined content ecosystem with total clarity, finding the data we needed and using it to populate the app. 

Working this way, we built out an app with a homepage, a sidebar, and configuration screens, iterating and problem-solving the entire way with AI prompts.

The MCP server took care of the content operations, fixing issues like duplicated team structures and hierarchy updates. It also enabled us to test the functionality of the app in a staging environment before deploying it. 

Development challenges and solutions

It wasn't all plain, agentic sailing. Here’s an example of a problem. 

We had two entirely separate content types: “methods,” which explained how team members  were going to achieve operational goals, and “measures,” which explained how they were going to measure their progress. Initially, from a technical perspective, everything was working well: the framework application was displaying the information we wanted.

But that's not how we needed it to function: measures entries are supposed to sit beneath methods — they’re KPIs that demonstrate whether a particular method is succeeding. The relationship is hierarchical, and our content model wasn't reflecting that. When we got that feedback, we thought a rebuild might be in the cards. 

Our structured content model came to the rescue. Because the relevant content already existed inside Contentful as structured entries, we didn't need to recreate anything. We simply updated the framework content model: by adding a reference field to the method content type, we could link measures directly to the relevant methods. The only thing that needed to change was the relationship between the two content types. 

This problem highlights the advantage of structured content. Like in any real-world marketing project, requirements evolve constantly. When content is structured, those changes don't necessarily require huge overhauls; you can zero in on specific assets and make the changes without disrupting the wider ecosystem. 

The finished app

The combination of Contentful’s content model, the Contentful MCP server, and iterative vibe coding brought the application to life. And quickly.

The first usable version of the application was ready within a couple of days. At that point, the core functionality was in place and the underlying content model was doing the heavy lifting. The remaining iterative work was about experience optimization. 

Roughly a week after development began, we had a fully functioning internal application built around structured content, powered by AI-assisted development, and hosted entirely within Contentful.

But the most important result wasn't the application itself. It was the realization that Contentful could play a much larger role in the development journey. 

Doing (much) more with Contentful

For years, organizations have used Contentful to power websites, apps, and digital experiences, all without overloading their marketers and other non-technical team members with complexity and developer dependencies. 

But now there's another possibility: using Contentful as the foundation for building bespoke tools and apps. 

What could that look like? Interesting question. 

Beyond the framework

Let’s take internal messaging and positioning as an example. In most organizations, internal comms assets live across a growing ecosystem of documents, folders, shared drives, and spreadsheets. New versions are created, old versions get archived, teams download local copies, and before long, nobody is entirely sure which version is the right one.

Structured content modeling means you can manage that process differently. Instead of delivering internal messaging as a document, you could model it as content. 

Each type of internal message could have its own defined structure, with the relevant teams owning and maintaining their areas of responsibility. An application layer can then surface information in whatever way makes the most sense: searchable by product, audience, use case, industry, or region.

The same principle could be applied to sales resources, playbooks, campaign planning, onboarding materials, and countless other internal experiences. In each use case, the process could involve vibe-coding an application and an interface, and then using Contentful as the engine. 

You’d have your app database, host, authentication, and governance, all wrapped up in one convenient, easy-to-use package.

What else is possible?

The point is, as AI drags down the barriers to software development, more people across an organization will be able to work with AI agents to build the tools they need. 

The challenge won’t necessarily be generating the applications and the functionalities; it will be ensuring those applications are powered by reliable, well-governed, well-structured content engines.

And that’s where Contentful changes the picture. If a small team can build an internal application in a matter of days, it's worth asking what else is possible.

Ready to get your next development journey started? We’ll be with you from the first step:  Reach out to our sales team to schedule a Contentful demo.

Take a tour

Chat with our team

Your experiences should wow, not wait. Let's talk.