Yesterday I was working on the Angular and React versions of Bedrock 3. The Angular version has been tested with a real prototype. The React version is early but coming along nicely.

What is Bedrock 3? It’s a layer on top of a dev environment that helps you make sense of your project when it’s still in a design phase. For more context, see my previous blog post.

There are currently 3 “flavors” of Bedrock in existence:

• bedrock3-nunjucks – Static HTML/CSS/JavaScript
• bedrock3-angular-tailwind4 – Angular 21 + Tailwind CSS 4
• bedrock3-tanstack-shadcn – React + TanStack Router + shadcn/ui

It is easy to make new “flavors” of Bedrock when needed; with Opus 4.5 I was able to set up the tanstack/shadcn version in just 20 minutes.

What this means is that for any given tech stack, we can deliver a base working environment where designers can make prototoypes; or where developers can prepare the front-end in a stack that closely resembles the production stack.

Each Bedrock flavor comes with a built-in Storybook.

Let’s give an example: imagine you are using Nuxt/Vue.js in your project. Your main project in development is going through a redesign. How would Bedrock fit into this logic?

1. Designers are typically using Figma to design screens, and they might have a few prototypes in Figma Make, Lovable, or other tools (important: these don’t use Vue.js)
2. Product managers are typically using Miro/Figjam, some kind of issue tracking tool like Linear/Jira/Github issues
3. Front and back-end developers have versions of the real codebase (i.e. using Nuxt and Vue.js) in various states of development. They also make their own prototypes (typically they do use Nuxt/Vue.js since they know how to work with their own tech stack)

How can all these parties work together?

My vision is the following:

1. Designers keep working in Figma for the visual layer – you need the canvas environment to decide what things will look like
2. Technically-oriented designers, product managers or front-end developers can then make Bedrock-based prototypes of the designs.
   • Depending on the needs they choose the right Bedrock flavor. Not all Bedrock flavors are the same: the base bedrock3-nunjucks is much easier to work with than bedrock3-angular-tailwind4.
     • If the need is to get design validation my choice would be to use the simplest stack (standard html/css). The designer doesn’t have to deal with Vue or Tailwind: they just get to a result.
     • If the need is to prepare production code my choice would be to use the stack that is closest to the production stack: Bedrock3-nuxt-vue-tailwind.
   • Over time, a designer might move to use Bedrock3-nuxt-vue-tailwind instead of Bedrock3-nunjucks (regular html/vanilla CSS)

Why all these flavors?

Bedrock tries providing an environment that is close to the actual stack. If the end result is going to be shadcn/ui and React, you might as well “vibe code” in an environment that has shadcn/ui and React. If you know what your design system should look likem you have a set of known assets, you are using Tailwind, a specific icon set, or anything like that, it should be embedded in your prototyping environment.

Why not Lovable or Figma Make?

The problem with Lovable and Figma Make is they are too basic for larger prototypes.

1. At their core, they are always React-based. Not everyone uses React. It might not matter for design validation (see below) but over time, the disparity between versions becomes a source of frustration
2. These tools struggle when codebases become too big.
3. They don’t actually know about your design system in a meaningful way
   • For Make, the feature where Figma links to your design system is an exercise in frustration
   • For Lovable, there is no link to your design system at all

The way I work & how Bedrock fits in

What you need to do to be productive, in my opinion, is use an agentic coding tool like Claude Code or OpenAI’s Codex. Personally I pay a good amount of money every month for these tools to help me code prototypes and do front-end work.

I prompt to implement screen designs, while retaining my component context in Storybook. Sometimes I focus entirely on the components to have a good base to build the screens. Other times I am entirely focused on the screens themselves.

I use Bedrock for both types of work:

• Get design validation: it’s much easier and productive for me to make an AI-based prototype than it is to detail everything in a static design tool like Figma (although I use Figma in a phase where we are figuring things out)
• Prepare front-end code for production: in this case I also use Bedrock, in a flavor that resembles the production code as much as possible

In both cases I heavily rely on the built-in Storybook integration to see what my components look like, and to steer the AI agents in the right direction.

While we develop these tools internally at Obra.studio they are not open sourced yet. Do reach out if you are interested.