Building an MVP with AI has never been easier. Building one well is still hard.

Just a couple of years ago, turning an idea into a mobile app or a piece of software took a serious amount of time and effort. All of that work happened before you even knew whether the product made sense. You had to design the interface, pick an architecture and a tech stack, configure the project, and write enough code by hand to produce a first version someone could test, and that version probably would not work correctly. Good times, right?

Today, AI tools clearly can (and do) accelerate much of that process. An idea explained in natural language can turn into components and databases within minutes. APIs and even operational features can show up within hours.

This shift is making software development more accessible to people who have never programmed, and much faster for those of us who already work in software engineering. The ease of generating code can also create the wrong impression:

"Building a product consists of describing features and waiting for an AI to implement them."

Anyone who has worked as a programmer (or even as a project manager) knows that writing code is only one part of the job. You still have to decide which problem, out of all of them, is worth solving first and which should wait, what the first version should look like, and which features should stay out.

At Code with Beto, we have incorporated AI into different stages of development, from initial exploration to implementation and code review. I will not lie to you, the increase in speed is real, but so is the need to exercise judgment. We can now build more in less time. That does not mean we should.

Built around a single task

Working with digital content every day meant we constantly had to adapt the same image to different formats: a square post, a vertical story, a YouTube thumbnail, an Open Graph image, or a specific aspect ratio for social media.

FrameKit came from a fairly small need. The idea behind can be summarized in one sentence: "Crop once. Export everywhere". You import an image, adjust its framing once, choose the formats you need, and export every version. Easy, right?

The process was not technically complex. We already had our frames in Figma. We would upload the photo into them and adjust each one if necessary. Still, the process was repetitive enough to interrupt our work.

Obviously, we did not want to build a design platform or compete with tools such as Photoshop or Canva. This is important because many solo builders want to take on the big companies when the real priority is one thing: eliminating a specific point of friction in your own workflow.

Limiting the product to one functional task was an important product decision. FrameKit had to open quickly, let anyone understand the interface without a manual or an onboarding flow, and solve the task in as few steps as possible.

If we added too many options, another sidebar, or more editing tools, the application could certainly become more powerful, but it would also stop being the simple utility we wanted to use.

Our main flow ended up being very easy to explain because it contained practically the entire value proposition. If we could not make it useful, fast, and enjoyable, adding more features would not create the product. It would only turn it into another side project.

FrameKitCrop once. Export everywhere.

A focused macOS utility for adapting one image to every social format. No accounts, no cloud uploads, no extra features in the way.

AI makes it far too easy to build too much

A common issue when working with AI is that it can suggest many reasonable features like custom presets, project history, cloud synchronization, batch processing, background removal, automatic framing, user accounts, etc.

None of those ideas is absurd, in fact, some could become good features after validating the product. But this brings us back to the point I made earlier, they were not necessary to prove that solved the original problem.

We should also remember that, before AI, every stage of development had a natural barrier, every feature cost time and effort. It had to be designed, programmed, tested, and eventually maintained. Adding something new was expensive enough to force us to consider whether it was genuinely worthwhile and whether the time invested made sense.

Today, that friction has decreased dramatically. You write a prompt requesting an implementation, receive it within minutes, and it may even include integrated tests. All of this means having something reasonably functional in a fraction of the time it would have taken us before.

What's so bad about that?

I understand why you might think there is nothing wrong with that, especially if you do not work in software. But there is a consequence that few people see or understand because it is very easy to confuse the number of features with progress.

After several hours, we can end up with more screens, configurations, files, and functionality that you will not be able to understand, and your main problem will probably still not be properly solved.

An MVP is not a small version of all your ideas

When someone imagines an application, it is normal to think from the beginning about authentication, profiles, notifications, subscriptions, analytics, integrations, administrative dashboards, and different types of users.

That idea has been drilled into us since university. In class, a project only felt valuable if it looked like a complete system: auth, roles, a dashboard, every feature on the checklist. Incomplete meant unfinished, and unfinished meant it did not count. So even when we say we are building an MVP, we still pay more attention to the "product" than to the "minimum."

An MVP should begin from the opposite direction. Instead of reducing twenty features until they fit within the budget, it is better to identify the smallest interaction that proves whether the idea has value.

This distinction becomes even more important when we work with agents, because the speed of implementation can make us feel that we do not need to choose.

However, every feature introduces new decisions, potential errors, and maintenance work. It also occupies space in the user interface and makes the product's purpose less clear.

