Delivery and support

Who does what

A project needs more than a list of deliverables. It needs people who can give context, make decisions and review the result. Whoever will use the system gets a say, even when someone else signs off.

At the start we agree the main contact, who approves what and how questions and changes are handled. How often we meet depends on the size of the work.

Review the actual journey

Feedback lands best when it follows the task. Do not judge one screen in isolation. Go from the first action to the result, then try it with information missing, an integration down or a customer who changes their mind.

Experience

Can the person it is for understand it and finish the task, on any screen size and with a keyboard?

Operation

Does the result reach the right person or system, with the access, the notifications and the details needed to sort out a problem?

Business context

Does the build still serve the offer and the way the business runs? A technical test cannot answer every commercial question.

Treat release as a decision

A release affects the people using it and every system it touches. What gets reviewed, what gets backed up and how we respond to a problem are decided for each project.

Those decisions sit in the scope. A prototype, an internal tool and a public customer app do not carry the same weight.

After launch

We stay reachable after launch and handle small adjustments as they come up. A live system can also need content changes, updates, monitoring or new development. Those are different jobs, and we name each one instead of hiding them inside the word support.

If you want us to keep running it for you, including the domain, hosting and upkeep, we set that up as its own agreement. It sets the contact, the covered work, the response you can expect and the cost of any tools or services that keep running.