React Bricks with Matteo Frana

Episode Description

Matteo Frana explains how React Bricks combines visual editing with React components to bridge the gap between developers and content creators.

Episode Summary

In this episode, React Bricks CEO and co-founder Matteo Frana walks through the origins and philosophy behind his visual CMS, which lets developers build design systems with React components while giving content creators a no-code editing experience akin to tools like Wix or Pages. The conversation traces Matteo's frustration with WordPress and headless CMSes — the former offering too much freedom that could break designs, the latter reducing everything to unintuitive gray forms — and how that gap inspired React Bricks. The hosts explore framework support across Next.js, Gatsby, and Remix, the potential impact of React Server Components and Astro on performance, and how structured data can be handled through page types, external CMS integrations, or a planned entities feature. Matteo shares his personal journey from coding on a Commodore 64 to running an Italian web agency, pivoting during the first Covid lockdown to build the React Bricks prototype. The episode closes with a look at upcoming features including an editorial calendar, visual brick selection with previews, customizable login pages, and layout components with column slots — all aimed at making the editing experience even more flexible and intuitive.

Chapters

00:00:00 - What Is React Bricks and Why It Exists

Matteo Frana introduces React Bricks as a visual CMS built on React components, describing it as something like "Wix for corporate" — easy for content creators but powered by a developer-defined design system. He explains that the project was born from his own search for a WordPress replacement at the end of 2019, when he found a clear gap between headless CMSes and visual website builders.

Chris shares his own experience discovering that headless CMSes, while great for developers, leave non-technical team members confused by abstract gray forms with no visual connection to the final page. Matteo agrees, recounting how even his WordPress projects relied on Advanced Custom Fields to constrain user freedom, effectively turning WordPress into gray forms anyway. The core insight driving React Bricks is that content creators think in terms of pages and visual blocks, not database entities.

00:05:21 - Filling the Gap Between Wix, Webflow, and Headless

Matteo maps out the CMS landscape, explaining why tools like Wix are great for small projects but lack the ability to enforce a custom corporate design system, while Webflow gives content creators too much power over CSS details like margins and paddings. React Bricks occupies the middle ground: users get visual editing freedom within carefully defined constraints so they cannot break the design.

From a developer perspective, React Bricks maps naturally to React's component model — each visually editable content block is a React component with props and a schema that governs what can be changed. Some props are edited inline (text, images), while others like background color appear in sidebar controls similar to Storybook knobs. Anthony asks whether it functions as both a no-code and low-code tool, and Matteo confirms: it is full-code for developers who build the components, and no-code for content creators who edit within them.

00:11:32 - Framework Support: Next.js, Gatsby, and Remix

The discussion turns to framework compatibility. Matteo explains that React Bricks supports Next.js, Gatsby, and Remix, noting that supporting all three required relatively little extra effort. He highlights a major advantage: migrating between frameworks is as simple as starting a new CLI project and copying over the bricks folder, since React Bricks abstracts away framework-specific image components and other differences.

Chris reflects on the JavaScript ecosystem's history of framework churn — from Gatsby's dominance to the Next.js era — and argues that React Bricks' multi-framework support protects users from being locked in. He also raises the possibility of supporting lighter frameworks like Astro, and Matteo responds enthusiastically about Astro's islands architecture and React Server Components, both of which could dramatically reduce unnecessary client-side JavaScript for static content blocks.

00:16:01 - React Server Components and Performance

Anthony asks how React Server Components would integrate with React Bricks. Matteo explains that the implementation depends on how RSC stabilizes, noting that most bricks — being static content like titles, images, and text — could become purely server-rendered components, while interactive elements like carousels would remain client components. He mentions Shopify's Hydrogen as another early RSC adopter.

The conversation emphasizes the performance implications: eliminating unnecessary client-side hydration would improve metrics like time-to-interactive that developers and businesses increasingly care about. Matteo takes a cautious approach, preferring to wait for RSC to exit beta before building deep integration, but sees it as a significant future improvement for React Bricks users.

00:18:01 - Structured Data and External CMS Integration

Chris pivots to structured data, asking how React Bricks handles content like blog posts or product listings. Matteo outlines three approaches: using React Bricks page types to fetch and list pages of a certain type (like blog posts), integrating external headless CMSes through an external data mapping feature that can blend or override external content with React Bricks content, and a planned entities system.