I also want to clarify that keeping your MVP small does not mean building something careless. It means investing the right amount of effort and available time in the part that truly matters.

What changes for someone who does not know how to code?

A non-technical founder no longer needs to wait months to discover what their idea might feel like. They can create a demo, show it to other people, and learn from their reactions before making a larger investment.

The risk appears when a "functional" interface is interpreted as a product ready for real users.

Behind every screen, there are still many decisions that remain invisible to them: where to store the information, whether in a database or locally; who can access it; how to handle errors and empty states; and how to protect data or credentials.

AI can implement many of these pieces, but it needs a great deal of context and supervision. If someone does not know that a particular problem exists, they will not necessarily know that they need to avoid it, request a solution, or verify that the generated code includes one.

This does not mean that someone without experience should abandon their idea. Do not misunderstand me. It means they need to distinguish between a prototype designed for learning or testing versus a product prepared to operate for other users.

My main advice for a non-technical person is this: the best initial use of AI is not to build the entire application. Define the problem more clearly, reduce the scope, and produce a first version that allows you to validate the most important assumptions.

If that version demonstrates genuine interest, you will have better reasons to invest in the next stage. If it does not, I am sure you have another idea you can work on.

That's the same approach Beto covers in From Idea to App Store with Claude Code: go from an idea to a real app without trying to build everything on day one.

What changes for those of us who work as engineers?

Realistically, AI does not eliminate the need to understand software. We read and write code every day. What changes is where we invest part of our development time.

We can now spend less effort remembering mechanical details about an API or writing repetitive structures, and more time defining constraints, analyzing proposals, reviewing implementations, and identifying the cases the model did not consider, or where it is overengineering.

When we use AI for development, we still make decisions about architecture, dependencies, security, performance, and maintenance. Our main responsibility is to verify that the code integrates correctly with the rest of the project.

An agent can generate a convincing solution in isolation and still introduce an unnecessary abstraction or ignore an important product convention.

The ability to evaluate the result becomes especially valuable because code can grow very quickly. Adding ten new files has a very low immediate cost, but maintaining them for the next several years does not.

An engineer's best contribution may be removing part of the generated code, simplifying the flow, or deciding that a feature should not exist yet.

AI knows the code, but it did not experience the product's origin

A model can analyze a repository and develop a fairly good understanding of how it is built. It can identify patterns, explain modules, and propose changes that are consistent with the existing implementation.

What it does not automatically know is the history behind every decision, and that remains 100% human, for now.

AI was not present when we observed the friction that gave rise to FrameKit. It does not know which part of the workflow was wasting our time or why we preferred a limited utility over a more complete design platform.

It also does not know about the conversations in which we rejected ideas, or the constraints we decided to accept to protect the product's simplicity.

Remember that working with AI is not simply about writing longer prompts. It requires communicating and explaining the problem, the product's boundaries, and the criteria we will use to evaluate a solution.

Good context can explain that an application should feel immediate, that it does not need user accounts, or that a particular action must be completed in only a few steps.

Without these constraints, any model will usually optimize for producing a complete solution from a technical perspective, not necessarily for preserving the product's identity and core idea.

Product judgment appears precisely in those decisions. You have to understand what the person using the tool needs, what level of complexity is acceptable, and which parts can wait.

AI should not decide on its own which of those alternatives best represents the product we are trying to build. Those decisions still belong to the team or the developer.

Building is still a form of choosing

Every day, more people are turning their ideas into prototypes, more teams are exploring products, and more tools are being created to solve highly specific problems.

This also means that we are seeing a considerable amount of unnecessarily complex software, built not because someone needed it but because it had become easy to produce.

In that environment, knowing how to develop, understanding the fundamentals, and understanding the language you are producing will remain valuable, but it will no longer be enough.

The ability to define the problem, reduce the scope, and evaluate what is being built will carry increasing weight. When almost any feature appears to be only one prompt away, learning to say "not yet" may become one of the project's most important decisions.

At Code with Beto, we use AI as part of the design and development process, not as a replacement for engineering judgment. This allows us to explore, implement, and review faster while dedicating more attention to the decisions that define every feature we release.

BookFrom Idea to App Store with Claude Code

The mental model for going from an idea to a real app with AI: define the problem, cut the scope, and ship a first version worth validating.

Related: You can build anything, but that doesn't mean it's worth building · How to Vibe Code with Claude