Simeon La Barrie
Founder and CEO
A founder who patented live-presence commerce before the category had a name — and then waited, because you cannot force timing.
Simeon La Barrie is the founder and CEO behind a technology platform built around what he calls “I Am There”: live video, real-time interaction and transaction combined in a single system, so that someone can be present in a physical store without being there. Core development and IP are held in-house, with patents secured across multiple regions.
He is candid that the platform is still in deployment cycles rather than at mass scale, and that pricing has not yet standardised. The more interesting thread is his account of building something before a market existed for it — and what that cost in adoption speed.
The Platform and the Model
How would you describe your company and your role as a founder and CEO?
I’m the founder and CEO behind a technology platform built around what I call “I Am There.” The idea is simple. Let someone be present in a physical store without being there. Live video, real-time interaction, and the ability to transact in one system. I lead the direction of the product, the partnerships, and the rollout. My role is not just strategy. I stay close to how the system actually works.
What is your operating model for building and delivering this technology?
It’s a hybrid model. Core development and IP stay controlled. That’s important because we’ve secured patents across multiple regions. Around that, I work with small, focused teams depending on the stage. I don’t scale teams early. I scale only when the system proves itself. That keeps the build disciplined.
How is your approach different from other commerce or video platforms?
Most platforms separate experience from transaction. Video sits in one place. Commerce sits in another. I combine them. The goal is not just to show a product. It’s to recreate presence. When someone logs in, they are not browsing. They are interacting in real time. That shift changes how people engage and how businesses sell.
Who It Is Built For
Who do you primarily build for, and how has that focus changed?
The core user is any business that benefits from human interaction during a sale. Retail is the obvious entry point. But it extends to services, showrooms, and even remote consultations. Early on, the focus was broad. Now it’s tighter. I look for use cases where presence directly impacts conversion.
What problems do people come to you to solve?
Distance and friction. Businesses lose sales when customers cannot experience something properly. Static images and delayed responses don’t solve that. They want immediacy. They want interaction. That’s what I build toward.
Signals and Staying Current
How do you stay ahead when technology moves quickly?
I don’t chase trends. I focus on what doesn’t change. People still want trust and clarity before they buy. The tools evolve, but the behavior doesn’t. I built this concept before the language around AI and live commerce became common. I stayed with it because the logic made sense.
Do you see repeat engagement from users or partners?
At this stage, engagement is tied to testing and deployment cycles. I’m not operating a mass platform yet. Repeat usage comes from partners who see the value in real interaction. Retention will matter more as the rollout expands.
How do you measure whether the system is working?
Engagement and completion. Are people staying in the session? Are they interacting? Are they completing transactions? Those are the signals. If someone logs in and leaves quickly, something is broken in the experience.
Deployment and Fit
What happens after a business starts using your system?
Support is direct. I stay involved. Early-stage technology needs feedback loops. I want to see how people use it, where they struggle, and what needs to change. That’s how the system improves.
How do you structure pricing at this stage?
It depends on the use case. There isn’t one fixed model yet. Some deployments are structured around access and usage. Others are tied to integration. The model will standardize over time, but right now flexibility is part of the process.
What determines whether a project is the right fit?
Clarity of use. If a business cannot define how live interaction improves their outcome, it’s not a fit. I don’t build for abstract ideas. There has to be a clear path from interaction to value.
Timing, Innovation and Culture
What challenges have shaped how you operate today?
Building something before the market is ready is the main one. Early on, there was no clear category for what I was doing. That meant slower adoption and more explanation. It also meant staying patient. You can’t force timing.
How do you approach innovation in your work?
I build from first principles. What should the experience feel like? Then I work backward. Innovation is not adding features. It’s removing friction. If something feels complicated, it’s wrong.
What does culture look like in a small, focused operation like yours?
It’s built around accountability. Small teams don’t have space for confusion. Everyone involved needs to understand the goal and how their work connects to it. That keeps things efficient.
Where It Goes
Where do you see this platform going over the next decade?
Toward integration. I see this becoming part of how people interact with businesses across multiple sectors. Not a separate tool, but something embedded into how transactions happen.
How has your leadership approach changed over time?
Earlier, I tried to do everything myself. Now I focus on where I add the most value. Direction, product clarity, and decisions around timing. Everything else gets structured around that.
What technologies or shifts are you paying attention to now?
Real-time interaction at scale. Not just faster systems, but systems that feel natural to use. The closer technology gets to human interaction, the more effective it becomes.
What would you tell someone building something new today?
Act before it’s obvious. If you wait for validation, you’re late. But also be prepared to stay with the idea longer than expected. Timing is rarely perfect.
Key Learnings
- Core development and IP are kept in-house, with patents secured across multiple regions; teams are kept small and scaled only once the system proves itself.
- The differentiator claimed is combining video and transaction in one system rather than treating experience and commerce as separate layers.
- Target use cases have narrowed from broad retail to situations where presence measurably affects conversion.
- Success signals are session retention, interaction, and completed transactions — a quick exit is read as a broken experience.
- Pricing is deliberately unstandardised at this stage, structured around access, usage or integration depending on deployment.
- His stated cost of building early: no established category, slower adoption, and more explaining.
What Live Commerce Actually Changes
Live commerce merges a real-time video session with the ability to transact inside it. The distinction from conventional e-commerce is not the presence of video — product videos have existed for years — but that the video is two-way and synchronous, and the purchase happens without leaving it. The customer can ask a question about an item and get an answer in the same moment they are looking at it.
The commercial logic rests on a gap that static listings cannot close. A photograph and a specification answer the questions a retailer anticipated. They cannot answer the unanticipated one, and for considered purchases — furniture, vehicles, specialist equipment, professional services — the unanticipated question is often what decides the sale. Physical showrooms resolve it by putting a knowledgeable person in the room. Live commerce attempts the same thing without the room.
The model is well established in parts of Asia, where livestream selling accounts for a substantial share of online retail, and considerably less mature in Western markets, where it has tended to arrive as a marketing format rather than a sales channel. The practical constraint is rarely the technology. It is staffing: a synchronous channel requires someone available to be synchronous with, which is why the use cases that work best are those with high enough order value to justify a person’s time.