The external data integration is particularly powerful for e-commerce — a product title from Shopify can be displayed but overridden by marketing teams for SEO purposes, reverting to the original when cleared. The upcoming entities feature would bring headless CMS-like structured data directly into React Bricks, with the added benefit of multiple visual previews (list view, detail view) that traditional headless systems lack. Chris notes this makes React Bricks ideal for incrementally enhancing existing websites rather than requiring full rebuilds.

00:24:35 - Matteo's Journey from Commodore 64 to React Bricks

Matteo traces his programming history from copying BASIC programs on a Commodore 64 at age eight, through Logo, Pascal, and university-level C++ and Java, to launching his web agency F2 at age 17 in 1996. He describes the evolution from static HTML uploaded via FTP through ASP and .NET to eventually adopting React when Angular's breaking changes between versions one and two pushed the team to take a risk on a new library.

The agency built web applications across diverse industries — pharmacy e-commerce, textile production, IoT — but website projects using Gatsby and WordPress proved frustrating. After completing Y Combinator's Startup School for a headless e-commerce idea, Matteo pivoted to React Bricks during Italy's first Covid lockdown in early 2020. He built the prototype, enlisted co-founder Dario for the backend, and the bootstrapped product grew from there.

00:33:52 - Getting Started and the Learning Tutorial

Chris recommends checking out example sites built on React Bricks — Catbase, Everfund, and Woosmap — as well as the demo playground on the React Bricks website. Matteo discusses the importance of documentation and highlights the step-by-step tutorial at React Bricks' learn page, which features gamification elements inspired by the Next.js tutorial but with added quiz challenges and a surprise reward for high scores.

Anthony praises the curriculum-style approach, and Matteo reveals he designed the tutorial, the admin UX, and the entire website himself, driven by a passion for interaction design. Chris confirms the tutorial was how he actually learned to use React Bricks, lending credibility to its effectiveness for hands-on learners who prefer tinkering over reading documentation.

00:38:45 - Upcoming Features and the Road Ahead

Matteo previews several features in development. The team has just released shareable preview links that work across all supported frameworks, allowing draft pages to be shared with anyone without a React Bricks account. An editorial calendar is coming soon, letting teams see scheduled publications day by day and jump directly into editing from the calendar view.

Additional planned improvements include customizable login pages to replace the default branding, visual brick selection using saved preview snapshots instead of just names, and — most significantly — layout components with slots that would allow nested brick structures like multi-column newspaper layouts. This slot system would let developers define structural bricks with designated areas where specific brick types can be added, greatly expanding layout flexibility beyond the current single-column block approach.

Transcript

00:00:00 - Matteo Frana

Yes, Matteo. Matteo.

00:00:12 - Christopher Burns

Welcome to the podcast, Matteo. You are the CEO and co-founder of React Bricks.

00:00:19 - Matteo Frana

All right. Thank you for having me here. It's a pleasure to be here.

00:00:23 - Christopher Burns

React Bricks is one of these companies I've been super interested in for such a long time, and I've actually used it now. And Everfund's website is built in React Bricks, so I like to say that just up front. Transparency, I think, is key. When I built Everfund, I looked around CMSes for so many months and years, from way back with Gatsby to now. To me, nothing is quite as easy as React Bricks, but I think it's easier for you to explain what it is, considering it's your product. So what is React Bricks?

00:00:53 - Matteo Frana

React Bricks is a new kind of CMS with visual editing based on React components. You can think of it like Wix for corporate, in a way, for content creators. It's as easy as Wix, but it uses your own design system that developers create using React components. It's something that I created because, like you, I was researching something to replace WordPress as a headless CMS together with Gatsby, which I was using at the end of 2019. I was searching for something else to replace it, and after a lot of research, I found that there was a gap, so I created React Bricks. For this reason, I can tell you what I looked for and why I created React Bricks.

00:01:48 - Christopher Burns

The big reason that I'm so interested in React Bricks is that, as a developer, I can look at a website and think, oh, here's all the components, the Lego bricks that bring it together from front to back, from navbars to hero sections and calls to action. So then you spend your time and go, okay, let's use something like a headless CMS. Any of them will do. Okay. I'm going to do this system in a headless CMS. Okay. Define the bricks that you want. And then the biggest thing that we found, and that I found personally, is that I was like, oh, I could build this whole website using gray forms and understand exactly how it's going to look. But then, as soon as I gave it to my team members who are not technically savvy, they go, gray forms? What is all of this? How do I know what gray form does what? This is where I think your segment of CMSs is actually really interesting, because instead of giving a gray form, you're actually showing the component.

