Mentorship8 min read

From Designer to Builder

How I helped my friend Amaury Brito go from experimenting with AI tools to building complete websites and mobile apps on his own

Most of the stories on this site are about things I built.

This one is a little different. It is about helping somebody else become a builder.

Amaury Brito is a coworker of mine, but over the past few years he has also become a good friend. When I first met him, he was an associate designer at my day job. He was talented, eager to learn, and clearly wanted to keep growing.

I decided to mentor him and help him work toward a promotion.

We worked together for about a year, and it went extremely well. Amaury took the feedback seriously, kept improving, and eventually got promoted. I was very proud of him.

That experience also showed me that we worked well together as mentor and mentee. He was willing to put in the work, and I was able to give him guidance without having to drag him through the process.

A couple of years later, that led to a new experiment.

Could I teach a non-engineer to build real software with AI?

Amaury had already been playing around with tools like Figma Make and Claude’s design features. He had created some interesting prototypes and was getting comfortable using AI to turn ideas into something visual.

But there is a pretty big difference between creating a good-looking prototype and building an actual product.

Real products have users. They have databases, authentication, payments, permissions, error states, deployment issues, security concerns, and all the other things that tend to show up once you move beyond a demo.

I wanted to see whether I could help Amaury cross that gap.

I asked him if he wanted to start digging into tools like Claude Code and learn how to build complete websites and apps. I told him it would be useful for him, but also interesting for me.

I have spent a large part of my life designing and building software. I was a front-end engineer for many years before moving fully into product design, and these days I use AI coding tools constantly.

I wanted to find out whether I could take the way I work and teach it to someone without a traditional engineering background.

If it worked, it might also tell me whether one-on-one coaching like this was something I could offer to other designers and product people in the future.

Amaury was up for it, so we got started.

The goal was not to make him dependent on me

From the beginning, I wanted Amaury to be able to build without me.

It would have been easy to sit next to him, take over whenever something got difficult, and slowly turn his project into something I was really building behind the scenes.

That would have defeated the entire purpose.

I wanted him to understand how to take an idea, break it down, explain it clearly to an AI coding tool, evaluate what came back, and keep moving when things broke.

Because things always break.

We talked about how to plan projects before generating a mountain of code. We worked on giving Claude enough context to make good decisions. We discussed how to recognize when a solution was getting too complicated and when the AI was confidently going in the wrong direction.

We also spent time on the less exciting parts that become very important once real users and real data are involved.

Authentication. Databases. Permissions. Payments. Security. Testing. Deployment.

A lot of people can get an AI tool to generate something impressive in an afternoon. The harder part is building something that continues to work after the first demo.

That was the level I wanted Amaury to reach.

A few weeks later, he was off to the races

Amaury picked this stuff up incredibly quickly.

Within a few weeks, I could already see the relationship changing. He was asking fewer basic questions and making more decisions on his own. Instead of waiting for me to tell him what to do next, he was testing ideas, debugging problems, and figuring things out.

Before long, he had several projects underway.

The most impressive one, in my opinion, is the website and mobile app he built for his church.

This is not a simple informational website with a few pages and a contact form.

It has user accounts, community features, interactive content, donations through Stripe, a database, and a secured backend. It is a real product that people can actually use.

I helped him think through some of the more complicated parts. We reviewed the architecture, worked through security concerns, and discussed how certain features should be implemented.

But Amaury built it.

He did the overwhelming majority of the work himself. He made the decisions, worked through the problems, and kept pushing the project forward.

That is the part I am most proud of.

Learning how to direct the tools

Using an AI coding tool is not really about knowing the perfect prompt.

The bigger skill is learning how to direct the work.

You need to know what you are trying to build. You need to give the tool the right context. You need to recognize when it has misunderstood the problem. You need to test what it produces instead of assuming that a confident explanation means the code is correct.

You also need to stay in control as the project grows.

That is where a lot of people get into trouble. The first few features work, so they keep generating more code. Eventually the application becomes difficult to understand, changes start breaking unrelated things, and neither the user nor the AI has a clear picture of the system anymore.

I tried to teach Amaury how to avoid that.

We focused on building in manageable steps, keeping the project organized, checking the work, and solving problems without constantly throwing everything away and starting over.

