I’m currently working on Bedrock 3, and I wanted to share some context about why I’m bringing this project back to life.
Bedrock was a static site generator designed to create HTML/CSS prototypes, originally released in 2015 under an MIT license. We used it heavily at my previous design company, Mono.
Bedrock 1 (2015)
The idea behind Bedrock 1 was solid for its time. We wanted to give developers a set of HTML/CSS templates along with a styleguide documenting all the components used.
Components, in this context, simply meant HTML and CSS—nothing more complicated than that. We relied on Bootstrap and other known frameworks, combined with a series of repeatable aspects we got really good at: generating icon fonts, customizing Bootstrap themes, and so on.
Where Bedrock 1 really shined was showcasing complex user flows and managing hundreds of components. Our prototypes powered some of Belgium’s biggest scaleups. We maintained Bedrock 1 for seven years.
Around the same time we started, React, Vue, and other JavaScript frameworks began gaining serious traction. The expectations for what constituted a “front-end deliverable” started to shift.
Over time, it became increasingly difficult for a design team to deliver front-end work. The frameworks kept becoming more complicated. From adding TypeScript, to library complexity itself (i.e. React hooks), to build pipeline problems (remember Grunt and Gulp?), and so on. The complexity kept compounding. At the same time, design tools were getting stronger. Figma’s feature set kept growing, and around 2018 the vibe shifted towards using Figma prototypes as the design deliverable. In general, the need to show design in the browser became a little less important.
It’s also around this time that I essentially gave up on teaching new designers how to code. There was a disconnect within the Mono team: both founders both had 10+ years of design experience including writing front-end code, while most employees came straight out of school, or had just a few years of experience (but with no code background).
When they were learning to code, they were learning the wrong things. People were enrolling in React bootcamps before they understood semantic HTML or how to properly work with CSS. They were dealing with problems that were completely irrelevant to a design deliverable (understanding what useEffect does is an example). The whole point was always to deliver a prototype that showed how the app or website should work. That’s it. But the general learning materials around learning what front-end development for a designer constituted got completely warped.
From a founder’s perspective, we also had many thoughts about the word “prototype.” In a way, it vastly undervalued our deliverable. Most of the code we delivered was essentially production-ready. Calling it a prototype made it sound like throwaway work, when in reality it was often solid, reusable front-end code (depending on how long projects went on). As founders we did grow up fixing IE6 bugs and we knew how to express design in CSS at quite a deep level.
Most front-end developers at the time were busy with other things than what concerned us. Front-enders were dealing with APIs, grabbing data with GraphQL, fixing iframe security issues — and on top of that dealing with the idiosyncrasies of something like React performance issues.
As designers, we had other concerns—accessibility, web performance, visual look, coherence. What ended up happening was that the combination of the work of the “real” front-end engineers and our design-related front-end work via the Bedrock 1 deliverable provided a great base for the front-end.
The prototype work was received well by our clients: managers loved they had a prototype that would never break and used it for sales. Backend developers loved that they didn’t have to deal with the parts of the front-end they didn’t care about. Dedicated front-end developers were happy to take the design vision and then apply their layer of work on top of it. But something was missing.
Bedrock 2 (2018)
Around 2018 I got the idea to create Bedrock 2. The intent was to use React, Vue, Angular, Ember.js or Svelte as the deliverable format. Whatever framework the client was using – there would be multiple flavors of Bedrock depending on the client’s needs.
I did some work on this, creating versions for Vue (Nuxt), Next.js and Sapper (now SvelteKit). We actually used bedrock2-angular and bedrock2-ember to ship work in client projects. It was good,but but the idea ultimately got abandoned because of the mismatch I mentioned earlier: designer skills weren’t keeping pace with front-end frameworks getting more complicated. Ultimately the skill to do this work remained with the founders and 1 particular employee who did bridge the gap to do both design and front-end development.
Around 2021, we disbanded Mono. After Mono, I worked as a product designer at Doccle for a few years. Within that job, I learned more about React and TypeScript.
A bit before, I became a Svelte enthusiast, following the project heavily from 2020 until now. During 2020 to 2024 I upped my front-end skills, but still felt uncomfortable writing certain types of code because of the ergonomics—heavy TypeScript, for example.
I mostly returned to product design and designing in Figma; but the itch to deliver part of the work in the browser remained, and I found myself sometimes creating front-end prototypes for specific purposes.
Bedrock 3 (2026)
Fast forward to 2026. Why revive Bedrock now?
- I have an agency again and there is a need for a structured deliverable, that can also be taught to designers internally
- It’s now realistic for a designer to prompt code; AI has made this possible in a way that wasn’t before. With the right tool
- With how people are working across design and development, there’s a massive need for a cohesive deliverable that can serve as a source of truth.
Right now, design work is scattered everywhere: Figma Design, Figma Make, front-end prototypes on tools like Lovable, and design prototypes that aren’t even made by designers anymore—they’re made by PMs, front-end developers, or just about anyone with a brain and access to an LLM.
When we worked on Bedrock at Mono, we got really good at our deliverable. We had branch-based prototypes to show design changes and facilitate discussions. We had clean URLs that could reference the design system. We had static documentation. All in one place. That cohesion matters.
The deployment space is also a problem. It’s dominated by too many VC-backed companies, when all you really need is a little VPS somewhere. Cloud deployment of prototypes should be simple—they tend to be static, with no backend to worry about.
I’m building Bedrock 3 primarily for our own needs—for client work happening at Obra Studio. But I’ve started thinking about how it could function as an open source project.
A general idea that survives from the never-shipped Bedrock 2 are the “flavors”. Different versions of Bedrock 3 would exist for different needs: bedrock3-shadn-react, bedrock3-vue-nuxt, bedrock3-nunjucks etc. Some of the needs are based on the template language used, some on the underlying metaframework or JS component tech, some on the UI framework used (e.g. shadcn). Splitting this up elegantly will be a challenge but it will mostly be informed by client work. For example, one of our clients uses Angular, so we will definitely have an Angular variant.
I am thinking of eventually providing a CLI tool to set up your Bedrock the way you want it.
Here are some early screenshots:
Storybook running in Bedrock 3 – We standardize on Storybook
I’m a massive believer in open source. Just like with our shadcn/ui kit, we will likely be open sourcing most of these tools.
We’re a design agency – when we’re out of the picture—which is simply what happens after a design delivery for a one-off project — anybody finding the deliverable can look at the documentation. The underlying logic and code is still there for anyone to use. That just makes for a professional deliverable people can use to bring their apps further.
If you’re curious to follow along with Bedrock 3’s development, keep an eye on @usebedrock on X, or subscribe to the Obra newsletter. If you want to talk about how this can help your company, get in touch!