the method

Yes, I use AI. Here's the honest version

Almost everyone quoting you is already doing this. Most won't say so, and a few will deny it. I'd rather tell you exactly what the tools do, exactly what I do, and let you judge whether the combination is worth buying.

the two ways this goes wrong

Both of them cost you money

failure one

The tools without the judgement.

Code arrives fast, looks professional, and runs. Nobody experienced has looked hard at it. The access model has a hole in it, the data design will trap you in a year, and the person who delivered it can't explain either — because they didn't decide them. You find out under load, or under attack, or when you try to change something.

failure two

The judgement without the tools.

Careful, experienced, senior people, quoting you for months of work that no longer takes months. The result is sound and the invoice is from a previous era. You pay a serious premium for a discipline that could have been applied at a fraction of the time.

What I sell is the intersection: 22 years of production experience, deciding what a system should be, using tools that have made building it dramatically faster.

stated plainly

Where the tools help, and where they don't get a vote

method.logask me about any line of this

        // the design is mine
        How the system is shaped, who is allowed to do what, how the data is modelled, what happens when things fail — I decide all of it before a line is generated. I do use AI here, but as an adversary: I ask it to attack my design and tell me what I've missed. Interrogating a decision is not the same as delegating it.
         
        // the building is accelerated
        Once the shape is fixed, the tools fill it in — and this is where the time and your money actually go in a traditional quote. It's safe here precisely because the decisions were already made.
         
        // nothing ships unverified
        Nobody reads fifty thousand lines, and anyone who tells you they do is selling something. What I read closely is where the risk sits — authentication, permissions, the data model, anything at a system boundary. The rest is proven by behaviour, under test against the specification.
         
        // no black boxes
        There is no part of your system I can't sit down and explain to you. That's a different claim from having typed it, it's a harder one to meet, and it's the entire difference between the two failures above.
         
        // accountability
        The contract has my name on it. "The tool wrote that part" is not a defence available to me, so I don't build as if it were.
      

how to test this

Don't take my word for any of it

The claims on this page are deliberately the kind you can check rather than the kind you have to trust. Point at any component of what I build and ask me why it's shaped that way, what happens when it fails, and who is allowed to call it. If I can't answer that fluently, the method isn't what I said it was — and you should walk.

22years building
production software

1engagement
at a time

0parts of your system
I can't explain to you

get in touch

Test the claim

Send me what you're trying to build — a paragraph is enough — and any quote you're already holding. You'll get a straight answer within a week: how I'd approach it, whether I can do it better and roughly by how much, or that I'm the wrong person for it. Ask me hard questions about the method while you're at it.

$ mail --to quoteme@definitionofdone.dev $ see-the-commercial-terms