[00:02:47] And then, one better, allowing users to just edit the actual text or image inside the component.

00:02:54 - Matteo Frana

Yes, that's true. We saw that when we worked with WordPress years ago. We used a blank canvas, and so the user was free to create. But that had other problems because there was too much freedom. They could break the responsive design. So even with WordPress, we were using Advanced Custom Fields so that we could limit what the user could do. Even WordPress became something like a set of gray forms, to be sure that the user could do just what we wanted them to do and not have red text over a green background. In a way, we were using this setup at the end of 2019. In some ways, WordPress is great, but I didn't want to host a WordPress website anymore, even if it's just the backend, the API, with a limited attack surface.

[00:04:10] So when I was looking for something else, the first thing is headless CMS, of course, because everyone loves headless CMS. Let's say developers love headless CMS, and for good reasons: you have decoupled APIs. They are APIs as a service, so no hassle to set up your server. You can choose the front-end framework that you want, but content creators don't like headless CMS for the reason that you said. It's like WordPress with Advanced Custom Fields. It's just gray forms. So even for developers, it's not great because you have to train your users. You have to say, well, what you see here in these gray fields ends up here on this page and in this part of the page, because with headless CMS you are more working on a database. You have the concept of a table of entities, if you want, but you lose the concept of page. The users, the content creators, think in terms of pages. So you have to say, if you change this entity right here and this entity right here, then you will have these results on your About Us page.

[00:05:21] Some years before 2019, I had already registered the NodePress domain name because I wanted to create a CMS based on Node.js, something like what is now KeystoneJS. I had something like that in mind, taking the best part from Drupal that was not there in WordPress. Then I started thinking, what is great for content creators? The first thing that comes to my mind is Wix, which has a great interface for content creators. The UX for sure is great, but it's only okay as long as you are okay with their templates and a limited ability to change the template. So I think that it's good for a small project, maybe if you have a small restaurant, but of course not for a corporate that wants to create its exact design system.

[00:06:39] And then there are other visual tools like Webflow. They are much more powerful, of course, but I think that they end up being too powerful because, in a way, the content creator is not in charge of deciding margins and paddings and things like that. They don't have to know the CSS box model. So what I wanted to create is something that allows content creators to have all the freedom that they want, but no more than they need. I want to have great constraints so that users can edit the content visually and easily within their design system, but be sure that they cannot break the design system.

[00:07:54] That's what I wanted to create when I started thinking of React Bricks. Of course, from a developer point of view, I love React, and maybe I will talk about how I came to React, but I love React. For me, the choice was quite easy. If we think that we want visually editable content blocks with a schema that sets constraints, for me that mapped perfectly to the concept of a React component with props. I want a visually editable content block, I want a schema, I want constraints. So I have the JSX of a React component, together with its props and the schema that defines how these props can be edited.

[00:08:17] Some props are edited directly. You have text you can edit, you have an image you can edit. This is what is inside your JSX using the React Bricks components. Then there are the background color and the font size. The experience is exactly what you have in a tool like Word or Pages. From a developer point of view, you don't have to train your users because you just give React Bricks to them and it's like they are in front of Pages. They write, they change the props, and they're good to go. No need to explain the gray fields.

00:08:17 - Anthony Campolo

I have never used React Bricks, so I'm going to have the noob-level questions here. It sounds like what you're describing is that it is both a no-code and a low-code tool, in the sense that you can edit the page just through a UI, but if you want to, there is React code there and you can go into that React code and tweak that itself. So you're trying to split the difference between what a developer would use versus what a content producer would use. You want to be something that both could use and be comfortable with. Is that kind of the idea?

00:08:50 - Matteo Frana

Yes, exactly. In fact, a tool like Webflow requires a developer who is also, in a way, the designer in that moment and is also a content creator in that moment. But in a corporate situation, or also in a startup situation, you have developers and you have content creators. They want different things. The content creator wants the no-code UI, while the developer wants the low-code, or let's say it's code because you create your content, your React components, in code, and you have the full power of React. It's low-code in the sense that the visual editing part, which is quite difficult to recreate, you don't have to create because it's part of the React Bricks library. So it's low-code for developers, in a way, and no-code for content creators.

00:09:38 - Christopher Burns

