how i learnt to build (as a non-technical)

in the startup world, being non-technical is basically a slur. i was surrounded by tech bros and still refused to touch code. partly because i had a CTO, so it was always faster to let engineering handle it while i did what i was good at. but mostly because i’ve always instinctively avoided things i’m not the best at. (yes, i know that’s a problem. i’m not her anymore.)

then my CTO left, and i was stranded. we had over a thousand users on a live app. some people sent me contacts for agencies and potential CTOs. others were hinting at me to quit, because there was no way i could take over the codebase and ship features myself.

but for weeks, a little voice kept asking: should you just give it a shot yourself first? i ignored it and kept going to coffee chats with potential technical hires. the voice got louder. so eventually i thought, fine. i’ll try one little thing.

that was the start of going from “nah, i don’t touch code” to shipping full features and building mini apps for fun. this is what i wish someone had told me at the start, because i was crashing out and i hope no one else has to.

the one little thing

my first few changes were tiny. removing a button here, a modal there. the first real thing i built was a revamp of the milestone screens, the ones you see after logging an activity.

i’d wanted to fix those forever, but i could never get engineering to prioritise them. they were animation-heavy and design-heavy, and i didn’t even know what was possible, so i couldn’t ask for anything specific.

so i just riffed with AI. no design, no plan. what if we did this? what if it looked like that? somewhere along the way i went down a rabbit hole on how duolingo does its lesson completion screens, and got inspired to build a fancy ball motion animation.

it was overkill. i ended up shipping something much simpler. but i don’t regret any of the crazy versions, because that’s how i found out what was actually possible, and what i could actually do.

it also took way longer than i expected. i thought duolingo’s screens were simple. only when i tried to build one did i realise how much goes into something that looks effortless. by the end i’d learnt more about what makes a completion screen good, great or bad than i ever would have by writing a spec.

you don’t have to learn to code

“learn to code” always sounded daunting. people spend years teaching themselves programming, and i had zero interest in doing that. but the tedious part is gone now. you can build things without knowing syntax rules, data types or how a for-loop works.

there’s no syllabus either. the best way to get comfortable building is to build something. start with a simple web app. i started with mobile because snowball was a mobile app, but that’s a lot more setup, and i’d 100% recommend web first. it doesn’t even need to be full-stack. a single-file, front-end-only app is plenty, and a claude artifact is a great place to start.

once you realise you can build really personalised things, ideas start coming. i wish this could send me push notifications. or pull live stock prices. or remember my data across devices. that’s when you ask your AI agent, and it tells you you need a backend.

then maybe you want continuous GPS tracking, or more reliable notifications, or for your friends and family to use it too. you ask again, and it suggests turning it into a mobile app.

you only add complexity when you hit a wall with your current setup. that makes it so much less overwhelming, because you always know why you’re adding something. you pick up the terminology along the way, with context, right when you need it. oh, apparently i need a database for this. a database is basically X, so i can do Y. that’s the whole guide really: learn things in the moment you need them, not all the theory first.

and you don’t have to understand everything your agent is doing. but if you’re curious, ask it to explain. it’s way more fun to follow along while it works.

let your ignorance be a blessing

dream big. don’t hold yourself back with nah, this is overkill or this is probably too complex. as a non-technical person, you’re blessed with not knowing what’s hard to build, so let that ignorance push you to try all sorts of things.

your estimates will be wrong, and that’s fine. some things i thought were complex turned out to be a one-line change. some things i thought were easy, like a “simple” completion screen, turned into way more work than i expected. over time you build a sense for what’s hard and what isn’t.

so go crazy. build the ball animation. do the “this is so extra” thing you pictured. worst case, you ship the simpler version and know exactly why.

do it from your phone, do it for fun

one practical tip: get claude on your phone. it’s so much easier to prompt your agent wherever you are. the idea for my gym assistant app came to me mid-workout, so i just picked up my phone and started building. every time i used the app at the gym, i’d think of something to improve and tell claude code right there. i never opened my laptop for that whole app.

i didn’t start this for fun. my CTO had left and i was in a pretty dire situation, so i had to do something. but i found the fun along the way, and i think that’s really important. so try it because it’s fun, not because linkedin told you to start vibe coding 🤡