Being non-technical stopped being the disadvantage

There is a particular feeling that comes with being the non-technical founder of a software company, and if you have had it you will recognise it immediately.

It is the feeling of describing something clearly, watching everyone nod, and then seeing something else entirely two weeks later. Not because anyone was careless. Because the thing in your head and the thing in their head were never the same thing, and there was no mechanism that would reveal the difference until it was expensive.

I had that feeling for four years.

The queue

I co-founded Triisum in February 2021 and ran it as CEO. What I did was operator work: fifty customer interviews and more, ten-plus white-label agreements, two OTA partnerships, two fintech integrations, the NIC Islamabad cohort we were selected into from over eleven hundred applicants, a team of eight across engineering, QA and operations.

What I could not do was build any of it.

Every idea went into a queue. The queue was other people, and the queue was always full. So you learn to be ruthless about what enters it, which sounds like discipline and is actually just rationing. And you get very, very good at writing specifications, not because you value the craft, but because the specification is the only lever you have. It is the entire interface between what you want and what exists.

I assumed this was a limitation I was working around. Something I would fix later by learning to code, or by hiring a technical co-founder, or by raising enough that the queue got shorter.

What actually changed

When the AI coding tools arrived I did what every non-technical founder does. I typed what I wanted in a sentence, the way you would ask a person, and I got back what everyone gets back: something that runs, looks roughly right, and is wrong in a way that takes longer to unpick than to rewrite.

I concluded the tools were for engineers. I went back to the queue.

What changed was noticing that I had been treating it like a search engine (short question, magic answer) when it is closer to an extremely fast, completely literal contractor with no memory of yesterday and no ability to ask a clarifying question.

So I stopped writing prompts and started writing the brief I had already spent four years learning to write for humans. Constraints. Edge cases. The file it goes in. What “done” means. What it must not touch.

The output stopped being wrong.

Same model that afternoon as that morning. The difference was that for the first time the specification was actually complete, and I only knew that because something had executed it literally enough to expose every gap.

The inversion

Here is the part that took me months to see, and it is the whole argument.

The four years of operator work were not the obstacle to building. They were the qualification for it.

Every hour spent writing a brief precise enough that a team of eight would not misread it was an hour of training in the exact skill that now determines whether software gets made. Learning to describe an edge case before it happens. Learning that “obviously it should do X” means X was never written down. Learning that the expensive gap is always the one nobody noticed was a gap.

I had that backwards the entire time.

If building software has become a specification problem rather than an engineering one (and I think for a large and growing class of software it has), then the person who has spent four years being forced to specify precisely, because they had no other option, is not behind. They were in training.

Where the argument stops

I want to mark the limit clearly, because the internet version of this claim does not have one and that is what makes it dishonest.

You still need technical judgement. You need to look at output and notice when it is plausible and wrong. You need to understand enough of what it did to ask why, and to understand the answer. You need to know when the right response to “it works” is “yes, but not like that.”

You cannot ship a production codebase with zero technical judgement. Nobody can. Anyone selling you that is selling you something, and I would rather lose your business than be one of them.

But writing the code and having judgement about the code are different requirements, and they came bundled together for so long that we all stopped noticing they were two things. They have come apart. That is the actual news.

What came out of it

Since then: LittleOS, an open AI operating system running fifty-plus agents. Liquid Finance, a personal-finance app with receipt scanning that I use every week, which is the only honest test of a personal-finance app. Safar, an e-visa eligibility checker for Pakistani, Bangladeshi and Nigerian passport holders. ThumbSnap AI, which turned two hours of designer time into thirty seconds. An autonomous publishing pipeline shipping fifteen-plus articles a day at zero operational cost. The Eco-Ambassadors app.

I still cannot write production code.

That is not a boast, and I am aware of how it reads. It is the evidence for a specific and falsifiable claim: that the thing which disqualified me was the thing that qualified me, and that if you have run anything (a team, a department, a business), you are closer to shipping software than you have been told.

It took me months of doing this badly to see it. It takes the people I work with about three weeks, because they get to skip the months.

That is the entire offer, and it is why I am not going to pretend it is more complicated than it is.