My weird way of explaining it is: it's like Storybook, where you view all your components, but instead of just viewing them and testing them, you just say, put that component there and click save, and then the website is built.

00:09:52 - Matteo Frana

Yes, exactly. In fact, the concept of the sidebar controls is similar to the concept of knobs in Storybook. There was a moment in which I was also thinking, what if we created Storybook for all the bricks so that you can see them in Storybook? But really, there is already the playground of bricks, which does exactly the same thing that you can do in Storybook, but you can see the component live and exactly as you use it in the editor. So therefore, if you don't know React Bricks, the playground is where you see all of your bricks, all of your visual content blocks, which constitute your design system, and you can play with them. So you have an idea of what the components are that you can use in the editor.

00:10:41 - Christopher Burns

What's actually really good is that, as you were saying, when you're in that playground, you're editing the real brick, the code you're going to use. What's really good is you can set defaults. So you can say, I know 95% of the time this is going to be laid out this specific way, so I'm just going to code that in as the default option. And then when the user drags that in, it's there and it's defaulted to what you put. There's a lot of customization. And what I've found is that it is so flexible that you just need to know how to do things right. A button can easily open a website, or it could talk to your Intercom or your Crisp chat, and there is no limit. It's just how you work around these blocks. Understanding the concept, I think, will go a really long way. And I think it's really important to talk about the big elephant in the room. I think it's called React Bricks, but what frameworks does it support?

00:11:32 - Matteo Frana

React Bricks supports the main React frameworks. At the moment it supports Next.js, Gatsby, and lately also Remix. At the moment it is limited to React. It is React Bricks. The idea is to maybe expand it to all component-based libraries. I think that we could expand it also to Vue or Svelte. It's something that we can do, but at the moment we support just React, and so Next.js, Gatsby, and Remix.

00:12:10 - Christopher Burns

There are obviously other visual editors out there, but some of them have made the choice to only support one of them, like Next.js. Why have you supported all three? And in your eyes, why do you let the user pick which one they want to use? Because to me, I really don't know the difference, and I just picked Next.js over Gatsby, for example.

00:12:31 - Matteo Frana

In a way, supporting all three was not so much additional work. I see that there are frameworks like Tina, for example, that support just Next.js. Maybe they have some technical reason to do so, but in our case, it's not so complex to support all three. So I think that giving the freedom to the user to choose the framework they want is the best way. And in a way, React Bricks is also an easy way to switch frameworks later. Because if you have a React Bricks project with Next.js and you decide that you want to migrate to Gatsby, it's just a matter of starting up the CLI, choosing a Gatsby project, and then putting your credentials there. If you use the CLI, the credentials are already there, and so it's just a matter of copying the bricks folder from one project to the other, and you're up and running in two minutes with Gatsby because you have all of your bricks. You don't depend on Next's image component, which is different from Gatsby's.

[00:13:37] You just have the image from React Bricks, so you can migrate in one moment. Want to try Remix? Okay. Start the project with the CLI, copy the folder, and you're good to go.

00:13:48 - Christopher Burns

As bad as that may be, my fastest way to try Remix fully fledged is to just move my Next.js website over. It's really easy and it's really, really exciting. Things like Remix are such a brand-new, well, not new, they've been doing it for some time, but new concept, and seeing that you are openly supporting it is so positive. Because what I find is that people don't know the best framework of choice for a task until it's too late. So many times, we jumped on the trend straight away. Earlier on in JavaScript, when Gatsby 2 was the thing, everything was Gatsby 2, and it was great until you started trying to build dashboards in it and all these other things, and you're like, this is terrible, why are we doing this to ourselves?

[00:15:00] Then everybody jumped from Gatsby to Next.js, and now everyone's on about Next.js being the best thing in the world. Even though Everfund is built in Next.js, I do think it's still maybe a little bit overkill, and I would be really excited to see maybe React Bricks and something like Astro that tries to be as lightweight as possible. Because a CMS, or really the code that needs to be shipped to your client, does it really need to be this really reactive code? It's a great question that I'm wondering if you've explored.

00:15:06 - Matteo Frana

It's very interesting. I think that the concept of Astro, to have these islands of interactive and non-interactive code, is interesting. In some way we will get there because I think it's a superior way of having front-end code, to try to make non-interactive what is non-interactive. I think that we want to support Astro, but also, when React Server Components are no longer in beta, they will be a great way to have much less JavaScript code running on the client. It makes no sense to have React rehydrate a component which just renders a static title with an image and a static text.

