Brief / 01
Eight fields that make the request testable
Write a short answer for every field. Mark a field as undecided when the buyer has not agreed it. Do not let a provider fill an unknown with an assumed promise.
-
Role and seniority
Name one primary role and explain the decisions that require its stated seniority.
- Choose frontend, backend, full-stack, integration, QA, or another clear primary role.
- Describe the decisions the person will make, not only a number of years.
- Separate required skills from skills that are useful but optional.
-
System context
List the commerce edition, current version, custom modules, integrations, environments, and known constraints.
- Distinguish Magento Open Source from Adobe Commerce.
- Name only integrations the role will actually touch.
- Record known technical debt, release freezes, and unavailable documentation.
-
Duration and allocation
State the expected engagement period, weekly allocation, desired start window, and any planned pauses.
- Treat the start date and allocation as proposal items until a named person accepts them.
- State whether the load is stable, seasonal, or expected to change.
- Do not convert a sourcing estimate into a delivery deadline.
-
Decision ownership
Name who owns the backlog, architecture, code review, QA acceptance, release approval, and priority changes.
- Give each decision one accountable buyer or supplier role.
- Record where a developer may recommend a change but cannot approve it.
- Add an escalation owner for blocked decisions.
-
Access boundary
List the systems and data the developer needs, the least privilege for each, and who grants and removes access.
- Separate development, staging, production, cloud, repository, ticketing, and observability access.
- Use named accounts and approved devices where the buyer requires them.
- State what the person must never download, copy, or store locally.
-
Acceptance checks
Define the expected output, test evidence, review path, documentation, and meaning of done for the work.
- Link the task to an observable result such as a merged change, test, runbook, or reviewed design note.
- Name who reviews code and who accepts business behaviour.
- State how defects and rejected work return to the backlog.
-
Working hours and location
Record the proposed person's work country, local hours, required overlap, holiday calendar, and communication rhythm.
- Write overlap as local clock hours and identify the time zone.
- Confirm how daylight-saving changes affect the agreed window.
- Do not infer a person's location or hours from an agency office address.
-
Exit and handover
Set the required repository state, documentation, credential return, knowledge transfer, and final access review.
- Name the artifacts that must be current before the final day.
- Set a walkthrough owner and a buyer recipient.
- Link the exit step to the buyer's access revocation and secret rotation process.
Brief / 02
Write a work boundary, not a technology list
A technology name does not explain what the person may change, what remains buyer-owned, or how work will be accepted.
Weak request
Senior Magento developer needed
This does not identify the system problem, duration, decision rights, access, or acceptance path. Different sourcing routes can interpret it in incompatible ways.
Testable request
One backend engineer inside an existing release team
State the modules and integrations in scope, expected weekly allocation, buyer technical owner, code-review path, staging access, overlap window, and handover output.
Brief / 03
Assign an owner to every delivery decision
The provider label does not settle responsibility. Put the actual ownership model into the proposal and contract documents.
Decision ownership register
| Decision | Record | Check |
|---|---|---|
| Backlog and priority | Name the person who orders work and approves priority changes. | Confirm the developer has one route for conflicts. |
| Architecture | Name who approves design choices and technical risk. | Separate advice from final approval. |
| Code review | Name the repository reviewers and merge rule. | Confirm the proposed person can work within it. |
| QA acceptance | Name who checks technical and business behaviour. | Define the evidence attached to a completed task. |
| Release | Name who authorizes deployment and rollback. | Do not assume an embedded developer owns production release. |
| Access | Name who grants, reviews, and removes each privilege. | Connect the owner to onboarding and offboarding dates. |
Brief / 04
State what evidence will count
Company evidence and person evidence answer different questions. Keep both, but do not treat one as a substitute for the other.
- CompanyDelivery contextA relevant case can show that a provider has worked in a similar system. It does not prove the proposed person did that work.
- PersonRole evidenceUse a CV, interview, permitted work sample, credential check, and reference that can be tied to the named person.
- ProposalCurrent commitmentRecord identity, allocation, location, working hours, start conditions, substitution terms, and escalation support in writing.
- BuyerAcceptance recordKeep interview notes, verification results, decision owners, approved access, and unresolved questions with the sourcing decision.
Next field tool
Verify the person behind the brief
Use the named-developer checklist to test the CV, interview evidence, allocation, location, substitution rules, escalation support, and handover plan.