By Michael Kubler | kublermdk.com
TLDR
Cards, Cables, Concrete is a three tier mental model for gauging how much effort it takes to change something.
- 🃏 Cards: Easy to move, no commitment. Like Post-it notes on a whiteboard, chalk drawings at a construction site or lines on a blueprint.
- 🔌 Cables: Wired up and working, but rewiring takes real effort. Doable, but not free and possibly needs an expert.
- 🪨 Concrete: Locked in. Changing it means jackhammering or moving heavy slabs. Costly, time consuming, likely needs a team of people and it’s potentially damaging.
Use it to ask: “Is this change a card, cable, or concrete situation?” before committing time, money, or people.
The Problem This Solves
Every decision sits somewhere on a spectrum between “trivially reversible” and “effectively permanent.” Most people intuitively sense this, but without a shared vocabulary, it’s hard to quickly communicate just how hard a change will be, especially in a team context.
The phrase “That’s going to be hard to change later” doesn’t really convey the difference between spending an afternoon on a refactor versus ripping up six months of architectural decisions. Cards, Cables, Concrete (CCC) gives you a precise, memorable shorthand for that spectrum.
This isn’t about whether a decision is good or bad, it’s about the cost of making the change. Knowing that something is “concrete level” doesn’t mean you shouldn’t do it. It means you should be sure before you do.
It means you know that this will take serious resources.
Where This Idea Comes From
This model builds on another mental shorthand: Hats, Haircuts, Tattoos which is a way of thinking about how long you’ll have to live with a decision.
- A hat you can swap in seconds.
- A bad haircut you’re stuck with for a few months.
- A tattoo is effectively forever, removal is painful, expensive, and never fully clean.
That’s a useful framework for duration. But there’s a different and equally important question: not “how long will I live with this?” but “how hard is it to actually change?”
That’s what Cards, Cables, Concrete answers. The two frameworks complement each other nicely. You can use Hats/Haircuts/Tattoos to assess permanence over time, and CCC to assess the effort cost of making a change at any given moment.
The Three Levels Explained
🃏 Cards: Zero Friction, Full Flexibility
A card is anything you can pick up and move in seconds without consequence. The name comes from the physical act of laying cards or Post-it notes on a table. Maybe UI elements on a wireframe, or placeholders on a floor plan.
It’s why Figma is so well liked, you get high fidelity mockups relatively fast.
If you are sketching the design of a house, then moving the light switch, power socket or door isn’t that hard in 3D.
At the card stage, nothing is wired up, nothing is committed. You’re working in the realm of blueprints and chalk outlines. If you draw a line in the wrong place, you rub it out and draw again. Change is essentially free.
The card phase is the natural home of brainstorming, wireframing, prototyping on paper, and early stage planning. The key property isn’t that things are simple. Your card stage plan can be highly detailed. It’s that the cost of changing your mind is near zero compared to the next stages. Cards invite you to try things, discard them, rearrange them, and try again without penalty.
Measure twice, cut once is the classic carpenter’s wisdom that maps to this stage perfectly. Spend time in the card phase. The cost is low. The leverage is high.
🔌 Cables: Real Work, but Rewireable
Once you move from planning to implementing, you’ve entered cable territory. Things are now physically (or digitally) wired up. They function. They exist. But the wiring can still be changed, it just takes a decent bit of effort.
Think of a button on a physical test bench with a cable running to it. If you want it somewhere else, you have to unplug it, run a new cable, and plug it back in. Not impossible, but not free either.
If you want the button to do something else, you’ll have to reprogram the logic.
In software, this is going from a Figma mockup to a React component that has a wired up implementation. Move a button into a different component and you’re now dealing with event handling, state management, and cross-component communication. You can do it, but it’s a longer, more cumbersome job. Rewiring costs time and sometimes causes complexity as it’s not what was expected and developed in the first pass.
In construction, this is when the electrician has run cables through the walls and installed your light switch. You can move it, drill a new hole, run a new cable, but it’s a noticeable investment of time and money compared to erasing a chalk mark on a blueprint.
🪨 Concrete: Locked In, Jackhammer Required
Concrete level changes are the ones where the cost of change is so high that it effectively constrains your future choices. The infrastructure is set. Trying to modify it means cutting through something structural and even if you succeed, you may leave permanent scars behind.
The metaphor is literal: Plumbing embedded in a concrete slab. You want to move the toilet drain 30cm to the left? That’s a jackhammer job. You’ll break out the concrete, relocate the pipe, pour new concrete, and hope the new material bonds well. Roads are a perfect real world example. Whenever road crews cut into a surface to lay a pipe and then patch it back, you almost always end up with a pothole at that exact spot, because the new concrete has different thermal expansion characteristics than the surrounding material and weathers differently. The scar is there until they resurface it, which is rarely ever.
In software, concrete level changes include things like your core data schema, your fundamental API contracts, or a deeply embedded architectural pattern that hundreds of other components depend on. Changing these ripples through everything. It’s not that it can’t be done, it’s that the cost is high enough to make you think very, very carefully before committing.
Examples Across Domains
🏠 Construction and Architecture
This is the domain where the metaphor lives most naturally.
| Stage | Example |
|---|---|
| Cards | Drawing chalk lines on a floor to mark where walls, light switches, toilets, and ethernet ports will go |
| Cables | Cables run through drywall, light switch installed, plumbing roughed in, hollow walls still accessible |
| Concrete | Plumbing embedded in a poured concrete slab. Decorative marble panels installed around fixtures |
That last example is worth pausing on. Imagine a beautifully carved marble panel housing flush buttons in a luxury bathroom. Those buttons had better be in exactly the right place, because cutting and re-polishing marble is a specialist job and too many cuts risk compromising structural integrity. The aesthetics demand perfection on the first attempt.
💻 Software and Web Development
Software development is one of the best domains to apply CCC, because the distinction between card, cable, and concrete can easily blur if you’re not paying attention.
| Stage | Example |
|---|---|
| Cards | Low (or high) fidelity wireframes, Figma mockups, a 3×4 card grid showing a UI layout |
| Cables | A working React component wired to an API, state management in place, buttons with handlers |
| Concrete | Core database schema, public API contracts, a distributed microservice architecture with deep inter-dependencies |
The classic developer trap is moving straight from idea to code without spending enough time at the card stage. Once something is wired up and in production, the cost of restructuring multiplies rapidly. A UI element that took 20 minutes to mockup might take 2 days to refactor once it’s deeply integrated into a live system.
Thankfully yes, AI has changed this a lot and what used to be considered a Cable, such as a single page working prototype with working buttons and even animations, is now more like a Card. It’s relatively easy to change using tools like Cursor, Codex or Claude Code.
Database schema is one of the most expensive things to change in a mature system. Adding a column is a cable change. Restructuring the relational model of a table that thousands of queries depend on? That’s concrete, you’re looking at migrations, data transformations, and carefully coordinated rollouts.
Even worse is migrating to an entirely new (often Key Value pair but highly scalable) database system.
📅 Meetings and Scheduling
Scheduling is a beautifully mundane domain where CCC maps precisely onto everyday experience.
| Stage | Example |
|---|---|
| Cards | A meeting on the calendar six months out. Rescheduling is a couple of clicks and barely affects anyone |
| Cables | The meeting is next week, other meetings have been arranged around it, someone’s booked a venue or blocked off preparation time |
| Concrete | You’ve already flown to another country for the event. The event changing time, now means missing a flight or booking a new one |
The key insight here is that the same meeting can shift from card to cable to concrete over time, purely based on proximity and how much effort has been built around it. Rescheduling a conference six months out is trivial. Rescheduling it when attendees have already landed in the city is a crisis.
🎪 Events and Festivals
Scale the scheduling example up and the stakes become dramatic.
An outdoor music festival scheduled for Easter weekend might be a card situation eight months out. The date is announced but flights aren’t booked, accommodation isn’t confirmed, and nothing is locked in.
Move the goalposts by six weeks with one week to go, and that’s like ripping up the foundations for 20,000 people simultaneously. Hotels are booked and non-refundable. Flights are purchased. People have arranged time off work. The ripple effect of that single date change propagates through the schedules of every single attendee. What feels like a small administrative change from the organiser’s side can be a concrete level disruption for thousands of attendees.
How to Use CCC in Practice
The value of the model isn’t just in classifying decisions, it’s in making sure you’re doing enough work at each stage before moving to the next.
1. Spend generously at the card stage.
Paper is cheap. Figma is cheap. Chalk is cheap. The card stage is where you should be exploring widely, testing assumptions, and actively trying to find flaws in your plan. Every hour spent here can save days later.
2. Move to cables deliberately.
The moment you start wiring things up, the cost of change rises. That’s fine, it should rise, because you’ve done the thinking. But don’t start running cables until you’ve done what you can at the card stage and need the feedback from actual wiring up and interactivity.
3. Label your concrete decisions explicitly.
When something is about to become concrete. A database schema, a product API, a legal commitment, a building foundation, etc. Say out loud: “This is a concrete decision. Once we do this, changing it will cost $XXXX.” That shared awareness changes how a team approaches the decision.
4. Use it as a communication tool.
In meetings, on Slack, in pull request reviews: “Is this a cable level change or are we talking concrete?” creates a shared frame of reference. It cuts through vagueness and gets everyone calibrated on what’s actually at stake.
5. Recognise when time converts cards to concrete.
A thing that is a card today may become concrete next month, not because anything changed about the thing itself, but because the surrounding system grew around it. Track your cards. If something has been sitting for too long without being decided, the environment may be quietly converting it to cables and concrete on your behalf.
CCC vs. Hats, Haircuts, Tattoos
These two frameworks ask different questions and are best used together:
| Framework | Core Question | Dimension |
|---|---|---|
| Hats, Haircuts, Tattoos | How long will I live with this decision? | Duration / permanence |
| Cards, Cables, Concrete | How hard is it to change this? | Effort / reversibility |
A decision can be any combination of these. A tattoo level commitment (permanent) might still be a card-level decision in terms of effort, signing a simple lifetime contract, for instance. Conversely, a hat-level commitment (easily changed) might have cable level effort. Like moving a piece of furniture that requires disassembly.
The most important quadrant to watch out for is the one that’s both high permanence and high-effort to change. Tattoo + Concrete.
These decisions deserve the most deliberation, the most card-stage exploration, and the most explicit acknowledgment before you commit.
The Deeper Principle
At its core, Cards, Cables, Concrete is an argument for front loading thinking and back loading commitment.
The systems that age best, whether they’re buildings, codebases, organisations, or plans, are the ones where the designers spent disproportionately long in the card stage. They explored, they iterated, they challenged assumptions, got alternative perspectives from people with experience and then they committed.
You often get issues where people were impatient to get to the cabling. They started wiring before the layout was settled. They poured concrete before others were sure about the plumbing. This usually leaves people with a bad setup, or high costs.
Before your next big decision, ask: Am I really still in the card stage? Or am I about to run cables? If so is the blueprint ready?
Michael Kubler is a technical co-founder of Drivible, podcast host of Abundant Mars, an advocate for an Abundance Centred Society and is currently working on the ATLAS project.
Find his other posts at kublermdk.com.
