Most software disappointment is not about the build. It is about the six months afterwards, when something breaks and nobody is sure whose job it is.
Triage by impact, not by who shouted
A reasonable support arrangement separates "the site is down" from "this label is wrong" and treats them differently. Everything urgent means nothing is. Agree upfront what counts as critical — usually anything blocking revenue or leaving data at risk — and what can wait for the next scheduled change.
A route in that is not one person's phone
If support depends on catching a particular developer, you do not have support, you have a favour. There should be an address that reaches more than one person and a record of what was reported, because the second time a problem happens the history is the fastest route to the cause.
Honest status over reassuring status
"Looking into it" for three days is worse than "we have reproduced it, we do not yet know the cause, next update Thursday". You cannot plan around optimism. Ask what the update cadence is when something is open.
Fixes at the cause, not the symptom
A bug patched where it was noticed will reappear somewhere else. It costs a little more to find why it happened and fix it there — and it is the difference between a system that gets more stable over time and one that accumulates patches until nobody wants to touch it.
Knowing where the boundary is
Plenty of "the website is broken" turns out to be an expired domain, a DNS change, a payment gateway outage or a full mailbox. Good support tells you that clearly and helps anyway where it can, rather than closing the ticket as out of scope.
What we do
Because we manage the servers as well as the applications, most of those boundary cases fall inside one conversation rather than between two suppliers. We would rather explain what actually happened than send a status page link.
If something is broken now, tell us what you are seeing — screenshots and the time it happened are usually enough to start.