What It Takes to Build With AI for Other People

Lightly edited for clarity. Solo episode: Ysi Gonzalez, Vantelira.

This episode is powered by Vantelira. We go inside a scaling operation, fix the process, and build the system that keeps it running.

Hello and welcome to The Forward Deployed Operator. I am so excited about this solo episode — I think it's the third one we've done, and it's episode 9.

If you haven't been here on the show before, this is a great moment to pause and go back to the first episode, where we explain what a forward deployed operator is. You'll get a little bit of what we're doing behind the scenes at Vantelira, what I do for my customers, and the passion I have about data governance, improving processes, and applying AI where it can be applied.

Catching up: episode 7, and finding another operator in the wild

These past two episodes we've been talking with amazing guests. On episode 7 we had Rafael Angarita, and it was an exciting conversation. I was looking for another forward deployed operator, and I found him in the wild. How exciting is that?

It was like — I sent one of my AI agents to do some research, and it came back with an article he had written a couple of weeks before I did that research, and I was able to get in touch with him.

He's the marketing architect, as he called himself, inside SERHANT., the real estate agency based out of New York City, Manhattan. If you haven't seen Owning Manhattan, it's on Netflix, and it's all about that — so you can go and watch and see what SERHANT. is about if you don't know them by now.

I feel very lucky and privileged to have been able to sit down with him and speak about what he has been doing behind the scenes for them. It's a real estate agency, but it's really marketing-based, so there's a lot of marketing that has to be done — and he was able to build automations and agents, and it became a platform. He explains everything on episode 7. Go and watch it. Pause here, go watch that, and then come back to this episode.

Catching up: episode 8, the AI guru and personal barista

Then on episode 8 there was another very special guest coming to the show. I had a conversation with my husband — Doneyli De Jesus, working at ClickHouse as a solutions architect for AI. I keep telling him: don't keep changing your job title, because I can't keep up with it.

For me he's the AI guru. He's my go-to person whenever I have questions about AI, and also my personal barista. You can hear everything about the hackathon date we had last year, where I ended up winning with the development of the software I needed at that moment, through vibe coding. That's another great episode to listen to.

What it actually takes to build with AI

Today I want to talk about a little bit of what it takes to actually build with AI.

A lot of people out there ask me questions. Is AI going to take my job? Is AI going to be taking over the world anytime soon? I personally don't think so, because it is not as easy as they make it look in the news. And I want to break that down today.

So: what it really takes to build with AI. For you, for an individual, for your own business — if you're a small business developing solutions that are only for yourself, for your personal use — it's a totally different ballgame from developing things for an enterprise-level customer, or even for another small business where there are going to be multiple users behind it.

That is the distinction I want everybody to understand.

Building for yourself: you are the only user

When you are developing a workflow, or developing a solution for you — your own personal finances, for example — or you're developing your own CRM because the CRMs out there are either too expensive or they don't have exactly what you need, that's one thing.

You can use it on your accounts, on your computer. You can run it locally. You have control. Oh, I want to change this: you go in, you make the changes, you deploy them right away, because you're the only one using it.

The questions you have to answer before other people log in

Now, when you develop a tool and then you put it in the hands of other users, this is when things can get a little bit sideways, because there are a lot of aspects you have to keep in mind.

You have to know the number of users who are going to be in the tool, and the time they're going to be spending in it, so you can forecast — or at least estimate — what the actual spend is going to be for that tool on a day-to-day basis.

Where is the tool going to be hosted? Is it going to be locally on somebody's computer? How is everybody else going to connect to it? You probably need a cloud-based infrastructure architecture, which is again where I call in my developers. That's the part where I'm like: yeah, I made it. I vibe coded the thing to work for me. Now I need you to go make it work for everybody else.

Where the operator stops and the engineer starts

That's where the developers come in. And this is why I've been very adamant about making the distinction: where is the line between a forward deployed operator and a forward deployed engineer?

These engineers are the people who studied it, the people who have the experience, and they know how to make that system work for everyone. We, as forward deployed operators, understand what they do — we don't necessarily do that job. We understand what the business needs. So this is where we can communicate properly with each other.

Who maintains it, and who tells the users it's going down

Going back to the point of building for other people's use: when you're building a tool, imagine you want to launch this product. For example, in the case of Rafael — he built a platform for marketing management, and it's amazing. Now, if he wants other people to use it on a subscription basis, or he wants to sell it as software, or he wants to implement it across SERHANT., the organization he works for, there are things that have to be taken into account.