00:16:01 - Anthony Campolo

So what would that mean exactly? To bring in something like React Server Components, would that be something that would be under the hood in React Bricks, or is that something that would actually be a part of the sites that you would be generating for people?

00:16:13 - Matteo Frana

Much of this depends on how React Server Components will be implemented. At the moment we see an experimental implementation in Next.js, where your component must have a name like component.client.js or component.client.tsx or component.server.tsx. We would need to know if the React Bricks brick is a purely server component so that it will become a server component, or if it has some client code like a carousel or something like that, so that it should be mapped to a client component. It's something to be seen because at the moment it's like, if you want to use a server component, you have to use a framework like Next.js that implements them for you. But I think that in the end it will not be this way. So at the moment we have not explored this thing because I want it to be stable before we look at it.

00:17:13 - Anthony Campolo

Have you looked at Hydrogen at all? It's Shopify's framework. They're using React Server Components pretty heavily.

00:17:18 - Matteo Frana

Yes, I saw that framework, but really quickly. Of course, server components will be a game changer. I think that 90% of the bricks that are created now can be purely server components. When you don't have carousel things or something like that, you really don't need any client-side hydration. It can become quite heavy, and it worsens all the metrics that now users are starting to look at, PageSpeed Insights, and they tell you, well, my time to interactive is half a second. Why? With server components, that will be much easier.

00:18:01 - Christopher Burns

I think what's really cool as well is that we have been talking about all this visual editing of data, but there's still a place for structured data like blog posts or podcast listings. How can structured data be implemented in React Bricks?

00:18:17 - Matteo Frana

There are three ways. One, you can create your page type. Let's say that you have a blog. We have many customers that right now are already creating their blogs with React Bricks, with no support for really structured data. You just have a page type which is blog, and using the React Bricks fetch pages function, you can fetch all the pages of a certain type. So you can fetch all the pages of type blog, and then you can iterate over them to create the list view of your blog. For each page you can get the featured image, you can get the author, the publish date, so you can render outside of React Bricks. You can render your list page just by fetching the pages of type blog, and when the user clicks, you have the detail view, which is the page created with React Bricks. This is one way when you have simple data. So you have a list of blog posts, a list of podcasts.

[00:19:24] Then there is another way, which is using an external CMS. You can use a headless CMS like Contentful, DatoCMS, etc., and there is a feature of React Bricks which is external content. So on a page type you can define a get external data function, which is just an async function that must return a promise that resolves to an object, and you will find that object on the page. Then on your bricks, in the schema, you can define a map external data to props function, which is similar to the Redux function to map the props, mapStateToProps. So you can decide that you map the external data from the external source to a prop that you can use inside your brick. You can decide that the external data is read-only if you map it to external data. Or you can say that the title, for example, is the React Bricks title or the external data title. It's a bit complex if you've not seen the code, but the map external data to props is a function that takes as arguments the external data and the React Bricks data, so you can mix them as you want and return the props.

[00:20:48] So you can also choose to have a title for an e-commerce product that comes from the external data, let's say Shopify, BigCommerce, or whatever, but then you can override it by writing over it in a React Bricks text field, and you can save it. As soon as you delete the title, it comes back to what was in the external data. So you can choose to have an e-commerce powered by external data and React Bricks, and let some of the properties be visually overridable with React Bricks. With an e-commerce, you can choose to let marketing change the name because maybe it's not the name that you have in the database. It's not so SEO-friendly, and then they can create all the landing pages using the React Bricks blocks.

[00:22:06] The third thing is that we want to better support structured data directly. This is a feature that we have in mind, the entities feature. We'll integrate something from a headless CMS inside React Bricks. This is part of our long-term project. We have in mind to let the user create entities that are reusable across pages. What's more, compared to what you have in headless CMSs, with React Bricks you could have an entity which has its gray form but also has its views. So you can have an entity which is an artwork, which has a list view, a details view. Then you can have a tag which is entity type artwork, ID, view details, or view list. When you are also writing on the gray form of an entity, you can preview it in details mode, in list mode, in short-list mode, something that you cannot do in a headless CMS. So we want to integrate something like a headless CMS, but better than headless, inside React Bricks for these entities that you can reuse across pages.

00:22:52 - Christopher Burns

And this is actually really important because what you've just described here is a really good way for somebody who wants to add a bit more reactivity to their website, a bit more customizability, without having to rewrite the whole website from scratch, i.e. a Shopify store. I've got a Shopify store. It's already pulling all these things, but then I want to now make my homepage more customizable. So now you can implement React Bricks to make this homepage really customizable, customizing the bricks without any of the other pages being touched. It gives this effect of, while it's great to go from day one and say, I'm just going to build a website with React Bricks, I think for a user who wants to really get the most out of it straight away, it's by having a website predefined, even if that's just in plain HTML, that can then be converted into React Bricks.

[00:23:58] Everybody works differently when it comes to building websites, but I find the hardest point is actually defining what you want first, as in the design, the base HTML, the CSS. And then, once you've got that, making it interactive in things like React Bricks, I think, goes a really long way. And that's something you can do just by yourself, as I have done, with no designer needed. I just built a website up from Tailwind Components. I just built it up to where it is today. And what's really, really good is that obviously Elephant is a startup itself, and we're forever changing our marketing, our pages, and we can literally hide pages, show pages, customize pages. The best thing about it is my non-technical co-founder doesn't have to ask me how to change it because it just works.

00:24:33 - Matteo Frana

Yes, that's great.

00:24:35 - Anthony Campolo

I'd be curious to hear a little bit about the history of React Bricks. I think you're kind of a bootstrapped company. What has the journey been like of building up React Bricks over time?

00:24:46 - Matteo Frana

I will start from my own journey in tech and go up to React Bricks. I started to copy programs when I was 8 or 9 on a Commodore, or Commodore 64, sorry. It was BASIC then. When I was ten, I had the luck to have an IBM 8088, and so I started programming in GW-BASIC. Then I really started programming using Logo. I don't know if you know Logo, where you move the turtle on the screen. You have a triangle which is called the turtle, and you have commands like forward 10, right 90, forward 20, and you can create procedures with it. This is really great, by the way. I think that it's still the best way to learn to program because now there are all these Blockly or Scratch, these block-based tools to learn how to program, but they lack the aura of mystery that writing code that the computer understands has. Dragging and dropping blocks is not like writing code.

[00:26:06] You see that the computer can understand it, and if you write it in the wrong way, the computer does not understand it. So really, I am already teaching my five-year-old son using Logo.

00:26:18 - Anthony Campolo

I've never heard of Logo before. Listeners, check it out. We've got a link for this in the show notes. This is really fascinating because this is like a visual programming language, like you're saying, that kind of vastly predates things like Scratch. So thank you for giving me the tip on this. I'm going to have to check this out.

00:26:33 - Matteo Frana

It's really great because you write the code and you see the turtle move on the screen. You have the visual part because the turtle is like you are moving a robot with the commands. You can create a procedure so you can repeat a procedure. So I think it's great. And so I started programming in that way. Then Pascal when I was 14, and then at university, C++, Java. But really, I was already working when I was 17. It was 1996, so you know that I'm older. I was 17 and I started programming in HTML because there was just HTML, CSS, no JavaScript. You just uploaded your HTML files to an FTP server. Things were much easier than now.

[00:27:45] Then the first server scripts were CGI written in Perl. Then I started with ASP, the old Microsoft Active Server Pages with the Access database in the beginning, and then they became ASP.NET with SQL Server. My agency, that was F2, when I was 17. I opened F2.net, and this is why I have this short domain name, which is f2.net, which is the domain of my agency. When we saw that the world was moving to the separation of concerns between backend and frontend, we started using Angular on the front end and ASP.NET Web API for the backend. Then there was a moment when we were starting a big project for the biggest Italian trade union. Angular 2 had just come out and it was completely different from Angular 1. We were upset by this. So what do we do? We use Angular 1, which is already legacy? We use Angular 2, which just came out? Let's go with React. So we took the risk to go with React, and we never came back. I really love React. I find no reason to switch. Then we abandoned the Microsoft technologies for the backend. We started using Node.js with MySQL or Postgres. That is our stack. It is the stack of React Bricks and the stack that we use for every project.

