The work
The quote sets the deliverables, exclusions, success criteria, schedule and responsibilities. It identifies assumptions, dependencies and what you need to provide.
Pricing & Working Together
A clear scope.
A useful result.
A price you agree.
Commission a defined project—not an open-ended promise about AI.
Tell us what you want to make possible and what you already use. We’ll compare the sensible options and agree the work before building.
Discuss your project ↗You don’t need a technical brief.
How pricing works
No standard price list. A quote for the work you actually need.
A connection between two supported tools is a different project from a customer-facing application or a physical prototype. We quote after reviewing the intended result, existing tools or files, access and the difficult cases—not from a generic package name.
The commercial terms
The quote sets the fee or charging basis, payment schedule and how scope changes are agreed. If investigation is needed before a reliable build quote, its scope and fee are agreed first.
The running costs
Hosting, model usage, software licences, fabrication, materials and specialist work can sit outside the build fee. The quote identifies included and separate costs, who pays them and any estimates that depend on usage.
A project discussion does not commit you to a build. No paid investigation, subscription or additional work starts without agreement.
Find your starting point
What would you like to buy?
What changes the quote
Price follows complexity and responsibility.
A more focused scope
- One defined job, user group or design question.
- Usable source files and supported system access.
- Known rules and a representative test set.
- A clear owner for decisions and operation.
A wider scope
- Several roles, processes or connected systems.
- Data cleanup, migration or incomplete CAD.
- More exceptions, permissions or reliability requirements.
- Physical builds, specialist review or ongoing operation.
To make a project more affordable, narrow the first release to a complete useful job—not an unfinished slice of every feature. We can separate later work in the proposal rather than hiding it inside a vague estimate.
From question to handover
Know what happens next.
Bring the result you want.
Describe the work, who uses it, the tools or files involved, and any timing or budget constraints. Start with a description; don’t send credentials or sensitive company records through the enquiry form.
Choose the approach and scope.
Compare configuration, an existing product, integration and custom work. Where uncertainty needs investigation, agree a separate assessment before committing to implementation.
Build and test against the agreed job.
Review the work against the written success criteria, including exceptions and limits. A requested change is discussed with its scope, cost and timing implications before it is added.
Hand over with an operating plan.
Review the agreed files, documentation, access and outstanding issues. Establish who operates the result and what support, if any, is included or separately arranged.
Before you commit
The questions worth settling.
Should we buy software instead of commissioning it?
Often, yes. If an existing product handles the essential job, configuration or vendor onboarding may be the better purchase. Custom work makes sense when a necessary workflow, experience or connection still does not fit. Read the build-versus-buy guide ↗
Can we keep our current tools?
That is the starting point where they work well. We check supported connectors, APIs, subscription tiers, permissions and export options before promising an integration. If access is unavailable, we explain the constraint and compare alternatives rather than assuming every platform can be connected.
What will we own and receive?
The proposal sets ownership and usage rights for custom work, access to source or design files, data exports and the handover materials. Third-party software, models, libraries and purchased components retain their own licences. Do not assume that commissioning a build transfers rights to every dependency; these terms are settled before work begins.
What happens after handover?
The quote defines any included support, its boundaries and duration, and who handles issues after launch. Ongoing maintenance, monitoring or new development is scoped separately where needed. We agree responsibility for hosting, subscriptions, backups, source updates and connection changes; there is no implied unlimited support or response-time guarantee.
How long does a project take?
The schedule follows the agreed scope and depends on access, feedback, third-party services and any fabrication or test work. The proposal records those dependencies. A smaller, complete first release can reduce uncertainty without promising the same delivery time for every project.
How do we know the project is finished?
Define the test before the build: a user completes the agreed workflow, records reconcile correctly, answers have the right sources, or a design question has documented findings. The quote sets the review process and how unresolved issues are handled. A successful demonstration is not proof of every possible case, and a prototype test is not certification.
Tell us what you want to make possible.
A business goal, an existing workflow or a product sketch is enough to start the conversation. Bring your constraints; you don’t need to arrive with the solution.