I’ve been around teams building software products before AI was something you’d put on a pitch deck. Igor Malchenko has been building them for longer.
He’s the VP of Product at Altar.io, and has shipped somewhere in the range of a hundred products across B2B, B2C, enterprise, and early-stage startups.
Roughly seventy percent of the founders he works with today are non-technical, and that number has been climbing steadily since 2023. I sat down with him for an hour to ask a question I get in almost every call I take in this industry: what can a non-technical founder actually do with AI in 2026, and where does it break?
His answers surprised me in places. In others, they confirmed things I’d been thinking about or heard somewhere else. What follows is that conversation, lightly edited for length and clarity. Where Igor referenced specific projects or numbers, those are real, anonymised only where people asked us to.
Let’s start with what a lot of the AI content out there gets wrong.
The most common misconception about AI in product building
Rui: Igor, when I brief people on what you do, one of the first things I say is that you think about AI differently from most product people I know. Give me your one-sentence version.
Igor: AI is not for building apps. It isn’t. Or at least, that’s not where its highest leverage sits for a non-technical founder in 2026. Everyone is talking about Claude Code, Cursor, Lovable, Bolt, Replit Agent. These tools let you generate a working application from natural language. And they’re real; they do work. But they’ve completely dominated the conversation, which means the far more useful application of AI for a first-time founder is the one nobody talks about: validation.
Rui: Explain what you mean by validation, because I think this is where most of the value is and it’s the least sexy story.
Igor: Sure. When you launch something completely new, you need to validate the market. How do you usually validate the market? You run interviews, you ask people questions, you look for signal. Traditionally there was a real gap between a problem interview, where you’re exploring whether the pain even exists, and a solution interview, where you’re testing whether your specific answer to the pain lands. That gap used to require weeks of design work in the middle. Now, if you can build a small interactive prototype, and it doesn’t have to be functional (it can be effectively a fake), you compress that gap dramatically. You can show a customer how the thing works, even if nothing behind the interface is real, and get feedback that used to require a real build to unlock.
That’s what AI has changed for founders. Not “you can now build production software without engineers”. That’s mostly a lie, and we’ll get to it. What’s changed is that you can now validate an idea with the visual richness of a real product, months earlier than before.
Rui: Agreed. That’s a much better use of the tools than what most VC newsletters are running with right now.
The tool stack for a serious non-technical founder in 2026
Rui: Someone in your family finishes college and wants to build a product. Non-technical. What’s the actual stack you’d tell them to use?
Igor: The simpler the better. One of the lies we’re being sold in 2026 is that you need the most sophisticated tool for every job. You don’t. Remember prompt engineering? It was the most-wanted job in the world for about two months. Now it doesn’t exist. The same thing will happen with half the tools founders are being told they need this year.
My honest recommendation for a first-time non-technical founder is this. Any frontier LLM does eighty percent of the work you actually need. Anthropic’s Claude, OpenAI’s ChatGPT, Google’s Gemini, any of them. It doesn’t materially matter which one for validation-stage work. You use it for research, for thinking, for pressure-testing your assumptions.
The other twenty percent is prototyping. You pick any prototype-generation tool that lets you see the thing you’re imagining. Lovable, Bolt, v0, Replit. I have no strong preference; they’re all in the same ballpark for what a non-technical founder actually needs at this stage. Anyone telling you a specific one is five times better than the others is lying to you.
That’s it. Two tools. Frontier LLM plus a prototype tool. If a founder builds discipline around those two, they’ll outperform 80% of the founders who bought into some 15-tool AI stack.
Rui: One thing I’d add: the output of a frontier LLM in 2026 is beautiful compared to what we had in 2018, genuinely beautiful, and the first reaction is often “this is ready.” It isn’t. If you don’t already know what “great” looks like, the LLM will happily deliver you competent mediocrity. That’s the risk of the tool being so good so fast. You need either the taste yourself, or a real advisor around you, to know when the output is a starting point and when it’s actually done.
How to use an LLM properly: it’s a therapist, not an oracle
Igor: This is the single most important reframe I can offer any non-technical founder building today. Do not use an LLM for answers. Use it for questions.
I mean this quite literally. If you go into ChatGPT or Claude and clumsily ask “is this a good idea?”, you already know what happens. It tells you it’s a brilliant idea. It’s the perfect combination of features. Go build it. That answer is worthless. Worse than worthless, because it feels validated and it isn’t.
If instead you use the LLM to generate the questions you should be asking, the questions a second-time founder with real scars would ask you before you commit to building, the output is transformative. It’ll tell you to talk to five specific customer types before you build. It’ll surface the assumption you’re smuggling in without noticing. It’ll point at the market segment you assumed away.
Think of it as a therapist. You don’t expect a therapist to hand you the answer. You expect a good therapist to ask the questions that let you find the answer yourself. AI in 2026 is exactly that, at scale, for free.
And there’s a bonus with the AI-as-therapist analogy that I love. You can’t snap at your therapist. If you do, they stop working with you. Whereas the AI takes it. The AI absorbs it and gives you a better answer anyway. That’s a genuine feature for the way most founders actually work, which is stressed, under pressure, and occasionally short-tempered.
The under-hyped capability: context, not answers
Rui: What’s a real capability non-technical founders should be using in 2026 that mostly aren’t? For me the answer is recording, processing, and storing information. The fact that people aren’t building a searchable second brain for their company from day one is stunning. What’s yours?
Igor: You’re basically pointing at what I’ve been trying to formulate for the last three months, and I’m going to expand it. It’s what I’d call context. The creation, storage, sharing, and access of context in a way that wasn’t possible before.
When you ask me “Igor, how are you doing?”, my answer is “I’m fine, going on vacation next month.” That’s a useful answer. But what you might actually need is not that single response. What you might actually need is a ten-thousand-line document that includes that answer plus every conversation I’ve had this month, every project I’m blocked on, every product decision I made this week. That corpus of data, bigger than what you need for the immediate answer, is a completely different kind of resource, and until very recently it was impossible to work with productively.
Now, with LLMs that can hold hundreds of thousands of tokens of context and models that can search across long documents intelligently, you can build a personal or company “second brain” that surfaces the relevant answer to whatever you’re asking, with all the context around it. The productivity gain I’ve seen from this in the teams I work with is roughly five-fold for the specific tasks it applies to. Nobody I know is calling this a category yet, but it’s the biggest under-exploited AI capability for founders right now.
Rui: I’ve been calling it “big context” in my own head. It’s about being aware. Knowing more than you’d otherwise know at any given moment, because your tools remember everything on your behalf and can surface the relevant piece when you ask.
Igor: Exactly. And the way you access it, the way you share it, the way you create it. Those are the levers that are going to define the productivity differences between companies over the next few years. This is not a “some day” observation. This is here.
What non-technical founders CAN’T do with AI in 2026
Rui: Let’s get into the section I think most articles about AI-for-founders skip entirely. Where it breaks. When founders come to us at Altar wanting help finishing something they built with AI, what wall have they hit?
Igor: The wall is closed beta. Let me explain what I mean.
The best current application of AI-generated software is a closed beta. A whitelisted group of invited users, potentially even paying users if it’s B2B SaaS. In a closed beta, you don’t have malicious actors trying to break your app, and infrastructure scalability is a non-issue because you know exactly how many users you have. AI-generated code holds up perfectly well for this stage. If your goal is to demonstrate the product to investors, validate with early customers, or run structured pilots, an AI-built prototype gets you all the way there.
The moment you go live, whether that’s a public launch, uncontrolled sign-ups, or real traffic, everything AI cannot yet do surfaces. Security hardening. Infrastructure scaling. Handling malicious actors. Edge cases nobody thought about because the code was generated to the happy path. Auth flows that work when a real attacker is probing them.
If you don’t have a DevOps or security background, going live with AI-generated code as your production system is the single most common expensive mistake I see. Stay in closed beta longer than feels comfortable. Then bring in real engineers before you open the door.
Let me give you a recent example. Two co-founders, very early stage, neither of them technical, but exceptionally good at selling. The product was an internal AI tool for companies, and the whole idea depended on speed: you ask it a question and it answers in real time, the way you’d expect ChatGPT or Claude to answer you.
They built a prototype with AI, actually functional, connected to a real database, and they did an amazing job with it. They got letters of intent, agreed on future pilots, and won a first tranche of grant money. The milestone for the next tranche, something like ten times the money, was to build the working version and onboard the pilot clients who had already signed up.
That’s exactly where they got stuck, and nothing dramatic happened, which is what makes it interesting. The tool simply took twenty or thirty seconds to answer a simple question, because AI will generate code that works, but it won’t build you the infrastructure that makes an AI product respond in real time. And when a company adopts an AI tool today, it expects it to be as fast as the tools from OpenAI or Anthropic. Nobody runs a pilot with something thirty times slower than what they already use. So the pilots stalled, and they ended up rebuilding from scratch with outside help. The rebuild wasn’t that difficult, but they couldn’t do it themselves, and it cost them months against a grant deadline.
The ironic part is that the demo was perfect. It’s what won them the grant. The exact thing that sold the product was the thing that couldn’t survive a real pilot.
The most expensive mistake: leaking API keys
Rui: What’s the single most expensive mistake you’ve seen a non-technical founder make with AI in the last twelve months?
Igor: Leaking API keys. It’s not glamorous, but it’s real and it’s costly.
For readers who don’t know what an API key is: it’s a credential that lets your app talk to a paid service. An LLM provider, a database, a payment processor. It’s linked to your credit card. When AI generates code for a founder, the AI doesn’t have a concept of “visible to the world” versus “private.” It writes code that works. That means it might store your credentials in plain text. It might expose a database to the public internet. It might leave an API key in a client-side file that anyone with a browser can read.
I’ve seen founders lose tens of thousands of dollars this way without knowing until the bill arrived. The pattern is: you deploy your AI-generated app, someone finds your exposed API key within days or hours, they use it to hammer whatever paid service it unlocks, and by the time you notice, you’ve burned through your seed capital.
Rui: A friend of mine had a lower-stakes version of this. A Google API key exposed through a Make.com automation whose keys he didn’t rotate properly. He got lucky; the exposure was small. But when I think about heavy users, our own CTO spends hundreds if not thousands of euros a day on LLM consumption running production workloads, if a determined attacker gets that key, you don’t have “a bill you didn’t expect.” You have a company-ending event by Friday.
The takeaway is simple. Even if you’re building solo with AI as your co-pilot, get someone who actually knows security to look at what you shipped before you deploy it publicly. That review costs a few hundred euros and it can save you your entire runway.
The “shipped in a weekend” LinkedIn myth
Rui: Every third post on LinkedIn right now is a founder claiming they built ten products before Sunday lunch. What’s the honest truth about what happens when a weekend-built product hits real users?
Igor: Out of ten of those posts, I’d say maybe two are technically true. The other eight are made up or heavily embellished. Of the two that are true, what got built is a demo, not a product. It looks like a product. It behaves like a product for the first ten users. For a pitch meeting or an angel round it’s genuinely useful.
The moment you point real traffic at it, the same two things we’ve been talking about surface immediately. Security holes get probed. Infrastructure buckles. Something breaks that a weekend of AI-assisted coding never thought about because the founder didn’t think about it.
Weekend builds have their place. They’re excellent for demonstrating an idea. They are not products in the sense that they can survive contact with hundreds or thousands of concurrent users. Understand which one you’re building and be honest about it.
The refactor ratio: 70/30
Rui: When founders bring you products they built with AI and want us to help them finish, what’s the split between fixing what was built and building from scratch?
Igor: Roughly seventy-thirty. Seventy percent of the time we restart, because the prototype served its purpose as an explanation of the idea but the technology, architecture, and infrastructure it needs to actually scale are so different from what got prototyped that it’s faster to rebuild. Thirty percent of the time we can do a deep refactor of what’s there.
The interesting thing is that even when we restart, the AI-built prototype was almost always worth building. Not because we’re using its code, but because it de-risked the idea. It let the founder see the product, show it to customers, and prove there’s a market before spending real money on a real build. That’s the correct mental model for AI-generated product code in 2026.
What’s overhyped: Too many CLAUDE.mds
Rui: Rapid fire. What’s overhyped right now that will look silly in eighteen months?
Igor: A CLAUDE.md file for every folder in the project. It’s the same cargo cult we saw with prompt engineering: nobody really understands how these models work, so when someone who claims to understand posts a flashy setup, everyone runs with it. There’s nothing wrong with a CLAUDE.md as such, a bare-bones map of what lives where saves the model time and tokens. The problem is people happily overuse it, introducing rules and structure where none is needed, until there’s a CLAUDE.md in every folder and the scaffolding is heavier than the thing being built. That confuses the model more than it helps it.
What’s the single biggest change from 2024 to 2026?
Rui: In concrete terms, what’s the single biggest thing a non-technical founder can accomplish today that they couldn’t in 2024?
Igor: A functional prototype that explains the value of the product. Sometimes even a working product for a small audience. That’s the two-year delta. It sounds small. It changes the entire economics of the earliest stages of a startup.
The one question every non-technical founder should ask their technical partner
Rui: What’s the one question a non-technical founder should ask any technical partner, be it an agency, freelancer, or co-founder, before signing anything for an AI product build in 2026?
Igor: The question I would ask is: what have you built yourself, zero to one, and how did it work out? Not what they built for previous clients, but what they built as their own product, with their own money on the line. And notice that the question doesn’t mention AI at all, which is deliberate. If someone just added AI to their positioning, they’ll answer it with tools. They’ll tell you which agents they use and how much faster they ship now, and that’s the tell, because the tools are the part anyone can copy in a weekend. What you’re actually listening for is scars. What they decided not to build, what broke when real users showed up, what the rebuild cost them. Someone who has never paid for those lessons on their own product will end up learning them on yours. And ask this question to everyone you’re considering, whether it’s an agency, a freelancer, or a potential co-founder. The reaction to the question tells you almost as much as the answer.
The homework: use AI as a red team, not a wingman
Rui: If a non-technical founder reads this article and does exactly one thing after, what should it be?
Igor: Whatever idea you’re currently sitting on, even if it’s still just in your head, unbuilt, go and stress-test it with AI. Not as your wingman. As a red team. Ask it to attack the idea. Ask it what would kill it. Ask it what you’re not seeing. Ask it what a specific type of sceptical customer would say. Use it to destroy your own idea in a safe environment.
If the idea survives that stress test, it’s stronger. If it doesn’t, you’ve saved yourself six months and a lot of money. Either outcome is a win.
And a final recommendation
Rui: One book, tool, or resource you’d send a non-technical founder building an AI product today?
Igor: None. Don’t listen to anyone. Go experiment. That’s the only way to get reliable information about AI in 2026. Everyone lies, including well-meaning people. Read less. Build more. Trust your own hands over anyone’s takes, including mine.
Where to go from here
If you’re a non-technical founder and any of this landed, we run a paid Product Scope, a short, structured engagement where we help you pressure-test the idea before you build. It’s designed to answer exactly the questions Igor described above: what to build, what not to build, what an actual AI product architecture should look like at your stage, and where the walls will hit you.
You can book a call if you want to talk. If not, take the homework Igor gave you and start there. Either works.
