Start with the task someone must complete.
A booking form, an app and an internal tool each need a clear account of who is using them and what should happen. We use that to define the build.
Show how it works today
Send the existing website, a sketch or an example of a repeated task. Include the software involved and where information has to move. You can describe the problem without having a technical specification ready.
Decide what the first version needs
We work through the screens, information and actions needed for the task. Existing software may cover part of it. An integration may depend on access or features in another provider's account.
We use those details to define the scope before quoting. Features for later versions stay outside the initial build unless they are included in that scope.
Agree the scope and price
The scope describes the agreed build and the connections included. Website builds have a fixed price agreed at scoping. Apps and custom tools need a project-specific quote. Timing also depends on the project and its dependencies.
Questions to settle before starting
Who owns the accounts and code?
Include account access, source code and handover requirements in the scope. Raise any ownership or licensing requirement at the start so it can be addressed in the project agreement.
What happens after launch?
Tell us what updates or ongoing support you expect after launch so we can include that work in the scope.
What if the requirements change?
A change in screens, behavior or integrations may change the work. We discuss the revised scope before adding it to the build.
Tell us what you need built
Who will use it? What should they be able to do? Include a link to anything that exists and any deadline the project needs to meet.