The problem, in your own words
What is happening today that should not be, or what should be possible that currently is not. Business framing is more useful than technical framing at this stage.
Contacts
Everything starts with an email.
All details above are published as plain text. This site has no contact form.
01Writing about a project
Six things worth including.
None of these are mandatory. Even a short description of the problem is enough to decide whether a technical conversation makes sense.
Systems already in place
Applications, databases, hosting, spreadsheets or third-party services involved in the process, including anything that must keep working unchanged.
Constraints
Fixed deadlines, regulatory requirements, platforms you are committed to, internal skills that will maintain the result, or budget boundaries you already know.
Definition of success
How you will judge whether the work succeeded: a process that takes less time, data that reconciles, releases that stop breaking, a report that arrives automatically.
Who is involved
The roles that will use or maintain the software, and who makes the technical decisions on your side.
Material we can read
Existing documentation, screenshots, exports, API references or repository access if there is a codebase already. Nothing is required to start the conversation.
A clear description of the problem is the most useful thing you can send.