HOW WE WORK TOGETHER
A clear way to start. An agreement that fits the work.
Choose a starting model based on how well the requirement is understood. Scope, commercials and responsibilities are confirmed in a written proposal; this page is an explanation, not a binding offer.
01 — Discovery & pilot
Best when the process, feasibility or integration is not yet clear. Agree a bounded assessment or proof of concept, sample data, questions to answer and an output such as a process map, recommendation or demonstrator. A pilot is not automatically a production system.
02 — Fixed-scope project
Best when requirements and acceptance criteria are sufficiently defined. Agree deliverables, assumptions, dependencies, milestones and a project fee in writing. Requests outside that baseline follow an agreed change process; a fixed price does not mean unlimited changes.
03 — Time & materials
Best when priorities will evolve. Agree rates, roles, reporting, review points and a budget or approval limit. Work is billed on the agreed basis with visible progress and effort records. New budget authority is confirmed before exceeding an agreed limit.
04 — Ongoing support
Best for an existing Business Central environment, integration or application needing agreed support. Assess the system first, then define coverage, hours, included effort, exclusions, escalation and service targets. No 24/7 coverage or guaranteed response is implied by this website.
BEFORE WORK STARTS
What the project agreement should make clear
Scope and acceptance
Deliverables, what is excluded, acceptance scenarios, review periods and the process for resolving defects or requesting changes.
Fees and third-party costs
The charging model, milestones, payment terms, taxes where relevant, and responsibility for licences, hosting, connectors and model usage.
Access and responsibilities
Client contacts, required permissions, sample data, decisions, environment readiness and dependencies that affect delivery dates.
Source code and intellectual property
Ownership and access for custom work, pre-existing components, open-source or vendor licences, repository handover and any conditions on transfer.
Confidentiality and data handling
Permitted data, access controls, approved providers, confidentiality obligations, processor terms where applicable and secure transfer methods.
Release, warranty and support
Deployment responsibilities, backups and rollback, any agreed defect-remedy period, support coverage, exit and handover arrangements.
From conversation to handover
- Understand the requirement. Review one concrete problem, the people involved and the existing systems.
- Agree a proposal. Record the model, scope, assumptions, costs and acceptance criteria.
- Build and review. Share progress at agreed checkpoints and document changes.
- Validate and hand over. Complete acceptance checks and provide the agreed code, documentation and knowledge transfer.
Who owns the source code?
Ownership of custom work and access to source code must be agreed in writing. Third-party and pre-existing components may carry separate licences. Do not assume a website enquiry transfers intellectual property.
Can we start with something small?
Yes. A bounded discovery or pilot is often a useful first step before a larger implementation. Its price, duration and outputs are agreed after discussing the requirement.
Is this the Terms & Conditions page?
No. This page explains engagement options. A signed proposal, statement of work or other applicable agreement defines the actual obligations. It does not replace tailored legal terms.
START WITH A CONVERSATION
Bring one challenge.
Define the next step.
Share the process, systems involved and what a useful outcome would look like. We will assess scope, dependencies and the right starting engagement.
Tell us about your project ↗