Pricing follows the shape of the work, the decisions still open, and how much continuity you need after release.
No single model fits every product state. Compare the boundary, continuity, and decisions each model requires.
For a defined outcome with agreed scope, review points, and a release boundary.
For a requirement that needs product, UX, architecture, or scope definition before build.
For an existing product or active roadmap that needs continued development and technical continuity.
Start with what exists and what must be decided. Then choose the structure that matches the next boundary.
A new requirement or bounded product slice. Start with Focused Product Definition when decisions remain open; use a Defined Project when the scope is ready to agree.
An existing product, codebase, or workflow. Define the current state first, then choose a contained project or a continuing workstream.
An active roadmap with ongoing responsibility. Ongoing Product Engineering fits when product areas, review cadence, and the next boundary are explicit.
The estimate depends on the work underneath the label. We look at scope, existing context, dependencies, pace, and responsibility before proposing a commercial structure.
Workflows, user roles, surfaces, and the product's current state shape the engineering footprint and the decisions still open.
Codebase condition, APIs, providers, data movement, and legacy dependencies add coordination, error handling, and verification work.
Review cadence, parallel work, release requirements, and whether the next boundary is handoff or continued development affect the commercial structure.
Questions about estimates, model fit, scope changes, and the details a proposal should make explicit.
We need the intended outcome, current product or materials, users and workflows, integrations, constraints, and the delivery boundary you have in mind. The more of that context is available, the more useful the commercial conversation can be.
