> ## Content Index > Fetch the complete content index at: https://www.vysora.co/llms.txt > Use this file to discover other available public pages before exploring further. # We Sold Projects. Founders Needed a Loop. AI Changed Who Owns It. - URL: https://www.vysora.co/we-sold-projects-founders-needed-a-loop-ai-changed-who-owns-it/ - Published: 2026-10-14T08:21:55.000Z - Updated: 2026-10-14T08:21:55.000Z - Description: AI isn't just making software cheaper. It's shrinking the distance between what customers teach a founder and the next version of the product - and the business that lived in that distance. - Author: Enes Lisovac - Tags: AI Downstream, Startups, Product development, AI Coding Agents, MVP I used to sell founders $25,000-$80,000 MVP projects. In some of those conversations, I gave advice that wasn't good for the agency's revenue: **Don't pay us to solve problems you don't have yet.** Build something small that works. Keep it easy to change. Let real usage justify the next investment. As a consultant, that was the job. As an agency, we earned more when there was more to build. Revenue wasn't the only resistance. The other hard argument was often with our own engineers. By default, good engineers want everything right from day one: architecture ready for scale, top-notch security, complete infrastructure, abstractions for features nobody has asked for yet... That instinct is part of what makes them good. For a product no customer has touched, it's rarely needed. Both tensions were real, and they sat inside a larger contradiction I kept returning to: **We sold projects. Founders needed a loop.** --- ## A Product Has No Final Delivery A project has a scope, a budget, and a date when everyone signs off. A product has releases, but no finish line, and its scope is discovered as it runs. Its work looks like this: **build → observe → learn → change → repeat** A customer stops at an onboarding step that seemed obvious in the design. A feature everyone insisted on goes untouched. A workaround appears where the team expected a clean workflow... The team notices, asks why, changes something, and watches again. Sometimes the right call is to change nothing - but that call should come from understanding what's happening, not from loyalty to the original plan. This isn't just how founders validate an MVP. It's how products stay useful. The loop starts before the first release and continues after traction, after hiring, after profitability. As the product grows, changes carry larger consequences. The need to learn doesn't shrink; the responsibility to separate evidence from noise grows. And the loop's value depends on more than how fast code gets written. It depends on the distance between reality producing a signal and the product responding to it. **That distance is where the traditional development model got expensive.** --- ## How Learning Became a Change Request A founder watches three customers struggle with the same step in a workflow. They don't know the fix yet, but they know the current design is wrong. In a traditional agency engagement, that discovery has to travel. The founder explains what happened. Someone turns it into a ticket. A designer reworks the flow and gets it approved. Developers clarify, estimate, schedule, build, and present it for review. Each step adds delay and cost, and each can lose something from the original observation. The obvious fix is to let the agency see the evidence directly: customer calls, product analytics, session recordings... Some founders do. Most draw a line, and for good reason. Customer relationships and usage data are among the most valuable things a young company has, and in regulated products, sharing them brings contracts, access controls, and compliance obligations. So founders who can afford it hire a product manager in-house to own that evidence. The signal stays inside. It still has to cross the boundary to get built. Now put a fixed-scope contract around it. The scope was negotiated before those customers touched the product - when both sides had the least evidence about how it would behave in the real world. The discovery arrives after the agreement, so it becomes a deviation to price, approve, and manage. **The contract was written before the evidence arrived. When the evidence arrived, it became a contract problem.** Fixed scope works when the problem is understood. But an MVP exists to discover what wasn't understood when the contract was signed. In ["From Foundation to Production"](https://www.vysora.co/from-foundation-to-production-discipline-is-what-makes-ai-compound), I argued that boundaries specified upfront are assumptions dressed as design. Fixed scope is the commercial version of the same assumption. We made change something to negotiate when change was the reason to build. Retainers and time-and-materials loosen the scope, not the boundary. They trade the change-order fight for an open meter, and the cost risk moves to the founder. Discoveries still have to be translated and prioritized across two organizations. Internal teams grow their own handoffs too; agencies just make the boundary easy to see. The question underneath every model is the same: **How much work lies between learning that something should change and seeing whether the change helped?** --- ## Why Founders Accepted the Compromise If the mismatch was so visible, why did founders keep outsourcing the first build for decades? Because agencies solved a real problem. The alternative wasn't just writing the software yourself. It meant finding people with the right technical and domain expertise. Evaluating candidates you weren't equipped to judge. Hiring engineers, designers, and technical leaders. Then carrying the cost of a product team before the business had earned one. An agency rented that team out ready-made. Founders could buy the output of a product team without first assembling one. It also created a strange dependency. Founders could own the repository and still rely on people in another company to know why decisions were made, how components interacted, and what would break if something changed. Good documentation and handover practices narrowed that gap. They couldn't remove the cost of coordinating two organizations around one evolving product. **The economics of accessing a product team made friction a reasonable price to pay.** That's the price AI is changing. --- ## What AI Actually Removes Some MVPs we delivered over 2-12 weeks for $25,000-$80,000 can now reach a first working version in a week or two. A founder with AI can get there on $500-$1,000 in direct tooling costs. That comparison is illustrative, not a claim of equal engineering quality or equal total cost. The founder's time counts. So do testing, security, and everything an agency included beyond implementation. But the economics have moved far enough to change the decision. A founder sees an onboarding problem on Tuesday morning. Working with AI, they go through the support tickets and session recordings to find where users stall, explore the solution space, change the interaction, run the tests, deploy, and put the new version in front of customers in the evening. Some changes take longer. Some take a day. The hours aren't the point. Neither is the code: AI helped read the evidence and frame the options before it wrote anything. **The person who learned something can now act on it directly, without first hiring or renting a team.** That's different from an agency getting faster with AI. Agencies will use the same tools, and their engineers might drive them better than the founder can. That isn't the gap. The gap is that the person driving the agents isn't the person who watched the customers struggle. The founder still has to explain the discovery, agree on the change, and wait for it to move through someone else's delivery process, on someone else's calendar: their working hours, their other clients... More skill on the other side of the boundary doesn't remove the boundary. The real gain isn't the cost per feature. It's the cost of the next experiment, and the one after it, while the context is still fresh. Learning, deciding, and building happen close together - and the knowledge that process creates stays with the person responsible for the product's future. **AI didn't invent the product learning loop. It's letting founders keep it in their own hands.** --- ## The Bottleneck Moves. It Doesn't Disappear. There's an obvious danger in this argument: cheap changes invite too many of them. One customer struggles, and the founder rewrites the experience. The next customer preferred the old version, and the founder changes it back. AI can summarize the evidence and even surface patterns in it. It can't decide what the evidence means for this product. The loop needs judgment, not just execution. Customer statements are signals, not specifications. A working prototype isn't proof of demand. At this stage, misreading evidence is a bigger risk than under-engineering. Before traction, the technical bar is way lower than most engineers want to admit. MVPs need to discover what’s worth building. What they can’t skip is the baseline: protect the data real users hand over, including what goes into AI tools, and avoid decisions that are expensive to undo. In regulated or safety-critical products, that baseline is much higher, and some safeguards are prerequisites from day one. A founder needs enough competence to hold that line: direct the agents, spot risky decisions, and recognize when outside expertise is required. AI narrows that gap too. A non-technical founder can ask an agent to explain an architecture, list the risks in a change, or say when a problem needs a specialist. That's real help, and it's new. But it's advice from the same kind of system that wrote the code, and it shares the weaknesses. It tends to agree with the hypothesis you bring to it. And it sounds as confident when it’s wrong as when it’s right. It can show you where to look. It can’t be the only one looking. **AI makes it easier to act. It doesn't decide what deserves action.** The founder’s constraint shifts from obtaining implementation capacity to interpreting reality well enough to choose what to build. That’s a better constraint to have. It’s also a demanding one, and poor judgment gets more expensive as building gets cheaper. A founder who misreads customers can now ship the wrong fix as fast as the right one. The answer isn't to slow down. It's to keep the loop tied to what customers actually do, so it doesn't decay into a loop of generating and revising software. The speed of the loop matters. What enters it matters more. --- ## Where Agencies Fit Now What’s changing is **when** founders need agencies, and for **what**. None of this means founders should build everything themselves forever. Once a product has customers, the founder's time has competing claims: sales, support, hiring, partnerships, running the business... The product picks up real obligations too: uptime, security, data integrity, maintainability, integrations, changes that must not break existing users... At that point, an internal team or a specialized agency is often the better investment. But the relationship should look different. Engineering capacity should make it easier to learn and respond, not freeze learning whenever a delivery plan is agreed. Execution can be delegated without disconnecting product decisions from the evidence behind them. Founders running their own loop before traction, and expecting partners to strengthen it, breaks both what agencies sell and how they sell it. From working with startup-focused agencies, I see them split into groups: - many still price, package, and deliver their services like AI never happened - some hope the AI bubble bursts, as if that would take the technology back - some silently use AI to deliver the same thing, the same way, just faster and cheaper - some rebranded as AI agencies and sell AI features the same way - a smaller group is truly redesigning what it sells and how it works The look-alikes are harder to spot. Some dress the same model up as product expertise: a paid discovery phase, then design, then the build. It sounds like learning. But discovery that ends when the build contract starts isn’t a loop. It’s the same project with a longer front end. The tells give them away: scope still lives in a contract, work is still sold by the hour, the team still treats every change as a frustration rather than the point... The last group can become much more valuable. Independent, system-level judgment: how product, AI, data, and infrastructure fit together, including where AI belongs and where it doesn’t. Deep domain expertise, especially where the domain is regulated. Redesigning how the client’s business runs with AI, not just its product. Reliable infrastructure. Security and compliance. Helping a product evolve safely as its consequences grow. The value is no longer that the agency has developers or a product process. It’s what the agency can recognize, decide, and take responsibility for that the founder can’t do alone. The commercial model changes with it: no scope locked before the evidence arrives, short cycles, direct access to customers and data, engineering decisions that follow the product’s needs... Nobody watches the clock. Engagements are judged by outcomes, not output: whether the product keeps getting better, not how many features shipped. The redesign isn’t a one-time event. Some of what the last group sells today, AI may handle within months. So the agency has to run the same loop on itself: watch what AI takes over, let it go, and move toward what AI can’t carry. And it shows clients the record: what AI took over, what the agency stopped charging for, and where the work moved instead. **An agency should strengthen the client’s learning loop, not become another obstacle or handoff inside it.** Waiting isn’t a strategy. Faster, cheaper, or relabeled isn’t a redesign. --- ## The Loop Belongs to the Product Back then, “build less” was the most useful advice the model allowed. I knew the real problem wasn’t the size of the build. It was the distance between what founders learned and how fast their product could respond. No agency contract could close that distance, and most founders couldn’t afford to close it themselves. The goal was never just to build less. It wasn’t for founders to write every line of code, or to avoid agencies at any cost. It was to keep the product answerable to what customers actually do and need, without forcing every discovery through an expensive translation and negotiation. Before traction, that can be one founder and AI working on the smallest useful version. After traction, it can be a full product and engineering organization with specialists and partners. What can't be lost in either case is the continuity between observing reality, deciding what matters, changing the product, and learning from the result. That continuity isn't a development methodology. It's how a product stays relevant. I used to sell the first build. Today, I tell most founders to build their own. Not because software no longer needs engineering, but because a product team is no longer the first large commitment a founder has to make. **We sold projects. Founders needed a loop. AI is putting that loop in their hands.** See AI Clearly. Think Beyond the Hype. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime.