01 / Choose the first process
Pick work that happens often enough to matter.
The first job should be narrow, repeatable and easy for the people doing it to explain. It should end with a useful record, approval or document that your team can check.
Information moves between familiar people, forms, emails, spreadsheets or folders on similar jobs.
There are current dockets, photographs, reports or records that show what goes in and what must come out.
There is no stable process to build around, or the real problem is unclear ownership rather than missing software.
Safety, legal, accounting and professional judgement must remain with the qualified people responsible for them.
A useful first sentence
“After every visit, our engineer’s docket and photographs are re-typed into a customer report.”02 / Before anything is built
Bring the current work, not a technical specification.
You do not need to design the software. I need to understand how the job is done now, who handles it and what a correct result looks like.
Forms, reports, emails, spreadsheets or screenshots, with confidential information removed where appropriate.
Who records the work, who checks it, who needs the result and which existing systems must remain.
The first build, its boundaries and a realistic delivery timeframe are set out before work begins.
The agreed process is tested with representative examples and reviewed by the people who will use its output.
03 / How the work runs
Four steps from first conversation to approval.
The 15-minute conversation is not a commitment to a project. It is a quick review of one process to see whether it is suitable for a small first build.
Talk through one repeated process
Explain where the information starts, where it is copied or chased and what useful result is needed.
Review real examples and requirements
I review representative documents, users, approvals, existing systems and any access requirements.
Agree the scope, quote and timeframe
You receive the proposed boundaries in writing before deciding whether to proceed.
Build, test and approve the first version
We test the software with agreed examples. It does not go live until your team has checked the output.
04 / Clear commercial boundaries
Fixed scope means the edges are written down.
The quote is for the agreed first process. If a requested change sits outside those boundaries, I flag it before doing extra work.
The scope names the users, current examples, main steps and output included in the first version.
It states how the first version will be checked and who inside your business can approve it.
The first build does not quietly become a new job-management, accounting or business-wide system.
More sites, users, forms, document types, integrations or ongoing support are discussed separately when needed.
05 / After the first version
Keep it narrow, or expand with evidence.
The first process should stand on its own. Wider work is a separate decision, based on what your team learned from using and checking the first version.
- Check whether the people doing the work can use it without unnecessary steps.
- Check whether the agreed record, approval or document is produced reliably.
- Compare the repeated handling before and after the change.
- Keep the process as it is if the result is useful and complete.
- Quote any wider rollout or separate process only when there is a clear reason to add it.
See a process first
Try the fictional job-record example.
Add one record and see its notes and attachments move into a searchable job list.
Try the examplePrepare your example
Use the free job-record template.
Map the fields, attachments, hand-offs and final output in one repeated piece of work.
Open the template06 / Questions
Before you agree to a conversation.
Is the 15-minute call the paid pilot?
No. It is an initial conversation about one repeated process. Any paid work starts only after you receive and accept a written scope, fixed quote and delivery timeframe.
Do we have to replace our current software?
No. Existing Microsoft, Google, field-service or accounting systems may remain in place. If a simpler change to your current process or software is enough, custom work may not be the right answer.
How much will it cost and how long will it take?
That depends on the process, required access, users and output. I review those details first, then provide the fixed quote and realistic timeframe in writing before work begins.
Will software approve safety or professional decisions?
No. Software may organise information and prepare records, but the responsible people in your business remain in control of safety, legal, accounting and professional judgement.
Who will I deal with?
Emmet Delaney. I review the process, quote the work and build it. You are not handed between a salesperson and a separate delivery team.
This page describes the Delaney Works process in general. The exact scope, cost, timeframe, technical approach, support and handover arrangements depend on the process reviewed and are agreed in writing before paid work begins.