← Back to blog
Case Study: Building a Digital Magazine with Diana CLI as a Non-Developer
case-studynon-developerno-codecmsblazoruser-experience

Building a Digital Magazine with Diana CLI as a Non-Developer

Background

I'm a marketer who has been working in the technology space for about four years. While I'm familiar with digital tools, I'm not a developer and I don't have a programming background.

Over the years I've used some no-code and low-code platforms like Webflow, Duda, and Base44 to build websites. Those tools allowed me to create simple pages, but anything more complex, especially when it involved CMS architecture, always became more time-consuming, expensive, or technically demanding.

I would describe my technical level as around a 5 out of 10: comfortable experimenting with tools, but not someone who can build software from scratch.

Recently, our team started a podcast called How It Shifts, where we interview people around the world who are changing how things are done — builders, creators, and thinkers across different industries.

As the podcast grew, we decided to expand it into a digital magazine that could host editorial content alongside the podcast.


The Goal

We wanted to build a digital magazine platform that could:

Most importantly, the entire platform needed to be controlled through a CMS so that publishing and managing content would be simple.


The Challenge

Before having Diana, my plan would have been to build the site using Webflow.

However, that approach had several limitations:

Realistically, creating the magazine with Webflow would likely have taken at least two weeks, not including iterations or future adjustments.

Without Diana, I probably would have only designed the concept in Adobe XD and then handed it off to a developer to build. That process would involve multiple back-and-forth iterations while waiting for implementation.


Building with Diana CLI

I started using Diana CLI to build the project.

On the first day, I focused on creating the magazine website structure, using mock data to explore the layout, structure, and editorial design.

On the second day, I built the CMS that powers the platform.

In total, the working system was created in about 16 hours of work across two days.

The first prompt I gave Diana was a long description outlining the platform we wanted to build, including:

The initial prompt instructed Diana to build the platform architecture and CMS logic.


What Stood Out

The most surprising part of the experience was how quickly Diana understood what I wanted.

Even without extremely technical prompts, the system was able to produce useful results and a visually strong interface.

This was very different from previous low-code tools I've used.

In many low-code platforms, adjusting design can become frustrating because the system struggles to interpret design changes. Even after multiple attempts, you often end up with a front-end design that feels compromised.

With Diana, the visual result was significantly better, and the platform consistently responded well to requests.


The Platform We Built

After two days of work, the system now includes both the public website and a fully functional CMS.

The CMS manages the entire platform.

Content Types Managed in the CMS

The CMS allows us to manage:

Article Management

From the CMS we can:

Sponsors can be uploaded and managed from the CMS.

For each sponsor placement we can:

Podcast Integration

The CMS also allows us to manage podcast content:

Guests appear on an interactive world map, where users can filter by country and explore episodes featuring guests from specific regions.

Our podcast guests are global, so this feature helps highlight the international nature of the show.

Team and Static Pages

The CMS also controls:


Building Without Technical Knowledge

Although the experience was very empowering, there were moments where my lack of technical knowledge showed.

Sometimes I would request a change and Diana would respond that it had been implemented, but visually I couldn't see any difference. In those cases, it was often because my prompt wasn't precise enough.

Also, Diana explains what it is doing while executing tasks, and many of those explanations contained technical terms that I didn't fully understand.

Because of that, some features required multiple prompts to reach the final result.

A developer might achieve the same result in one prompt, while I sometimes needed four or five iterations.

However, Diana made it possible to overcome those moments.

When errors appeared, I would open the browser inspector, copy the error message, and paste it back into Diana. In most cases, the system was able to diagnose and fix the issue immediately.


Results

In just two days and approximately 16 hours of work, we now have a working version of the magazine platform.

The system is already functional and capable of publishing content.

The only remaining step before launch is replacing mock content with real articles and information.

Even more importantly, I now feel confident that I can continue improving the platform myself without needing a developer.


Final Thoughts

As someone coming from marketing rather than engineering, Diana felt like a bridge between ideas and execution.

It allowed me to bring my marketing vision into a technical product without relying on intermediaries.

And for the first time, while building a platform like this, I genuinely felt powerful.