Business problem
What needs to change, and who is affected?
For decision-makers
Know what you're commissioning.
The most useful project discussions are grounded in the work, the people and the systems already in place. This page explains what to bring, and what you should expect to clarify.
The first brief
Six things worth knowing before a call.
Nothing here needs to be perfect. Even partial answers help distinguish a small integration from a larger software project.
Current environment
Which software, forms and systems are already in use?
Volume and exceptions
How often does the task happen? What unusual cases matter?
Ownership
Who approves decisions, owns data and handles failures?
Constraints
Any security, access, legal or procurement requirements to consider?
Success measures
What would make the work demonstrably better?
A proposal worth reading
Look beyond the headline price.
A sound proposal should make the boundaries legible: what is included, what depends on third parties, what will be tested and who is responsible for decisions.
For business automation in particular, consider exception handling, access to source systems, data quality, the ownership of accounts and what happens if an integration changes.
Where a measurable outcome matters, agree how it will be assessed before comparing it with the original process. Less manual work is not automatically the same as a cash saving.
Common questions
Answers before the first engagement.
Can we start without a formal specification?
Yes. A useful initial description covers the process, pain points and relevant systems. Requirements can be clarified before a proposal is made.
Will you estimate a project before reviewing our systems?
A meaningful estimate depends on scope, integrations, constraints and access. Early figures are indicative until the requirements are agreed.
How do you handle security-sensitive work?
Security and data access requirements are assessed during scoping. Credentials should not be sent through the public enquiry form. Any specific controls or contractual obligations must be agreed before access is provided.
Can we keep ownership of our systems and accounts?
Ownership of accounts, deliverables, source code and support responsibilities should be explicit in a written agreement.
What if the project is not a fit?
We would rather identify a mismatch early than recommend a system the business does not need or we cannot responsibly deliver.
Ready to begin?
Send a project brief ↗Start with a clear problem.
Tell us what happens today, and what you would like to work differently.