For example: what platform is going to support that tool? Who's going to maintain the thing afterwards if something breaks? That becomes almost a full-time job, depending on the number of users you have.

You also have to keep in mind what happens when a change needs to be implemented — when there's a request from one user who wants to change something, even if it's in the UI, the front-facing part of how the tool looks. You have to think: oh wait, I need to figure out what time everybody is out of the tool, or let everybody know, please be out of the tool by this time.

You know this if you've worked in corporate before, or if you've used one of the government sites: they always put a popup at the top saying there's going to be maintenance between this time and that time. That is exactly what's happening. Those are things you have to figure out as the sole developer of the tool, or hand off to the team that is going to work on it.

Why AI isn't taking these jobs yet

Which is the distinction — and this is why I personally think that AI is not ready to take over our jobs, because there are a lot of steps that have to happen before that.

Once you build a tool — and let's say an agent can build a tool for you — then, to hand it off to whoever is going to maintain it, you have to create other agents, and somebody has to manage those agents anyway, and they have to be properly created. Which is the part where, to me, the software developers out there will have a job. They should be, and they are, in higher demand, because they have to be fixing the mistakes and also taking care of what happens when you have to deploy this at scale.

The tool I won a hackathon with

So, I had an example. There was a tool that I vibe coded — the tool I won the hackathon with. I ended up spending a couple of months on it. It was my first full-on tool build: there was coding, there was a database connected, there were different tables, there was a UI, I wanted users to be able to connect to it with a password, all of these things.

Back then the models were not as developed as they are today, because as you all know, this is a race. Every week there's something new coming out. Every month or so Anthropic comes out with a new and improved model. It could be that it's not as good as the previous one, but there's always evolution.

So a year ago — actually, more than a year ago already — the models were not as developed. I spent a couple of weeks, long weeks, days and nights, working on my operational hub, which is what I called that tool. I developed it for a specific customer that had specific needs at that moment.

Why custom-built beat a $30,000 implementation

The reason I went with a custom-built tool for them was that customization. They were coming from managing different platforms where they got the intake of their data, and instead of just migrating them to a $20,000 or $30,000 implementation tool — and then the maintenance fee and everything that came with it — they were at a pivotal point in their processes.

Again, this is the reason I look at processes first. They were at a pivotal moment in their process where I had to define: okay, is this going to be the final end game for them? Is it worth it to invest the $30,000 right now, to then go back and change it next year? No. So that was a decision I had to make, to make a custom tool.

I also had the opportunity to build something with Zapier, an automation with Zapier, or an Excel sheet. I'm very versed, I would say, in developing semi-automated reporting tools, forecasting analysis, and inventory management within Excel files. But again, it needs an expert in Excel to be able to manage that — and if it breaks, then an expert in Excel has to go back in.

I build things so I can walk out the next day

Part of my whole philosophy is that I build things so I can walk out the next day and have somebody else taking care of them. Not necessarily me. If you want to keep me, fine — but you can have somebody from your team, less technical, less qualified so to speak, handle that operation.

The change I pushed while someone was still using it

So, back to the story. I developed the operational hub — OpsHub for short — and I deployed it with the customer. They knew it was a testing ground. It was the first tool I officially put out there for others; I had developed a couple of tools by then already, for personal use.

I put it in their hands, and a couple of weeks went by. I started getting requests. Oh, can you add this? Can you add that? And one day I completely forgot that there were other people working in it, and I went ahead and implemented the change.

Somebody was entering information at that moment, and they called me immediately. They were like: Ysi, I can't find the order I was just entering.

And I was like — oh, oh my god. I completely forgot to let them know I was implementing that change they requested, the one I was able to put together really quick and fast with my Claude at that moment. I completely forgot. I was in the zone, you know, vibe coding the thing.

I saw the results in the UAT environment. So I was like, let me just push it. Let me just put it to production. This is ready, let's go. And lo and behold — yeah, that was not the right thing to do.

Those are the kind of lessons you learn, and that the software developers know for a fact. Before they go to production, they make sure there are no users in it, and that it is at a time when they can take the time to course-correct — because that also happens. What if it performed one way in UAT, but then when it goes to production something else happens? It can happen, and then you have to pull the change back, or fix it. So they make sure there is a window for this.

UAT: what it is and why you ship inside a window

I mentioned the UAT environment. This is user acceptance testing, and it is used to test the changes you're implementing.

Normally, when you're vibe coding an app — let's say through Lovable or Replit — you do have a development environment, and this is where you make your changes, and then you test it, and then you publish the app. It's kind of the same thing when you're doing software development outside of a tool like this. When you're using Claude or Codex, or if you're actually writing the lines of code — which I don't think anybody is doing these days, or at least I would hope so, because it's time-consuming and there are many, many AI models capable of doing that.

