March 2016, a Frustrating Search
Back in early 2016, I needed a simple one-page site for a side project. I went looking for a drag and drop web builder. Something I could use without learning HTML or CSS. What I found was either a bloated multi-page editor with a steep learning curve, or a template-based tool that locked me into a rigid layout. None of them felt fast. None felt mine.
So I did what any solo maker with a bit of free time would do: I decided to build my own. Here’s how it went, the doubts, the messy parts, and the moment it all clicked.
The Core Idea: One Page, One Stack
I knew from the start that this builder wasn’t going to be everything for everyone. The product’s narrow focus was intentional. It would only build one-page sites. No dashboards of pages. No multi-level menus. Just a single stack of elements you could drag, drop, and customize.
That constraint gave me permission to make the interface really simple. I didn’t need to worry about routing, page hierarchy, or complex state management. The whole editor could be just three parts:
- Canvas — the live preview of your page
- Panel — the control panel for tweaking elements
- Menu — the top bar with actions (undo, save, preview)
All looked great on paper, but how would it play out in practice?
Building Without a Framework
I made the call early on to skip React, Vue, or Angular. I went framework-less with vanilla JavaScript and jQuery. That decision wasn’t about being a purist. It was about control. If I hand-rolled everything, I’d understand every line. Bug-fixing would be easier. Adding features would mean writing the code myself, not learning a framework’s patterns.
It also forced me to learn things a framework would have hidden. Scroll positions, event delegation, async loading, I had to own it all. Worth trying at least once.
The trade-off? More initial code. But the builder itself stayed lightweight. It could run largely independent of the backend, even on low-spec hardware and smaller screens.
The Three-Panel UI: Canvas, Panel, Menu
After a few months of iteration (and an early-2015 mockup that looked surprisingly close to the final design), the interface settled into its final form. I called it the Canvas, Panel, Menu pattern.
- Canvas — This is where you see your site update in real time. Drag an element from the panel, drop it onto the canvas, and you’ll see exactly what visitors will see.
- Panel — Every element you add has its own settings. Text style, image source, background color, padding — all right there, no hidden menus.
- Menu — The top bar holds undo/redo, preview, save, and export. That’s it.
The whole thing fit on one screen. No tabs. No side bars that slide in and out. It was minimal in style and (I hoped) self-explanatory.
The Generator: Automating the Spec
I also built a companion tool I called the Generator. Its job was to take the “site spec” (the list of elements and their settings) and produce the actual HTML, CSS, and JS files. That decoupling meant I could iterate on the spec without rewriting the builder logic.
During testing, I realized the Generator could do more than just profiles. A small addition, wrapping the stack in a box, unlocked far more customization while staying true to the core pattern. Suddenly the tool was capable of cranking out a gorgeous site in under 5 minutes for almost anything: a landing page, a portfolio, a wedding invite.
Dividing the Monster Into Five Parts
The whole project, builder, generator, dashboard, site rendering, and paid plans, felt huge by my past standards. So I broke it into five subprojects and tackled them one at a time. The Builder was the centerpiece, but the Generator got finished first. Then the Dashboard for managing sites, then the Site (the live page), and finally the Paid Plan stuff.
That modularity kept me from feeling overwhelmed. Each subproject was small enough to finish in a week or two.
The Results: Really Good
When I finally tested the builder on a real project, a friend’s band website, much to my surprise, the results were good. Really good. The site loaded fast, looked crisp on mobile, and the drag and drop web builder felt responsive even on a cheap tablet.
I also added downloadable code, HTML, CSS, and JS for any site you create. That meant you could build in Carrd, then take the code and host it anywhere. (It requires the Pro Plus plan, but the option is there.)
Why Multi-Page Isn’t the Goal
People ask: “Can it do multi-page?” No. And it won’t. Not because I can’t add it, but because adding multi-page would break the simplicity that makes this thing useful. A drag and drop web builder that tries to do everything ends up doing nothing well. Short of me royally screwing up the current design, I intend to keep it one-page forever.
If you need multi-page, you’re better off with a tool that’s built for that. But if you just want a single, beautiful, responsive page without the overhead, Carrd is for you.
Final Thoughts
Building Carrd taught me that constraints are liberating. The product’s narrow focus, one page, one stack of elements, three-panel UI, created a natural limit to its complexity. That made it easy to use, design, and maintain.
And for the record: it wasn’t 2006. Modern CSS Grid and flexbox made responsive layouts trivial. I didn’t have to build a WYSIWYG from scratch. I just had to wrap each element in a smart container.
Today, Carrd is a free drag and drop web builder that runs in your browser, works on phones, and spits out clean code. If you’ve ever wanted a simple one-page site but found other tools overkill, give it a try. It’s simply built, customizable, and responsive, just like I wanted back in March 2016.