What I'd Tell a Designer Who Wants to Build
The bottleneck was never the code. It was the judgment. Start before you feel ready, direct the tools instead of deferring to them, and tell the true story rather than the impressive one.

You don't need to become an engineer. You need to get dangerous with judgment
Every designer I talk to right now is having the same quiet thought: could I just build the thing myself? A year ago the honest answer was no, not without a team. Now it is yes, but not for the reason people assume. The bottleneck was never the code. It was the judgment.
Here is what I would tell you before you start.
1. Stop waiting to feel ready
I am a designer. I had no engineering team. I started anyway, shipped, hit a wall that forced me to rethink who the product was even for, and rebuilt around a different audience, in weeks. If I had waited until I felt qualified, there would be nothing to show. I remodel houses the same way. I do not wait until I am an expert to pick up the tool. I start, I learn on the job, and I fix what I get wrong. Action teaches faster than planning ever will.
2. Direct the AI. Do not defer to it
The leverage is real, and so are the confident mistakes. The one that stays with me: my app has a PIN wall that is supposed to keep a viewer out of the admin area. It built clean. I even confirmed the right code had shipped. And it did nothing. The guard logic quietly let any signed-in session straight through, so the admin area was reachable just by typing the address into the bar. The build was green and the product was broken. That is the sentence I keep taped to the inside of my head now. A passing build proves nothing about correctness. You have to drive the real thing.
There is a subtler kind of wrong, too. My AI helper confidently told me a paid tier would remove the ads in my video player, and it was flat wrong. I only caught it by reading the platform's own documentation, which said plainly that it does not work that way in the embed I use. If I had trusted the confident answer, I would have made a false promise to caregivers about ads in a product built for a vulnerable audience. The value of AI is not what it hands you. It is what you do after.
3. Make it a partner, not a yes-man
Here is the thing nobody tells you: an AI will happily agree with you straight into a wall. Ask it "is this good?" and it will find reasons to say yes. The quality of what you get back is set almost entirely by how you talk to it. My best work comes when I say things like "this is just my current thinking, poke holes in it," or "I am open to being wrong here," or simply "keep me honest." Those few words flip it from a mirror into a sparring partner. It starts telling me what I got wrong instead of what I want to hear, and that is the version of the tool that actually makes you better.
And if you are reading all of this thinking you are not technical enough to drive, that is exactly the reason to drive. You do not need to already know. You need to be willing to ask the dumb question, sit in not-knowing for a minute, and let the tool teach you as you go. The people who get the most out of AI are not the ones who arrive knowing the most. They are the ones who stay curious, take the wheel, and treat the machine as a partner they are actively questioning, not an oracle they are quietly obeying.
4. Your design skills matter more now, not less
The biggest decision in this entire project was not a line of code. I started out building for kids. Then I watched a free, better-funded product eat that exact idea, and I realized the real gap was somewhere else entirely: caregiver-curated video for autistic and IDD teens and adults, an audience whose own complaint is that everything is built for five-year-olds. No model handed me that. It came from reading a market and listening to a community. When anyone can generate a screen in seconds, the scarce thing is knowing which screen is even worth generating. That is taste, and taste is design.
5. Keep a hand on the wheel
The rule that saved me: the thing writing the code cannot be the thing approving it. Separate building from checking. Drive the real product yourself, on the real screens, and read what it actually does instead of what the code claims it does. Verify a claim before you repeat it. Own the direction, because deciding what the thing should be is the one job no model can take from you.
6. Do not sell the "AI-built" story
It is a worse story than the truth. "AI-built" erases the part that is actually hard and actually yours: the decisions, the reversals, the taste, the calls no model can make for you. Say what really happened. A designer with no team started, hit a wall, rethought the whole audience, caught the machine being confidently wrong, and rebuilt. That is a better story, and it has the advantage of being the real one.
The short version
- Start before you feel ready. The readiness comes from starting
- AI is leverage, not a decision-maker. A green build is not a working product
- Talk to it like a partner. Ask it to keep you honest and it will, agree with you and it will do that too
- Taste and judgment are the scarce skills now, and yours already qualify you
- Separate who builds from who checks, and always drive the real thing
- Tell the true story, not the impressive one
I am Aneil Razvi, a product design and AI experience leader. Cubby, my personal project, is a caregiver-curated video app for teens and adults with autism and intellectual disabilities.
Available for fractional design leadership and advisory work.
First published on LinkedIn on 1 September 2026. Read the comments there →