So once you do your coding and your changes and your development portion, then you have to put it somewhere to test it before it goes to production.

Changes that quietly touch the database

Other things I've learned through this path: building with AI is not for the faint of heart. There are changes that may create new tables in the database, and that will create more storage space, or it will change the behavior of the app.

So make sure you always have your development team taking care of that last portion. It's a marriage — and we explained it in episode 8 — the perfect marriage between the forward deployed operator and the FDE, because they know what the impact is going to be on the technical side.

Different mission, same operational pattern

Through all of this, after we developed OpsHub, I was given the opportunity to develop another app for a nonprofit here out of Montreal, and it's been a great experience. I actually wrote a full article about it in the newsletter, The Forward Deployed Operator. You can go and search it on Substack — subscribe in the meantime, because me and the team try to send updates and tell stories about what happens behind the scenes when dealing with operations.

Every system you fixed became someone else's win. The next one has your name on it. An eight-week live cohort. You solve a real problem inside a real company, ship a working AI system, and leave with the case study, the build and the title: Forward Deployed Operator. Join the waitlist at fdoschool.com. That is fdoschool.com.

LiliBloom makes personalized wooden and acrylic keepsakes out of Montreal. It is my choice for any keepsakes that I want to give to my friends, my family, my customers. First birthday photo boards, cake toppers, first day of school signs, anything in between and anything you need. Every piece is thoughtfully designed and crafted with love, care, and an eye for detail, making your celebrations and your gifts even more special. Find them on Etsy as LiliBloomShop. That's L-I-L-I-B-L-O-O-M-S-H-O-P. LiliBloomShop.

This operation was a little bit different from what I was used to. It managed a different type of inventory, not necessarily physical inventory. Nonetheless, it's the same operational pattern, right? There is a need. There are inputs that come through. There is handoff of data. There is data that needs to be unified — so, governed: establish the terms that everybody is going to be using, or find out what everybody is using already.

The article is called "Different Mission, Same Operational Pattern," and it was a special edition describing the infrastructure underneath building software.

The delivery life cycle is changing hands — and should get faster

The last point I want to touch on today is that building with AI is changing the world, and it's changing even how software developers are thinking about things now.

I consider myself to be on the front lines of what's happening at the enterprise level with AI — not the model developers. The Anthropics and OpenAIs of the world are out there up on the curve. I'm a little bit below, I would say, or at a starting point, where I get to play with AI for actual operational improvement and process improvement.

And the way we're looking at it right now: so far, the delivery life cycles are changing, are expected to change. How do we make sure that things are not just changing hands and keeping the same timeline as it used to be, but accelerating the timeline by changing hands? And when I say changing hands, I mean that instead of a human necessarily writing the code, an agent writes it and then the human supervises it, so things can be accelerated as much as possible.

Why I still write my processes by hand

Thank you so much for listening to my little rant about building with AI. I am very blessed that I get the opportunity to develop and improve processes. I still do look at my processes written by hand, so I know exactly where AI needs to be implemented.

And this is what I teach to my students through FDO School. If you haven't heard of it, go to fdoschool.com. There's probably a commercial that our editor is going to put in between here, so go look at it. This is exactly what we teach to the fellows going through the school.

Once you have the experience, and you've seen the process many, many times — manually being done, manually analyzed, manually developed and used and implemented — having that experience and being able to plug AI where you think, oh, this could be an agentic kind of solution, this could be automated through a specific deterministic workflow: it's beautiful. At least I find it that way. I'm very passionate about it, and as I mentioned before, I hope you see it through these little talks.

Thank you so much for joining me on The Forward Deployed Operator. We're going to have a blast. There are a lot more episodes to come, and I'm very excited that this is already episode 9. I think I read in an article earlier this year that a minimum of 10 episodes have to be done for a podcast to be successful, so I feel like we're almost there.

Go ahead and listen to the rest of the episodes, subscribe to the podcast, subscribe to the newsletter, and follow us on LinkedIn and Instagram too.

The Forward Deployed Operator — I think it's the new way of doing things: having all of your experience in a specific market, in a specific process, in an industry, and then bringing AI to it. How do you bring it? This is all we talk about in this podcast.

Thank you so much for tuning in. We'll see you next time on The Forward Deployed Operator.

That's it for this one. Follow the show so the next episode finds you. And the newsletter goes out every Tuesday — the link is below. See you next time on The Forward Deployed Operator.