The moment a site needs accounts, roles, records or a workflow, it stops being a website and becomes software. The two are quoted very differently, and conflating them is how projects go wrong.
What the work involves
Data model before screens
What the system stores and how those things relate. Get this wrong and every screen built on top of it is a workaround.
Users, roles and permissions
Who can see and do what, defined explicitly. Retrofitting an authorisation model into a live application is one of the most expensive corrections there is.
The workflow as it really runs
Including the exceptions, the approvals and the case your operations team handles by phone. Those are the requirements that surface in month three otherwise.
Audit trails
Who changed what and when. Boring until the first dispute, then the most valuable feature in the system.
Tested where it counts
Automated tests on the logic that would hurt if it silently broke: pricing, permissions, availability, payments.
Built to be handed over
Environments, deployment pipeline, documentation. You should be able to bring this in-house without a rescue project.
Questions we get asked
Can you build an MVP first?
Usually the right approach. We scope a first version that solves one real workflow end to end, ship it, then extend from evidence instead of from a wishlist.
Who owns the code?
You do, in your repository, from the first commit. There is no licensing arrangement and nothing we can withdraw.
Will it integrate with our existing systems?
That is usually the whole point. See API and integrations for how we de-risk that part first.
What about ongoing changes?
Applications are never finished. Most clients move onto a monthly arrangement after launch, covered under support and DevOps.
Tell us what it has to do
Send the requirement, however roughly it is written. You get back the questions we would need answered, the integrations we would test first, and a realistic range.