Engagement / Commercial and operational terms
A direct, visible engagement from the first investigation to production.
The right commercial structure depends on how much is already known. A defined implementation can be delivered as a project. Work inside an existing system or uncertain process is usually safer on a time-and-materials basis until the real boundary becomes visible.
Engagement formats
Consultation and investigation
Hourly consulting is appropriate for workflow analysis, architecture review, production failure analysis, integration design, feasibility and scope definition. Substantial research or written design becomes a paid discovery engagement.
Defined project
A project model fits understood deliverables and acceptance criteria. The proposal defines scope, exclusions, milestones, responsibilities, payment schedule, assumptions and change process.
Ongoing engineering
Hourly or monthly capacity fits iterative improvements, maintenance, support and small changes. Capacity is agreed in advance; it is limited, and does not imply unlimited or on-call support.
Entry offer / bounded paid engagement
Operational System Review
A responsible first phase for a manual, fragile or unclear operational system. The review makes the current boundary, failure modes and safest first production scope visible before implementation begins.
Likely outputs
- Current workflow and system map
- Ownership and system-boundary analysis
- Failure modes, hidden dependencies and exception paths
- Recommended first production scope and architecture direction
- Assumptions, deliberate exclusions and a build / postpone / simplify recommendation
Process
- Initial written context
- Focused technical and operational review
- Existing-system and workflow analysis
- Findings, review session and implementation decision
The exact outputs depend on the system being reviewed. You retain the written output, whether or not we continue into implementation.
Progress and communication
- Meaningful progress at least twice each week.
- Material blockers and risks are communicated when discovered.
- Decisions, assumptions and scope changes are written down.
- Meetings resolve ambiguity; they do not substitute for visible work.
Timing and capacity
Bounded implementation work is normally planned in phases measured in weeks. The timeline depends on access, external providers, client decisions and uncertainty discovered during implementation.
I work with a limited number of clients at a time. Capacity and the earliest realistic start date are confirmed before a proposal is accepted.
Ownership and continuity
Bespoke source code and project-specific deliverables become the client’s property after the related invoices have been paid in full.
Pre-existing tools, reusable components, general engineering methods and know-how remain mine. Where a pre-existing component is included, the client receives the rights required to operate, maintain and modify the system. Open-source and third-party components remain under their original licences. The final contract controls the precise terms.
Source code normally lives in the client’s repository and production infrastructure in client-controlled accounts where practical.
Architecture decisions, deployment and recovery instructions, known limitations and handover items are documented where the system requires them.
Scope stays within what one accountable engineer can responsibly deliver. A broader team is recommended when the work needs one.
Business and security
Engagements begin with a written agreement or proposal covering scope, exclusions, payment model and responsibilities. Contracting and invoicing identity are disclosed before work begins.
I can sign a reasonable mutual NDA. When I process personal data, I can enter into an appropriate DPA after systems, subprocessors, data locations and security obligations are understood.
- Least-privilege access and separate development and production credentials.
- No secrets in source control; use the client’s approved secret management where available.
- Rotate or remove access at the end of the engagement.
- Minimise locally stored client data and use synthetic or redacted data where practical.
- External AI use with client material requires explicit approval and data minimisation.
When software is not the right answer
If an existing product, a simpler integration or a process change solves the problem more safely, I will say so. The initial investigation is also about determining whether custom software is justified at all.
Commercial transparency FAQ
Do you charge hourly or per project?
Both are possible. Uncertain investigation is usually hourly or time-and-materials; bounded implementation can use project or milestone pricing.
Do you publish a fixed rate?
No public rate is shown. The written proposal sets the agreed commercial model and scope.
How often will we see progress?
At least twice each week through a written update, demonstration, pull request, deployment or decision record.
Who owns the source code?
The client owns bespoke project deliverables after related invoices are paid in full. Pre-existing reusable materials remain mine, with operating and maintenance rights for included components.
Can you work in our existing repository?
Yes. A client-controlled repository is the normal default.
Can you sign an NDA or DPA?
I can sign a reasonable mutual NDA and an appropriate DPA when the work makes me a processor of personal data.
What happens after launch?
Handover items and any stabilization period are defined in the proposal. Ongoing maintenance, response times and on-call support are separate unless explicitly included.
What happens if scope changes?
Material changes are written down and approved before implementation proceeds under the changed boundary.
Are you available full-time?
I work with a limited number of clients. Capacity and the earliest realistic start date are confirmed before a proposal is accepted.
What if the project needs more than one engineer?
I will say so. Scope stays within what one accountable engineer can responsibly deliver, and a broader team should be involved when the work clearly requires it.
Start with the system as it exists
Bring the messy version.
Send the current process, the systems involved and one example of where it breaks.
Email Serhii ↗