[00:29:01] React Bricks started when I saw that we needed something more for our customers, because we are mainly a web development agency that develops web applications, from e-commerce to production management, IoT, things like that, or also custom ERPs. We were a company that created web apps, really, because now we are concentrated on React Bricks mainly. We still do some work for customers, but our idea is to just concentrate on React Bricks for the future. We were creating web applications, and sometimes customers asked for websites. It happens. You don't want them to go to another agency just for the website, so okay, we do the website part also. For that we were using Gatsby together with WordPress. I was upset with the developer experience. I thought that the experience of our users with the famous gray forms was also not great. By the way, at that time, at the end of 2019, I had just done Y Combinator Startup School for another project that was in headless e-commerce. My idea was to create a headless e-commerce, and then I pivoted that idea to what is now React Bricks.

[00:30:19] Then it was the period of the first lockdown. In a way there was less work, so it was a good moment to start something new. During the first lockdown, I created the prototype for React Bricks and I liked it. I believed in it, so I asked my colleague, my co-founder Dario, to create the backend part. It all started then.

00:30:54 - Christopher Burns

Yeah, this is really interesting, and something that we've not touched on until this moment is that you are European, you're from Italy. This is not something we hear of often, but there are not many Italian tech companies that I know of. If I remember rightly, when it came to Covid and being in Europe, Italy was actually one of the first countries to be locked down. Yes. And then [unclear], something like that, and then the whole world went terribly.

00:31:18 - Matteo Frana

Yes, yes. I am from Bergamo. It is a part of Italy. It was hit hardest at the beginning of Covid. So, yes.

00:31:28 - Christopher Burns

A lot of lockdowns happened. Let's not obviously focus on that part because of how it is, but obviously what that allowed you to do is start focusing on React Bricks. I am a big supporter of it, and as you said, it's completely bootstrapped from an agency. I've seen something similar myself, coming from this experimental agency world to building a product ourselves. Agencies are great because there's always something different to work on, but I feel you: you long to just work on your own project and just tackle one thing every single day. Have you felt that?

00:32:00 - Matteo Frana

Yes, it's true. It's great to work on different projects and to see different realities. If you are creating a web application for drums production, you learn everything about how drums are created. Then you do an application for a textile industry and you get to learn everything they do. It's interesting because it's not just the programming part. When you do the analysis, you come in touch with many things and you can learn much from all the different sectors that you work with. For example, you create many e-commerce applications in the pharmacy sector, and so you come to learn everything about that.

[00:33:24] But in some way, having your own product is the dream, because sometimes working with customers is great and sometimes it is less great. It happens that you have customers that don't understand the quality of your product, don't pay, etc. When this happens, you want to leave that part and create your own products. It's not easy. In the past, we also created another product that completely failed. That was a social network based on interests. It was a text chat. It's not easy to start something that really solves a problem. In this case, with React Bricks, we had that problem. We knew the context quite well, so we invested much in it because I believed that it could be useful not just for us, but for other agencies.

00:33:52 - Christopher Burns

To start closing it out, I think the first thing anybody can do is look at three websites of choice. These are from the examples page. It's Catbase, Everfund, and Woosmap. These are all built on React Bricks. Really good examples of longevity. Today I saw someone on Twitter who built a Snipcart slash Algolia website with React Bricks as well. What you can do with React Bricks is obviously infinite, and I really do suggest giving it a go.

[00:34:48] The next thing is, on your website, you can just give it a go. You've built this demo playground, just allowing you to customize it. You don't want to just start with your own website. You just want to give it a go, understand the CMS, and I think that is really, really cool. The last really big thing I wanted to touch on was the learn documentation that you wrote. I am a big fan of teaching people how to do things.

00:34:48 - Anthony Campolo

Absolutely.

00:34:49 - Matteo Frana

Of course it's necessary to have all this long documentation. It's difficult to keep it up to date. Sometimes features start in documentation and then we implement them, and when it happens the other way, we need to remember to document everything. But really, with TypeScript it's easier because you can look at all the TypeScript interfaces and all the TypeScript types and see if you forgot something in the documentation. I think that React Bricks now has grown into a framework, so it's difficult to grasp everything when you start using it. So the documentation really is useful to discover something when you need it. If you need a particular feature, you can look it up in the documentation. But maybe the best way to learn how to use React Bricks is the step-by-step tutorial.

[00:36:02] If you go to React Bricks slash learn, there is the link. You see the step-by-step tutorial, and that is a tutorial with gamification. It starts from the CLI up to creating your bricks and deploying on Vercel or Netlify.

00:36:02 - Anthony Campolo

I absolutely love this, having actual curriculum with challenges associated with it. It makes such a difference in terms of how people actually retain content, and so this is really cool that you built this out. What was kind of the impetus for this? Did you have someone on the team who was into curriculum design, or is this just something you came up with yourself? Where did this come from?

