Building Software Without Being Able to Code: What a Year of It Actually Taught Us

Sanora One was started by someone who cannot write code. Not "can write a little" — cannot. A dentist by training, a physicist by degree, and a person who had never opened a terminal.

The platform exists. It's live, it processes payments, it has users. It was built using AI coding tools, a small number of hired developers, and a great deal of trial and error. We're writing this because the "non-technical founder builds a product with AI" story is usually told as either a miracle or a cautionary tale, and the truth is more useful than either.

What AI coding tools actually do

Tools like Cursor, Claude, and similar let you describe what you want in ordinary language and get working code back. For a non-coder, this feels like magic the first time. You type "make a login page with email and password" and a login page appears.

The magic wears off quickly, in a specific way. The tool builds exactly what you asked for, and what you asked for was wrong. Not wrong in the sense of broken — wrong in the sense that you didn't know to ask for password hashing, or rate limiting, or what happens when someone types their email with a capital letter. The tool doesn't volunteer those things unless asked, and you don't know to ask.

So the real skill a non-coder develops isn't coding. It's learning what questions to ask. After a year, our founder still can't write a function, but he knows to ask "what happens if this fails?", "where is this data stored?", "who can access this?", and "what would a hostile user do here?" Those four questions catch most of what matters.

What went well

Speed of the first version. A prototype that would have taken a hired team two months and several lakh rupees was working in three weeks. It was ugly and fragile, but it was real enough to show people and get reactions.

Understanding the product deeply. Because every feature was described in plain language to the AI, the founder had to think through every feature in plain language. There was no "the developers will figure out the details" — the details had to be articulated. That forced clarity turned out to be valuable when hiring real developers later, because the specification already existed.

Cheap experimentation. Trying an idea cost an evening, not a sprint. Dozens of features were built, tried, and thrown away at a cost that a conventional team would never have tolerated.

Independence from any one developer. Because the founder could read the code (even without writing it) and understood the architecture, no single developer had a monopoly on knowledge. When one left under difficult circumstances, the platform survived.

What went badly

Security, at first. The early versions had problems that any professional would have caught: keys committed to public repositories, database access that was too open, user data that wasn't properly separated. None of it caused a breach, as far as we know, but that was luck. Fixing it later cost more than doing it right would have.

Inconsistent structure. Code written in many sessions, over many months, with the AI's "memory" resetting each time, ended up with three different ways of doing the same thing. Professional developers who joined later spent their first weeks untangling it.

Not knowing what "done" meant. A feature that works when you test it is not a feature that works. It has to work when a thousand people use it at once, when the network is slow, when someone enters Hindi in a field expecting English, when the payment gateway is down. The founder didn't know these cases existed until they happened.

Over-trusting the tool. AI coding assistants are confident. When they say "this is secure" or "this handles all edge cases", they sound like they know. Sometimes they don't. Learning to treat the assistant as a very fast, very knowledgeable, occasionally wrong junior developer — rather than as an oracle — took months.

Hiring badly. Without the ability to evaluate code, the first developer hires were based on interviews and portfolios. Some were excellent. One was not, and it took too long to find out because the founder couldn't see the quality difference directly. The fix was to hire a senior developer for a few hours to review the others' work — money very well spent.

What we'd tell someone starting now

Build the first version yourself with AI tools. It's the fastest way to learn what you actually want, and the prototype will be good enough to show people.

Hire a senior developer for review, not for building, early. A few hours a month from someone who actually knows what they're looking at will catch the problems you can't see. This is the single highest-value spend.

Learn to read code even if you never write it. Enough to follow what a function does, recognise where data goes, and notice when something looks different from everything around it. This takes a few weeks and pays off forever.

Own everything from day one. Accounts, domains, repositories, keys — in your name, not a developer's. We wrote a separate article about this. It's not optional.

Set up the boring things before you need them. Backups, error tracking, a staging environment. Each takes an hour with AI help. Each saves days when something goes wrong.

Expect to rebuild. The version you launch with is not the version that scales. Plan for a rewrite of the core once you know what the product actually is. The prototype's job is to teach you that, not to last.

Is it worth it?

For us, yes. The alternative wasn't "hire a proper team" — it was "don't build it". Non-coders with ideas have always been dependent on finding a technical co-founder or raising money to hire one. AI tools have changed that. Not completely — you still need real developers eventually — but enough that the first mile can be walked alone.

The platform you're reading this on is the result. It's imperfect, it's still being fixed, and it's here. That's more than most ideas get.