The engineering capability behind your next move.

One is fine, and common. The two lines exist to show what we do rather than to bundle it — an assessment, a single integration or one automated path are all real engagements. Where a second capability is genuinely needed we will say so and explain why, instead of quietly widening the scope.

Yes, and we start with a read rather than a rewrite: an assessment of the code, the infrastructure and the tests, with a plain account of what is sound and what is a liability. Inheriting a system honestly is cheaper for everyone than declaring it beyond saving.

Yes, provided the boundaries are written down — who owns which interface, and who is on call for what. Most friction between suppliers is an undefined boundary rather than bad intent, so we would rather define it in week one than discover it during an incident.

For a scoped first slice, often. For a year of discovery-shaped work, no: a fixed price on an unknown is a number that transfers risk to whoever is worse at estimating. We price the slice we can define, then re-price the next one with what the first taught us.

Discovery usually within a couple of weeks. Delivery depends on who the work actually needs — and we would rather give you an honest start date than assign whoever happens to be free, because that decision gets paid for later.

Whichever one addresses the constraint you can name. If you cannot name it yet, that is what a short discovery is for, and it is a smaller commitment than picking a capability and hoping it was the right one.