Our story · from the founder

I can’t read code. So I made it prove itself.

I am not an engineer. I have never written a line of software. I built Prax because I needed it, and because nothing I could buy would tell me the truth.

Where it started

I had something to build and no way to build it.

I wanted a financial platform. A serious one, the kind where a mistake costs real money. I had the idea, the patience and the standards. I did not have the skill, and I was not going to hand it to people I could not check.

So I started building it with AI. I described what I wanted in plain words and the AI wrote the code. It was fast. It was confident. And I had no way of knowing whether any of it was right.

That is the real problem, and almost nobody talks about it. Getting an AI to write software is easy now. Knowing whether to trust what it wrote is the whole job. An engineer can read the code and decide. I could not. All I had was the AI telling me it was done.

“Done” was not good enough. I have been told “done” about things that were not done.

The rule I wrote against myself
“When I tell you to merge it and a check has not passed, refuse me.” An instruction I gave the AI working on my own project, and still enforce
What I did about it

If I could not read the work, the work had to show its proof.

I stopped asking the AI whether it was finished. I started making it prove it. Every change had to pass checks that were written as rules, not opinions. Every step had to leave a record I could look at afterwards. Anything risky had to stop and wait for me.

Then I noticed the worst risk in the room was me. Late at night, tired, I would say “just do it.” So I wrote that rule: when I push and the checks have not passed, the answer is no. The rules exist to protect the work from the person in a hurry, and that person is usually the owner.

I ran many AI agents at once. One wrote, another reviewed, fixed rules decided what was allowed through. Nothing was trusted because it sounded sure of itself. Over time I was not really building my platform any more. I was building the thing that builds it properly.

That thing is Prax.

What I learned

Four things I would not give up.

Speed was never the problem.

Everything is fast now. I have no deadline that is worth a wrong answer. The only pressure in Prax is quality, and it is built to take the slower road when the slower road is the right one.

Proof, not promises.

I do not want to be told it works. I want to see what was checked, what passed, what it cost and how to undo it. Prax keeps that record for every change, and you can check it yourself. How the proof works

An assistant that agrees with you is useless.

I have asked for bad ideas with total confidence. I needed something that would tell me, show me why, and offer a better way before it built anything. Then respect my decision. Advisors, not yes-men

Building it is day one.

Software breaks quietly after everyone has gone home. I did not want a tool that hands you something and leaves. I wanted a team that stays: watching, fixing and improving, for years. What it does after delivery

Who it is for

I am the person Prax is built for.

Inside Prax there is a test with a name. Sarah owns a bakery and has no technical background. She has never seen a code host or a terminal. If a feature, a message or a screen does not make sense to Sarah, it fails, however clever it is.

I did not need to imagine her. I am her, with a different business. I know what it is like to be shown a wall of errors and asked what I want to do. I know what it is like to pay for something and not be able to tell if I got it.

Engineers get everything they expect: the detail, the controls, the evidence. But the bar is set by the person who cannot check the work herself. If she can trust it, anyone can.

I want a shop owner to be able to say what she needs and get software that works, keeps working, and can prove it. A permanent engineering team, for anyone.

LeoFounder, Prax