Delivery
Why we write the scope before we staff the room
A team without a written outcome will fill the calendar anyway. That looks like progress and usually is not. We spend the first days on the decision the software has to support, the systems around it, and what is explicitly out of scope. Only then do we name who will do the work.
If we cannot write that letter, we should not hire the room. Buyers who skip this step typically pay for it in change orders and a product that matches last week’s meeting, not the business.
Ownership
What “you own the IP” should actually include
Ownership is not a sentence in a pitch deck. At handover you should have: repositories with history, infrastructure in your cloud accounts, secrets you can rotate, and a release path a new engineer can follow. If a vendor keeps the only working copy, you do not own the software.
Ask where the code lives on day one, not at the last invoice. Probens writes this into the engagement letter.
Product
When applied AI is a feature — and when it is a distraction
A model is useful when it changes a decision or removes a step someone already hates. It is a distraction when it sits beside a workflow that is still broken: missing permissions, no source of truth, or a UI no one can finish a task in.
We will recommend search, extraction, or a copilot when the data and the job are clear. We will recommend fixing the system of record first when they are not. That is not ideology. It is how you avoid paying twice.
Probens