This interview is with Anik Devaughn, Founder & CEO, Wired to Create.
For Connectively readers, who are you and what are you building right now as Founder & CEO of Wired to Create and Karo in information technology and services?
I’m Anik Devaughn, founder and CEO of Wired to Create, a holding company building AI-native ventures across tech, media, and the creative industries. Rather than a single-product company, it’s a portfolio built around one idea: the future belongs to those who create. In the modern age, as technology increasingly replaces the work and skills of specialists, we need innovators. Our ambition is to restore people’s lost creative power and build companies and products that thrive on creativity and unorthodox organizational and product structures. We believe companies that are AI-native and have true creative direction and leadership from day one operate fundamentally differently than those that bolt AI onto an existing structure.
One of our first public ventures is Karo, an AI-native point-of-sale and back-office platform. It’s fiscally certified, partnered with Worldline on payments and Visma on ERP, and our first commercial deployment—a Swedish retail chain migrating off the enterprise incumbent—goes live in summer 2026.
What makes the work distinctive isn’t the product; it’s the shape of the company behind it. My operating thesis is that, in the AI era, the org chart is the moat, not the codebase. A competitor can copy any feature; they can’t copy the company underneath it without rebuilding from zero. Specialists build features. Polymaths build companies and drive innovation. We build without venture capital by choice, because the freedom to move is worth more than capital that constrains it.
I came up through music, dance, big tech, and design before building companies, so I tend to architect a company the way you’d architect a creative work: structure first, with the product as the thing that comes downstream of it.
Right now the focus is getting Karo’s first deployment live this summer while building Wired to Create into a portfolio that proves the model. I’m not predicting where AI takes business from the outside; I’m building from inside it. Our next big launch is a global artist we’ve been working with for years, Prince Kim, which will introduce a disruptive way for independent artists to take over the entertainment industry.
How did your path from hip hop dance and audio engineering to founding an AI‑native retail platform shape the way you approach UX/UI and product leadership today?
The honest answer is that multiple disciplines in the creative industries (dance, music) taught me creative leadership before I ever called it that.
Popping — the dance style — is about precision inside a feeling. You’re not just hitting a move; you’re making something technically exact read as effortless to someone watching. That’s UX. A good interface is precise engineering that the user doesn’t perceive as engineering. They just feel that it works, that it’s smooth, that it understands them. Every hour I spent making something hard look easy on a stage is the same instinct I bring to a screen, to a product, and to business. The experience should always feel inevitable.
Music taught me the opposite but complementary discipline: structure underneath the feeling. A great track is emotion sitting on top of an extremely deliberate technical foundation — levels, timing, space — things the listener never consciously notices but absolutely feels if they’re wrong. Product is identical. The user never sees the data model or the architecture, but they feel it instantly when it’s badly built. So I design from the experience backward: what should this feel like? Then I build the structure to deliver that, rather than building the structure first and putting an interface on at the end.
That’s actually the core of how Karo is built and why it’s different. Most retail tech is engineered first and the interface is whatever the database happens to allow. We do it backward, on purpose. We sketch and prototype the operator’s actual task, the cashier’s real moment on the floor, and only then build the data model to serve it. Design first, engineering downstream. That’s not a tagline; it’s the literal sequence, and it comes straight from a life spent making technical things feel human.
As for product leadership, the through line is that I don’t believe in specialists running the show. A dancer who also engineers audio and builds companies isn’t scattered; they’re someone who sees the whole thing at once if they’re truly good at it. Unfortunately, a lot of people are misguided and therefore scattered. There’s an art to the craft of polymaths. Specialists optimize their slice. A polymath holds the entire experience in one head and refuses to let any single layer win at the expense of the whole.
Zooming into Karo: when you designed the POS and back‑office UX for Nordic multi‑store retailers under tax‑agency certification, what was the toughest usability‑versus‑compliance trade‑off you faced, and how did you resolve it?
The honest tension in Swedish retail tech is that compliance is non‑negotiable and often ugly, while good UX is about removing friction; those two forces pull in opposite directions. The majority of enterprise SaaS products are built by engineers for engineers. We designed this with the end user throughout the product development process; it is tailored to them.
Swedish law requires every sale to run through a certified control unit, with receipts that carry mandated fiscal data in a fixed format—no exceptions. The legal requirement doesn’t care about your interface; it cares that the data is captured, signed, and reportable exactly to spec. The naive way to build that is to make the cashier confront compliance: extra fields, extra confirmations, and the legal machinery visible on screen at the exact moment they’re trying to serve a customer who’s standing there. That’s how most compliant systems feel—like the law is standing between the cashier and the customer. The same thing goes for financial reports from the back office: it’s built for people who know Excel or Google Sheets. It’s far too technical for a store manager.
We refused that. The principle we landed on is simple: these systems should be invisible to the operator and absolute underneath. The cashier should never feel they’re “doing compliance”; they’re selling. The system should handle compliance silently, every single time, with zero opportunity for them to get it wrong.
Resolving it meant moving all the rigidity downward into the architecture so none of it surfaced as friction. The control unit signing, the fiscal formatting, and the reporting structure should be exposed through natural language; all of that happens beneath a well‑crafted system. Compliance is the most rigid part of the system and the least visible. That inversion—hardest requirement, lightest touch—is the whole design philosophy in one decision.
The deeper lesson, and why an AI‑native company can do this where legacy vendors struggle, is that legacy systems expose their internal complexity to the user because their architecture forces them to. We designed the experience first—the cashier’s real moment—and then built the compliance machinery to serve that experience instead of letting it dictate the experience. Design first, compliance engineered downstream. The same principle we apply to everything else we build, applied to the hardest possible constraint.
Staying with trust and brand: after launching Milla Simone as an openly synthetic Customer Success Manager, what did you learn about designing interface cues, voice, and guardrails so an AI persona can earn credibility with B2B customers?
The first decision was the one everyone else gets wrong: disclosure. Milla is labeled as AI on every surface she touches, and that’s not a compliance checkbox; it’s the foundation on which the entire credibility rests. The instinct most companies have is to hide the AI, make it pass as human, because they assume disclosure costs them trust. We built on the opposite belief: that in a market about to flood with AI-slop content pretending to be human, the rarest and most valuable thing you can be is honest about what you are. Disclosure isn’t the risk to credibility but the source of it.
Once that’s the foundation, the design work gets interesting. On voice, the principle we held is that she earns trust by being right, not by being warm. Milla doesn’t oversell, doesn’t manufacture enthusiasm, and doesn’t bluff. She’s a missionary, not a mascot—urgent because she genuinely believes retail is being underserved, but never performing emotion she doesn’t have grounds for. A synthetic voice that tries too hard to feel human triggers exactly the distrust you’re trying to avoid. One that’s direct, grounded, and useful earns a different kind of credibility, the kind you give a sharp colleague.
On guardrails, this is the part I’d tell any B2B builder to take most seriously: an AI persona must never be the final authority on anything that carries real consequences. Milla educates, explains, and points people in the right direction. She does not give binding pricing. She does not improvise on regulation or compliance. She does not close deals. The moment a conversation moves from understanding to commitment, a human takes over. That boundary isn’t a limitation; it’s what makes her trustworthy, because customers can feel the difference between an AI that knows its edges and one that’s pretending to know things it shouldn’t.
The interface cue underneath all of it is honesty about capability. The fastest way to destroy an AI persona’s credibility is to let it act more certain or more authoritative than it has any right to be. The fastest way to build credibility is the reverse: be transparent about what she is, clear about what she knows, and explicit about where a human takes over. Trust in an AI persona isn’t built by making it seem more human; it’s built by making it more honest.
Operationally, as a bootstrapped four‑person team augmented by an AI organization, what single weekly product or design ritual most improved your shipping cadence, and how can another founder replicate it?
The single ritual that changed our cadence is: every week, we start from the operator’s real moment, not from our roadmap. We pick one actual task a user does — the cashier’s moment on the floor, a store owner’s Monday morning — and we walk through it together as a team before we touch code. What does this person actually feel here, where does it break, and what’s the smallest thing that would make it better this week?
It sounds simple, but it isn’t, because it inverts how most teams work. Most teams start from the backlog — what we planned to build. We start from the experience — what the user needs to feel — and let that decide what ships. The roadmap serves the moment, not the other way around.
Why it works for a small team: it eliminates the single biggest waste in product — building the wrong thing well. When four people walk the same real user moment every week, you don’t drift. Everyone is anchored to the same concrete reality, so the design, the build, and the priority all point in the same direction without layers of meetings to align them.
How another founder replicates it:
- Pick one real user task. Not a feature — a task: a specific human in a specific moment.
- Walk it end to end as a team, out loud, every week.
- Ship the smallest improvement to that moment.
- Repeat.
You don’t need process or headcount for this. You need the discipline to start from the person instead of the plan.
Bringing in your choreography background, can you share a concrete moment where timing, rhythm, or staging principles directly improved a specific user flow, and how others can apply that to onboarding?
Choreography is the study of how you move a person through time, and that is exactly what a user flow is. Dance isn’t a list of moves; it’s a sequence with rhythm—where you put effort, where you give release, where you let a moment breathe, and where you accelerate. Get the timing and feeling wrong, and even technically perfect movement feels off. The audience can’t tell you why; they just feel it.
User flows are identical. A flow isn’t a list of screens; it’s a sequence with rhythm. The mistake most products make is treating every step as equal weight, the same density, and the same pace from beginning to end. That’s like choreography with no dynamics: technically complete and completely flat. The user can’t tell you why it feels exhausting; they just feel it and leave.
The principle I carry from dance into product is to control the tempo deliberately. Front-load a small, satisfying win early—the equivalent of a strong opening move—so the user feels momentum before you ask anything hard of them. Then vary the rhythm, group the heavy steps, give light ones space, and never make someone do three demanding things in a row. You’re conducting energy, not just collecting inputs.
For onboarding specifically, that’s the whole game. Most onboarding fails because it’s rhythmically flat, a wall of equal-weight steps. Fix it the way you’d fix a routine that’s losing the room: give them a real win in the first ten seconds, then pace the effort so it never spikes. Onboarding isn’t a form to complete; it’s a sequence to feel. Design the rhythm, not just the steps.
On structure as a competitive edge, describe one feature you out‑shipped a larger competitor on because of your AI‑native org, highlighting the specific tooling and code/design handoff (e.g., Figma, design tokens, JS/CSS) that made it fast and high‑quality.
Haha, I want to answer this honestly rather than claim a competitor scalp I haven’t earned yet! We’re pre-commercial; our first deployment goes live this summer, so I’m not going to point to a specific feature where we beat a larger competitor head-to-head, because that race hasn’t run in market (yet). What I CAN tell you, though, is exactly why the structure makes us fast, which is the REAL question underneath.
The speed doesn’t come from a tool. It comes from removing the distance between a decision and a shipped change. In a large competitor, a feature travels through product managers, design review, an engineering queue, sprint planning, and several layers of sign-off before it reaches a user. The tooling isn’t the bottleneck; the org chart is. Every layer is a delay, and no design system or handoff process removes a delay that’s structural. I’ve seen this through decades of consultancy experience among big and large corporations.
Our handoff is short because the company is short. The person who understands the user’s problem, the person designing the solution, and the person shipping it are working in a tight loop, often the same conversation, augmented by AI that handles the execution depth a small team couldn’t otherwise reach. There’s no translation loss between “here’s the problem” and “here’s the deployed fix,” because there are almost no people for the intent to pass through and degrade.
So the honest version of the competitive edge isn’t a specific feature or a specific tool. It’s that we compressed the distance from insight to deployment to almost nothing, and that compression is structural, not procedural. A larger competitor can buy the same design tools and the same AI. They can’t buy the short org chart without firing most of their org. That’s the part they can’t copy, and it’s why a four-person team can out-ship a far larger one. After this summer I’ll have specific in-market examples. Right now I can tell you the mechanism, and the mechanism is the secret sauce.
On product taste, before launch what signal or metric most reliably tells you a UX is ready, and how did you arrive at that bar through experience?
The signal I trust isn’t a metric but rather a feeling I learned to recognize long before I built products: the moment the craft disappears.
When UX is ready, the person using it stops noticing it. That’s literally what great design is. They’re not thinking about the interface; they’re just doing the thing they came to do. When it’s not ready, you can see them notice the tool, hesitate, look for the button, and wonder what happens next. That hesitation is the tell. Great UX produces a kind of silence: the user moves through it without friction or comment because nothing pulls their attention away from their actual task.
I arrived at that bar through dance and music, where the same rule governs everything. A move isn’t ready when it’s technically correct; it’s ready when it reads as effortless to someone watching. A mix isn’t done when every level is right on paper; it’s done when the listener feels the song and never notices the engineering. In both, the finish line is the same: the work becomes invisible and only the experience remains. That’s the bar I carry into product. Technically complete is not the bar. Invisible is the bar.
Practically, that means I watch people, not dashboards, before launch. I put the real flow in front of a real person, and I don’t ask if they like it. I watch where they hesitate. Every hesitation is a place where the craft hasn’t disappeared yet. When the hesitations are gone—when they move through it without thinking—it’s ready. The dashboard tells you what happened after launch. The hesitation tells you whether you’re ready to launch at all.
Looking ahead to your 2026 rollout, what bold UI simplification are you planning that most teams would avoid, and what evidence gives you the confidence to ship it?
Honestly, the bold bet isn’t a UI simplification. It’s everything underneath that nobody sees.
The interface is the easy part. The hard, bold thing most teams avoid is simplifying the structure beneath it: the system, the architecture, the organization, the rollout itself. That’s where the real complexity lives, and where almost everyone is afraid to cut.
Most companies add layers to feel safe—more process, more people, more steps in the rollout. We’re doing the opposite. We’re keeping the structure radically simple on purpose: a small team, a short org, a clean architecture, a deliberate rollout—and letting that simplicity show up as a product that just works.
Our confidence doesn’t come from a single metric. It comes from knowing that simplicity underneath produces simplicity on the surface. You can’t ship a clean experience on top of a tangled company. The UI is only ever as simple as the system and the organization behind it. So the bold move isn’t on the screen—it’s everything beneath it.
Thanks for sharing your knowledge and expertise. Is there anything else you’d like to add?
Just one thing. None of what we’ve talked about—the design, the speed, the structure—works because of a tool or a tactic. It works because of how the company is built underneath it all.
That’s the part I’d want people to take away. In this era, everyone has access to the same AI, the same tools, the same tactics. The difference isn’t what you can build. It’s the shape of the company doing the building. Specialists build features. Polymaths build companies. And small, free, AI-native teams are about to out-build organizations many times their size, not by working harder, but by being structured for the moment we’re actually in.
That’s what we’re really building at Wired to Create. Not just products, but proof of a different way to build them.