FAQ
The useful questions change with the product state, so start with the answer closest to the work you are considering.
Begin with the context
that shapes the next decision.
What to share before an enquiry, and how we decide whether the next step is discussion, definition, or delivery.
Share the current product state, who the software is for, what needs to change, what already exists, and any known timing, budget, access, procurement, or technical constraints. A short message is enough to identify the useful next conversation.
Start with what exists
before choosing the change.
Questions about inherited products, current codebases, transitions, and focused improvements.
Yes, when the current product, codebase, users, architecture, dependencies, access, and next useful change can be understood before commitment.
Make the commercial shape
match the work underneath.
How scope, uncertainty, and product state affect the engagement model and the usefulness of an estimate.
The charging model should match the work: a Defined Project, Focused Product Definition, Ongoing Product Engineering, or approved dedicated product capacity. Cost is affected by workflow depth, product condition, interfaces, integrations, data, quality and release responsibility, timing, and uncertainty.
Make ownership and access
explicit before delivery.
Questions about repositories, assets, intellectual property, and what a responsible handoff includes.
The authoritative answer comes from the approved contract. The applicable transfer point and rights should be confirmed for the specific engagement rather than assumed from general website language.
Resolve access and data
responsibilities early.
Questions about security, privacy, confidentiality, onboarding, and procurement requirements.
Security responsibility is scoped to the product, data, access boundaries, and delivery requirements agreed for each engagement.
Plan around the reasons
a schedule can change.
How product scope, dependencies, decisions, and release boundaries affect timing.
There is no approved universal timeline. Timing depends on product scope, current state, interfaces, integrations, technical risk, quality and release responsibility, decision speed, dependencies, and team model.
Define the working boundary
with your existing team.
How responsibilities, tools, and capacity are agreed when Craftnotion works alongside an internal team.
Yes, when the engagement defines product ownership, technical standards, repositories, review responsibilities, communication paths, release authority, and the product area Craftnotion owns.
Choose what happens next
after the first release.
How handoff, support, improvements, and ongoing product engineering differ after release.
The next step may be an intentional handoff, a focused improvement phase, approved support responsibility, or Ongoing Product Engineering for a continuing roadmap. The engagement should state which applies.
