A simple workflow sketch
A rough diagram showing roles, handoffs, decisions, and systems is more useful than polished mockups that hide the operating problem.
Project brief / verified delivery
You do not need a finished specification. Describe the operating problem, the people affected, the systems involved, and the decision you need to make. Do not email credentials, personal information, production data, or other sensitive material.
What work is delayed, duplicated, hard to see, hard to control, or dependent on one person's memory? What happens today when the process fails?
Who requests, approves, performs, supports, and audits the work? Where does responsibility change? Which users are internal, external, or partner-side?
List the relevant software, spreadsheets, documents, APIs, identity providers, vendors, and system owners. Note access limitations without sending access details.
Describe categories of information, not real records. Identify the people who can approve privacy, security, retention, data-location, accessibility, procurement, tax, and contract decisions.
What should become faster, safer, more visible, or easier to maintain? Include deadline drivers, working languages, participant time zones, procurement steps, budget boundary if known, and required ownership at handoff.
A rough diagram showing roles, handoffs, decisions, and systems is more useful than polished mockups that hide the operating problem.
Do not send passwords, tokens, private keys, customer records, health or financial data, production exports, or confidential contracts in the first inquiry.
The first step is to confirm that the work is a good fit and identify the information needed for a useful scope.
Schedule and price depend on the current system, integrations, security and data needs, and the result you expect. We will not invent those details just to produce a fast number.
Ready when the boundary is visible