What we can tell in a thirty minute call

The first conversation is thirty minutes and costs nothing. That is not a discount — it is that half an hour is usually enough to know whether there is a project here, and neither of us benefits from finding out slowly.

What we ask about

Not requirements. Process. Who does the work today, what they do when it goes wrong, and how often that happens. Requirements are what people have already decided they want; process is where the problem actually lives, and the two frequently disagree.

What we can usually establish

Whether the problem is software at all. A surprising share of what arrives as a build request is a process nobody has changed because changing it is awkward. Software makes that permanent and expensive.

Whether it can be scoped fixed. Some work can honestly be fixed-price; some cannot, and pretending otherwise produces a change request in month two. We say which at the start rather than discovering it later.

Roughly what it is worth. Not a quote. Whether the cost of the problem is plausibly larger than the cost of solving it — because if it is not, everything after that is wasted effort.

Why we sometimes say wait

Because the data is not ready, or the process is about to change anyway, or the thing you need exists off the shelf for a fraction of a build. Saying so early is cheaper for you and better for us than a project that disappoints.

What happens after

If there is something worth doing, you get a written view of what we would do, in what order, and which parts we would fix and which we would not. If there is not, you get that in writing too, with what we would do instead.

Either way you are talking to an engineer who could build the thing, not to someone relaying it to one later.