Those habits matter much more than memorizing syntax.

AI can help with the syntax.

The human still has to provide the judgment.

Designers are in a better position than they may realize

One of the things this experience reinforced for me is that product designers already have many of the skills needed to become good AI-assisted builders.

Designers understand users, flows, states, interactions, hierarchy, edge cases, and product intent. They are used to taking vague ideas and turning them into something concrete.

The biggest barrier has traditionally been implementation.

A designer could have a fully formed product idea and still need an engineer, a budget, a team, and organizational approval before anything could be built.

That barrier is getting much lower.

There are still difficult parts. Security is difficult. Authentication is difficult. Data architecture is difficult. AI does not magically make those things disappear.

But designers can now go much further on their own than they could even a few years ago.

With the right guidance, I believe many of them can become genuinely capable builders.

Amaury is a great example of that.

What I learned from the experiment

Amaury is obviously only one person, so I am not going to pretend this proves that I can turn absolutely anyone into a software builder.

He deserves a huge amount of the credit.

He is motivated, curious, patient, and willing to keep going when something becomes frustrating. He actually applies what he learns. No coaching method can compensate for somebody who does not want to do the work.

But I do think the experiment showed that my approach works.

I was able to take someone who was comfortable with design tools and AI prototyping and help him become capable of building complete products.

More importantly, he no longer needs me sitting beside him to do it.

He still reaches out when he wants a second opinion or runs into something especially difficult, but that is very different from depending on me to move the project forward.

He owns the work now.

Amaury told me I should write this story

This entry actually exists because Amaury encouraged me to write it.

He told me that people should know I had helped him get to this point, and that teaching someone to become an independent builder was worth showing alongside the products I have built myself.

I think he was right.

I love making things, but there is something especially rewarding about helping someone else reach the point where they can make their own things.

Amaury can now build products for himself, for customers, for his church, and for any other idea he decides to pursue.

He does not have to wait for somebody else to make it real for him.

I am incredibly proud of what he has accomplished, and I am excited to see what he builds next.

This experience has also made me seriously consider offering this kind of one-on-one coaching to other designers and product people.

There are plenty of tutorials that can teach someone how to install a tool or copy a workflow.

What I am interested in is helping people become independent. Helping them develop the judgment, habits, and confidence to take an idea all the way from zero to something real.

Amaury did exactly that.

Explore Amaury’s work

Below are a few examples of the projects Amaury has designed and built since we started working together.

  • AB Design & Strategy — Amaury’s own design studio, where he takes on client work and showcases his case studies.
  • Iglesia Cristiana Jehová Mi Rey — the bilingual digital ecosystem he built for his church: a public website, a member app, live streaming for Bible studies and sermons, and online giving.

You can also hear directly from Amaury about his experience learning to use Claude Code and other AI tools, what our coaching sessions were like, and how the process changed what he now feels capable of building.

Amaury and me in San Francisco

From day one, Marco has been one of the most influential people in my professional growth. He has always been willing to help, no matter the time or the challenge. He helped me present a case study during my panel job interview, when everything was falling into pieces, and supported me throughout my onboarding at our company. I remember many late nights working together, sharing fresh ideas, challenging my thinking, and helping me become a stronger, more strategic designer.

His mentorship went far beyond UX design. He encouraged me to explore artificial intelligence and experiment with tools that initially felt beyond my reach. I don’t come from a software engineering background, and I had no coding experience. Yet he showed me how to leverage these technologies to turn ideas into real products.

Through his guidance, I was able to design and build a complete digital ecosystem for my church from the ground up, including a website, a mobile app, live streaming for Bible studies and sermons, online giving, and other digital tools that help serve our congregation.

What I value most is that his mentorship gave me the confidence to become an independent learner. Today, I can create these kinds of solutions on my own, but I still reach out to Marco whenever I need a second opinion or face a complex challenge.

His willingness to teach, share his knowledge, and invest in my growth has left a lasting impact on both my career and the way I approach every new project. I will always be grateful for the time, encouragement, and wisdom he has shared with me. His mentorship didn’t just help me become a better designer; it changed the way I learn, build, and solve problems.

— Amaury

Comments