00:36:25 - Matteo Frana

I did it myself. Really, the whole website.

00:36:29 - Anthony Campolo

It's really impressive.

00:36:30 - Matteo Frana

Also the UX of the React Bricks admin and the tutorial, I did it. I am a developer, but I always loved interaction design. So I have many, many books about interaction design. Surely I'm not a designer, I'm not the best interaction designer out there, and an interaction designer could do something better than what I do. But it's something that I really like. I like the fact that by studying the UX or the interaction, you can affect the way that many people work. I love to try and think of better alternatives when I think of UI or UX. So I like also this part of front-end development.

[00:37:49] As for the tutorial, we looked at the Next.js tutorial, really, because that was my inspiration. I have to say that I saw the Next.js tutorial and I really liked it, but there you gained points just advancing on the pages. I wanted something that was more challenging, so I introduced questions with answers, and you gained more points if you answered the question correctly. Then there is a final surprise that I cannot say. So when you do the tutorial and if you have enough points, you will discover the final surprise in the last step.

00:37:58 - Christopher Burns

Yeah, this is honestly how I actually learned to use React Bricks. I went through the step-by-step, and I tend to be just a tinkerer. Just spin it up, get it working, and just tinker away with it until you're done.

00:38:12 - Anthony Campolo

If you got Chris using one of your tutorials, that's high praise. Chris is definitely not a tutorial person.

00:38:17 - Christopher Burns

You say that. I normally run through a tutorial first and then chuck it away and never look at it again. But there is a place for this, and I think it's really a testament to what you've built. I think it's really important for people to give it a go if they need to build a marketing website because, like I said, we may understand gray forms and boxes that we can move around, but when it comes to your non-technical marketing person, they sure do not like that.

00:38:45 - Matteo Frana

If I can anticipate something that is coming, if you want to know something that nobody knows yet.

00:38:54 - Christopher Burns

Yeah, please do.

00:38:54 - Matteo Frana

We just released the shareable preview link so that you can get a preview link that is independent of the platform. It works with Next, with Gatsby, with Remix. You can have a preview link of a page so that you can share it with anyone without a React Bricks account. They can see the preview of a draft page. But what we are working on right now is the editorial calendar. So in React Bricks, you can schedule the publishing of content. We have customers that want to know what is coming out tomorrow, what's the article that will be published tomorrow, and so we will release very soon an editorial calendar where you can see the pages that are scheduled day by day. You can click on a page and go and edit it directly from the calendar. Then we'll add the ability to customize the login UI a bit.

[00:40:02] Some customers don't like the pink sofa that you find now on the login page of React Bricks. They want to change it or put their logo on the login page. So we will work on a way to customize it. Another thing is the ability to select bricks in a more visual way. Now you have the name of the bricks, but I'd like to save a preview of the component so that users who have not used your design system for long and don't know the components by name can just see the components, click on one, and add it. This is especially useful for stories. In React Bricks we have the concept of stories. If you have a brick, you can save it in a certain configuration. You change the text, you change the props, you like it, and you save it to reuse it later. It is a story.

[00:41:06] So the ability to choose a story visually, I think, will improve the UX for users. So you have the blue, the green, the pink story, but if you see them, you can click on one and just add it. In the long term, as I said, we want to implement entities, the headless part, like a headless CMS. But a very important thing we want to implement is layout components. At the moment, a big limit of React Bricks is that bricks are, in a way, block-based. It's not easy to implement a two-column interface. Think of a newspaper where you have a two-column interface and you want to add bricks to it. At the moment you can have a brick with two columns, of course, but what we want to create is the ability to have slots inside bricks.

[00:42:09] So you can have bricks which define the structure, and they define two columns, for example. Then you have a slot on the left with its allowed block types. They allow the bricks for the left part. Then you have a slot on the right side, where you can define the allowed bricks for that side so that it is much more flexible. This is a thing that we have designed, we have shaped, and it just needs to be implemented.

00:42:09 - Christopher Burns

I can't wait to see actual snapshots instead of names for your bricks, because no matter if you're a non-technical person who can edit it, your bricks are still named feature one, feature two, feature three, grid one, grid two, grid three. And it's just the grid in different formats.

00:42:27 - Matteo Frana

Yes, it's true that you can hover over a brick and see a preview without really adding it, but choosing visually will be much better.