In September 2025, I sat down at a desk in Vancouver, opened a terminal, and started building ioZen. No dev team. No co-founder writing code beside me. No Slack channels with dozens of engineers debating architecture decisions.
Just me, a clear vision, and AI.
Four months later, we’re launching the beta of a platform that replaces bureaucratic forms with intelligent conversations. It has AI-powered intake flows, visual workflow boards, a CRM, marketing attribution, embeddable widgets, and a document extraction engine.
A well-funded startup with a full engineering team would have taken 12 to 18 months to ship this scope.
I’m still processing what happened. I want to tell you the real story.
The road to Vancouver
I need to go back to explain how I got here.
For over 20 years, I built technology companies in Latin America. I founded PATIOTuerca (Ecuador’s largest automotive marketplace) and co-founded Vive1 (real estate), Evaluar.com (leading HR tech serving millions of users), and Taxo (tax technology for Mexico and Ecuador). I led engineering organizations across Mexico, Argentina, Perú, Ecuador, and beyond. Across all of these ventures, I managed teams of dozens of developers building complex, high-stakes systems.
I know what it takes to ship software at scale. I’ve lived through waterfall-to-agile transitions, microservices migrations, monolith rewrites, cloud infrastructure debates. Every flavor of technical debt you can imagine. I’ve recruited senior devs, built hiring pipelines, run sprint ceremonies, negotiated with vendors. I’ve done architecture reviews at 2 AM before critical launches.
That world was my entire identity for two decades.
Speaking at BBVA Open Innovation. The world I knew for 20 years.
Presenting at AWS Cloud Experience: 5X faster deployments, 60% productivity gains. Cloud architecture experience.
Some of the engineering teams I led across Latin America. These people taught me everything I know about building software at scale. In our startups, we called them “Magos” (Wizards might be the best translation in this context).”
Then, in early 2025, I made a decision that changed everything.
I stepped away from Taxo. My wife and I moved to Vancouver, Canada. It was a new beginning in every sense: new country, new language (English isn’t my native tongue), new environment, new financial reality. I left behind the comfort zone of my network in Ecuador, the teams I had built, the companies that defined me.
I arrived in Vancouver with a clear mind and an empty calendar.
The uncomfortable truth about starting over
I won’t deny it. Those first months in Vancouver were hard.
I had income from advisory roles and board seats, but nothing like what I earned before. I was in a city where nobody knew my track record. I didn’t have the grounding of my professional network, the daily rhythm of managing teams, the identity that comes from being “the hardcore tech nerd” in the room.
What I did have was time. And an idea that had been growing in my head for years.
Vancouver, 2025. New city, new beginning.
Throughout my career, I watched the same pattern destroy value everywhere: bureaucracy. Every organization I touched was drowning in forms, approvals, paperwork, and process overhead. The tools designed to fix this (form builders, workflow engines, CRM systems) create their own bureaucracy. They make the problem prettier, not smaller.
I kept thinking: what if we could kill the forms entirely? What if instead of building another form, you could have a conversation that gets the right information, then routes it, processes it, and delivers an outcome automatically?
That was the seed idea for ioZen.
The name came to me one evening while walking the seawall in West Vancouver. Traditional systems follow a simple pattern: input, process, output. I wanted something different.
Intelligent intake instead of input. Because we’re not just receiving data passively. We’re having a conversation. Asking follow-up questions. Understanding context.
Intelligent processing instead of mechanical routing. The system should think, not just shuffle papers or cards.
And outcomes instead of output. Because nobody cares about data dumps. What matters is the result: the approval, the resolution, the answer delivered. Output is not the same as outcome.
When intake, intelligence, and outcomes work in harmony, everything becomes calm. Clear. You stop fighting the system and start trusting it. That state of Flow, that peace of mind when everything just works… that’s Zen.
io + Zen. ioZen.
The experiment
Here I want to be brutally honest. I didn’t plan to build ioZen alone.
The original plan was to find a technical co-founder. Maybe hire a small team. Raise a pre-seed round. Do it the way I’d always done it: architect the system, recruit the talent, manage the execution.
But something happened while that plan was materializing. I started prototyping with AI coding tools. Not because I believed I could build the whole thing, but because I’m an engineer at heart, and I wanted to validate my ideas fast.
I’ve been coding since I was a teenager. In 1996, at 16, I sold my first website. Uglier than sin (we have a saying in my country about demons that I’ll spare you), but someone paid for it. Over the years, as I moved into leadership, I coded less and managed more. But the mental models and the logic of building software never left, they sharpened. System design, data architecture, API patterns, cloud infrastructure, security considerations, code patterns. All of that was still there, accumulating over 20 years of shipping real products, but far from the syntax and the thrill of coding.
So I started. Cursor open. Claude in another window. A blank Git repository.
And something unexpected happened.
The AI didn’t just autocomplete my code. It became a real right hand. I could describe an architectural pattern I wanted, say a queue-based workflow engine with state transitions, and the AI understood what I meant. Not because it had opinions about architecture. But because I had opinions, and it could execute on them at a speed no junior or mid-level developer could match. It even surprised me by making brilliant decisions or challenging assumptions in ways I had only experienced with my best wizards.
This wasn’t about AI replacing developers. It was about AI amplifying someone who already knew what to build and how to build it.
What experience actually means in the age of AI
This is the part nobody talks about when they say “AI will replace developers.”
AI is incredible at generating code. It’s fast, tireless, and gets better every month. But code is not the same as software. Software is decisions. Architecture decisions. Data model decisions. Security decisions. UX decisions. Hard trade-off decisions that come from building things that broke, from scaling systems that buckled, from shipping products that users rejected or never used.
When I sat down to build ioZen, I wasn’t starting from zero. I was starting from twenty years of hardships, failed products, and successful releases accumulated.
I knew why I wanted a particular database schema because I had lived through what a bad database design does at scale. I knew which authentication patterns to use because I’d had to deal with the mess of getting them wrong. I knew how to structure a monorepo, how to design an API that could evolve gracefully, how to implement role-based access control that wouldn’t become a maintenance nightmare.
The AI gave me speed. My experience gave the AI direction.
Without the experience, the AI would have generated functional but fragile code. Without the AI, my experience would have produced maybe the same code in 10 or 100 times the time, and I would have needed a whole team.
Together? Something new happened.
Four months, one person
Let me be more specific about what we built between September 2025 and January 2026.
We built IntakeBots: conversational AI agents that replace forms. They ask follow-up questions, handle branching logic, extract data from documents, and adapt based on previous answers. Forms that think.
We built Process Boards: visual workflow management inspired by Kanban, purpose-built for intake-driven processes. Stages, assignments, automations, status tracking. All connected to the intake data.
We built a Contact Records system and lightweight CRM that auto-populates from intake conversations. Every interaction, document, and status change is captured and searchable.
We built AI Field Intelligence: AI to classify, extract, summarize, and validate incoming data. Not bolted-on AI. Native intelligence in data fields.
We built Embeddable Widgets so you can deploy any IntakeBot as a chatbot widget on any website or as a direct link. Custom branding, zero-friction integration.
We built Marketing Attribution to track which campaigns, sources, and referrers drive conversions, with built-in UTM tracking and soon AI-powered analytics dashboards.
We built Multi-workspace Architecture with full multi-tenancy, team management, role-based access, and workspace isolation.
We built Developer Tools: webhooks, embed codes, API access, and complete documentation.
We built a First-class Marketing Website: high SEO performance, refined design, modern animations.
One person. Four months. A complete product-led SaaS platform with Stripe integration and a marketing website. And as if that wasn’t enough, 100% functional in English and Spanish.
I’m not listing this to boast. If you told me two years ago that a single founder could ship this scope in this timeline, I would not have believed you. And I was the person who was supposed to know what’s possible.
What AI development actually looks like
People hear “I built it with AI” and imagine someone typing prompts into ChatGPT and pasting code into an IDE or something. This turns out to be more than that.
AI engineering is a new discipline. It has its own patterns, its own problems, its own art.
Here’s what my days actually looked like:
Architecture sessions. I’d spend time thinking about system design: on paper, in my head, walking around Vancouver. The AI didn’t help here. This was pure experience and neurons. What should the data model look like? Where do we need real-time updates vs. batch processing? How do we handle concurrent workflow state changes?
Implementation sprints. Once I had a clear architectural vision, the AI became my execution engine. I could describe what I needed (a specific component, an API endpoint, a database migration) and iterate rapidly. What would take a developer a week, I could review, refine, and ship in hours.
Code review of my own AI-generated code. This is critical and underrated. AI generates code that works. It doesn’t always generate code that’s right. I spent significant time reading, questioning, and restructuring what the AI produced. My experience has been most valuable here: recognizing patterns that would cause problems at scale, catching security oversights, ensuring consistency across the codebase, validating test coverage (this is key), automatic hooks before commits, ensuring good CI/CD with quality gates.
Debugging sessions. AI is great at writing code. It’s less great at understanding why something doesn’t work in a specific context. Debugging complex interactions between services, tracing state management bugs, understanding why a particular edge case behaves unexpectedly, iterating until it’s right. That required human judgment.
Whole days of refactoring. Something I learned over the years: it’s unlikely you’ll build a quality product without several refactors along the way. No matter how well-conceived your architecture or how good your code. Technical debt is the biggest poison to software quality. For the first time in my life, I gave myself the luxury of doing deep refactors before going to production. I’m not exaggerating, I must have done a dozen deep refactors of what I built over these months. Unthinkable in my past life, because doing a refactor at this level in production can take weeks or months.
The ratio was roughly: 30% thinking, 20% directing the AI, 25% reviewing and testing, 15% debugging, 10% manual coding for the tricky parts. And some days, 100% refactoring with the same AI and test coverage.
It’s not just dictating prompts and done. It’s a new way of building that requires a different kind of discipline and determination.
Gratitude
I want to pause the technical narrative and say thank you.
To God, for putting me exactly where I needed to be, even when I couldn’t see why.
My wife. She dismantled her life in Ecuador to come to Vancouver with me. She believed in this vision before there was a product, before there was a company, before there was anything but an idea and a conviction.
My three children. My daughter here with me in Vancouver, my other daughter and my son still in Ecuador. That distance is the price of starting over. It’s also the reason I wake up early and work late.
My brothers and sisters here, blood and chosen, who moved to Vancouver before me and showed me that reinvention is possible. My parents, who built their business here from nothing, proving that starting over in a new country is in my blood.
And the people who shaped me professionally over the past 20 years. My partners, my colleagues, the teams I built and worked with across Latin America taught me about technical craftsmanship, about what good engineering looks like from the inside. Some of my wizards called it poetry in code. 😆
A long way from Ecuador. Exactly where I needed to be.
Vancouver deserves credit. This beautiful city gave me something I didn’t know I needed: distance. Distance from my comfort zone. Distance from the identity I had built around managing teams and running companies. That distance forced me to rediscover what I actually know, what I can actually do. Not through other people, but through my own hands and mind.
Why this matters beyond my story
I’m not writing this as a humble-brag about what one founder can do. I’m writing it because I think we’re at a turning point that most people haven’t fully processed.
For decades, the limiting factor for software startups was engineering talent. You needed a team. You needed funding to pay that team. You needed months or years of runway to build something meaningful. This created a natural barrier to entry that favored well-funded companies in major tech hubs.
That barrier is collapsing.
A single person with years of building experience and AI fluency can now build what used to require a team of 10 or 20. Not a toy project. Not an MVP held together with tape. A real, production-grade platform.
This doesn’t mean developers are going away. Far from it. As ioZen grows, I will build a talented team. There are challenges that require multiple minds, diverse perspectives, and specialized expertise. AI amplifies capability. It doesn’t replace the need for humans to collaborate, debate, and create together.
But the starting conditions have changed forever. The solo founder with experience and vision is now a viable technical team. The barrier to entry for building ambitious software has dropped by an order of magnitude.
If you’re an experienced professional who has been on the sidelines of the AI revolution, thinking it’s for “real developers” or “younger people,” you’re wrong. Your experience is the most valuable input an AI can receive. The architecture patterns you learned the hard way, the production failures you survived, the systems you built and maintained for years. That knowledge, combined with AI, is powerful.
What’s next
ioZen is live. The platform is real. The mission is real.
We’re going after bureaucracy. Starting with the forms that waste everyone’s time and ending with the processes that keep organizations stuck.
Kill the forms. Hide the process. Deliver the outcome.
If you’ve ever filled out a 47-field form and wondered “why does this exist,” you understand the problem. If you’ve ever built a workflow that created more overhead than it eliminated, you understand it deeply.
We’re building something different. A platform where AI conversations replace rigid forms. Where workflows run invisibly in the background. Where the outcome (approved, issued, scheduled, resolved) is what matters.
Four months ago, this was an idea in a Vancouver apartment. Now it’s a product.
Come see what one person with experience and AI can build.
Tags:
