Why non-coders get stuck before they start

Here is the first thing I need you to unlearn.

Most non-technical people are not afraid of programming. They are afraid of the appearance of programming. They open a screen, they see a wall of symbols and brackets and colours, and something in them quietly decides: this is not for me, this requires some alien level of intelligence I was simply not born with.

That feeling is real, but the conclusion is a lie. The intimidation comes from the look of code, not the logic of it. And those are two completely different things.

Because here is what I eventually understood, and it changed everything for me:

Code is just another novel.

No matter how complex a program looks, it is made of code the same way the most impressive piece of literature you have ever read is, in the end, just made of words. War and Peace is words. A love letter is words. The difference is not the alphabet. The difference is the arrangement, the structure, the intention behind it.

I am a writer. And the moment I saw code as a novel rather than as mathematics, building became natural. Because what is writing a story? You plan the structure. You design your characters. You work out the relationships between them, who pushes who, what happens when this one meets that one. That is exactly what software architecture is. A user is a character. A feature is a plot point. The flow between screens is a narrative arc.

Programming does not require alien-level understanding. It requires the simple articulation of logic. And if you can articulate, you can build.

Where to start if you want to build an app without coding

Knowing this in your head and feeling it in your hands are two different things. I needed a safe place to start. I needed to build confidence before I built a product.

I started on Base44.

I want to be specific about why, because this matters for anyone reading this who is scared. Base44 is built heavily for non-coders. The genius of it, for me, was that I never had to look at code with my own eyes. I could describe what I wanted and watch it appear. And because I never saw the wall of symbols, the fear never got a chance to switch on.

What that did was let me get familiar with the language of the craft in a room that felt safe. I started picking up the terms. I started understanding what a database was, what a function did, what it meant for something to be "front end" or "back end," not from a textbook, but from doing. By the time I eventually did see real code, it was not an alien artefact. It was just the novel I had already learned to read.

Do not start where it is hard. Start where it is safe. Build your confidence and your vocabulary first, in a place that does not let the fear in. The hard stuff becomes easy once the fear is gone.

How to use AI to design your app before you build it

Here is the mistake most excited beginners make. They have an idea, they open a builder, and they immediately start making screens. Pretty buttons. A nice logo. They are decorating a house that has no foundation.

I did the opposite, and I credit this for everything that followed.

Before I built anything, I went to Claude and asked it to help me generate a full specification and architecture document. And I did not hold back. I dumped everything. Every function I wanted at the time. Every platform it needed to be optimised for. I asked it to design for scale, to follow security best practices, to handle data storage and privacy properly from day one. As much information as my brain could pour out, I poured. Then I asked for the architecture.

That document became the blueprint I handed to my builder. I was no longer decorating. I was constructing on a foundation that had been designed properly before the first brick.

And this is the most important practical truth in this whole piece. I am not a software architect. I do not have a computer science degree. I had no idea, on my own, how to design a scalable, secure, privacy-respecting system.

And it did not matter.

If you do not have the domain expertise, you can outsource it to the AI. You use the AI to brief you for the AI. Your job is not to be the expert. Your job is to know what you want, articulate it clearly, and let the intelligence fill in the expertise you are missing.

That is the new skill of this era. Not knowing everything. Knowing what you want, badly enough to describe it.

The product reveals itself when you live inside it

Once the basic version was up, the real work began, and it was work no spec document could have done for me.

Every builder and every writer knows this feeling: the story reveals itself the longer you sit with it. You think you are in control of the plot, and then the characters start telling you what they would actually do. Software is the same. The product reveals itself the longer you sit with it.

The shift happens at one specific moment. The moment you go from interacting with an idea to interacting with a product. Suddenly you are not imagining it, you are using it. And the instant you start using it, you see a million lapses you could never have predicted on paper. This is awkward. That is two taps where it should be one. This screen makes no sense once you are actually standing in it.

I became obsessed. Feature update after feature update, chasing a single standard. The app had to be intuitive. The app had to be frictionless. Friction is where users go to leave. Every extra tap, every confusing moment, every "wait, how do I…" is a tiny exit door. My whole obsession was closing those doors.

Build the thing, then live inside the thing. Iteration is not a phase you do after building. It is the building.

The two walls my friends showed me

When the basic functions worked, I did my first round of real tests with friends. Friends, used correctly, are diagnostic equipment. Watching real people touch your product tells you in ten minutes what you could not learn in ten weeks alone.

Two problems came back loud and clear. Two walls.

The first was scalability. Could this thing survive a crowd?

The second was stickiness. Would anyone come back?

Those are not small problems. Those are the problems. A product that cannot scale dies of success. A product that cannot stick dies of silence.

Stickiness: people come back when they see movement

The problem was simple. People would use the app, then leave, then forget it existed. There was no reason to return. The core issue, I realised, was notification. There was nothing pulling people back, no signal that said "something is happening, come and see."

So I ran a test. I rigged up notifications using email and watched the numbers. And there it was: an uptick in returns. People came back. I could not afford to pay for email notifications across the entire site, that was not sustainable. But I did not need the full system to learn the lesson.

People come back when they see movement.

A social product is not a place. It is a heartbeat. If nothing moves, it is a dead room, and people do not return to dead rooms. So I went and built my own notification system, for both web and mobile, so the heartbeat would never stop and it would never bankrupt me.

This is also a good moment for a shout-out, because it is a lesson too. Building for web, Android, and iOS used to mean building three separate things. Three codebases, three teams, three times the cost, the exact cost that killed HVNG the first time. Then I learned about React, and the fact that it lets you operate web, Android, and iOS all from one codebase and one database, instead of doing everything three separate times. Shout-out to the inventors, genuinely. That single idea is part of why a person like me can now build what used to take a company.

Technology is not just tools, it is leverage. Find the leverage that lets one person do the work of a team, and use it without shame.

Scalability: you are not building for one village

Now the harder wall.

The backend I had been prototyping on was, to be honest, a toy. Beautiful for a prototype, fine for proving an idea, but the moment I imagined real load, it fell apart. My testing made it clear that if a couple of hundred people were on the site at the same time, the logic would start to buckle.

And I had to ask myself an honest question. Who am I building for? I was not building for a single village. I was not even building for a large family. I was building for a crowd, eventually for a city, and the foundation I was standing on could not hold that weight.

A quick warning, since some of you will quote me: do not confuse "the starter tier I was on hit a ceiling" with "this tool cannot scale." Those are different sentences. Production tools scale far beyond a prototype setup once you configure them properly. What I had outgrown was the toy version, not the technology.

So I researched where to move, and I chose Supabase as the real home for HVNG. Here is exactly why, because the reasoning is more useful to you than the name:

• It had strong support for vector storage, which I needed for what HVNG is becoming.
• It was genuinely affordable, with a free tier to start on, so I was not betting money I did not have before I had proof.
• Critically, it handles authentication and token keys properly. That last one is not glamorous, but it is the difference between a real product and a lawsuit. I do not want to be the person who stored people's data badly and got sued. You should not want that either.

Choose your infrastructure for where you are going, not just where you are. And never treat security and privacy as a later problem. Later is too late.

Hands-on lab

The chapter above is the why. These guides are the how. The one rule never changes: if a step stumps you, screenshot it and paste it to your AI with "assume I have no technical experience; tell me exactly what to click next." Nothing here cannot be undone.

G1.1 · Write your first architecture and spec prompt [Core]

What you'll have: A clear blueprint you can hand to any builder, describing exactly what to build.

Before you start: Beginner · 30–45 min · free · you'll need a clear idea and a chat with Claude

1. Open Claude and set the role: "Act as a senior software architect helping a non-technical founder."
2. Describe your product in plain language: what it does, who it is for, the core things users can do.
3. List every function you want for version one. Do not hold back; dump everything.
4. State constraints and priorities: which platforms (web, iOS, Android), and that it must be scalable, secure, privacy-respecting, and affordable.
5. Ask for: a feature list, a simple data model (what information you store), a recommended technical approach, and security and privacy best practices.
6. Ask it to flag anything you forgot, and to design "scalable from day one."
7. Save the output. This is your foundation document.

Check you did it right: You have a written spec listing features, data, and a build approach.

If something looks off: Output too vague → add detail and regenerate. Overwhelmed → ask it to split must-have (v1) from later.

G1.2 · Build your first working version on Base44 [Core]

What you'll have: A clickable prototype of your product.

Before you start: Beginner · a few hours · Base44 has a free tier to start · you'll need your spec and a Base44 account

1. Sign up at base44.com and start a new project.
2. Paste the key parts of your spec into Base44's build prompt and describe the first version you want.
3. Let it generate the app, then click through what it built.
4. Iterate in plain language: "add a profile page," "make the home screen show X."
5. Keep going until the core journey works end to end.

Check you did it right: You can open your app and click through the main journey.

If something looks off: It built the wrong thing → describe the difference and ask again. Stuck → screenshot and paste to the AI.

G1.3 · Add a simple notification system [Optional]

What you'll have: A way to pull users back when something happens.

Before you start: Beginner · 1–2 hrs · free to low · you'll need a working app

1. Decide your triggers (a new message, someone joined an event).
2. Ask the builder to add in-app notifications for those triggers first (cheapest).
3. Test email nudges on a small scale before paying for volume.
4. Later, add web and mobile push once you are on your own stack.

Check you did it right: Doing a trigger action produces a visible notification.

If something looks off: Too many notifications annoy users → notify only on what they care about.

Stop building alone

I want to end on something bigger than HVNG.

HVNG died once because a non-technical person could not afford the cost of building. That sentence used to be a full stop for millions of people. AI has turned it into a comma. And I do not think we have begun to understand how deeply this changes things. The barrier that decided who got to build, and who only got to dream, is coming down.

Think of it like the home studio revolution in music. There was a time you needed a major label and an expensive studio to make a record anyone would hear. Then the equipment got cheap and got into bedrooms, and an entire generation of independent artists changed the sound of the world from their homes. AI is the home studio for builders. You no longer need the label. You can make the thing yourself.

But here is my real ask. Learn this, and then do not build alone.

The solo model is not how we win, especially not here. Africa has to take an ecosystem approach. Some of us will need to share hosting. Some of us will need to share tokens. We pool what we have so that no good idea dies the way HVNG nearly did, in a drawer, for lack of money.

What's next

I knew I had to migrate to a proper foundation. Being sensible for once, I called a coding friend to help with the move. And then impatience struck, that same voice that got me into all of this, whispering: you have come this far on your own, you can do this too.

So I started the migration alone. How that went, what broke, and exactly how you set up GitHub, Vercel, Supabase and Claude Code as a non-coder, is Part Two: From Prototype to Live. Sit with the cliffhanger. It is the exact discomfort every builder learns to love.