# Clear decisions. Reviewable progress. > How Webvelopment scopes, designs, builds and hands over digital work with clear ownership at every stage. Canonical page: https://webvelopment.co.za/about/our-process/ Language: en How we work A useful delivery process turns a business question into a scoped decision, reviewable work and an agreed handover. At each step, name the input, approver and evidence needed before moving forward. [Let’s talk](https://webvelopment.co.za/contact/) ## Understand the actual problem ![Two colleagues working side by side with laptops and notebooks.](https://webvelopment.co.za/images/lifestyle/pair-programming-1400.webp) Illustrative photography · [Christina @ wocintechchat.com M / Unsplash](https://unsplash.com/photos/two-women-using-macbook-pro-KzU0ezL9tJo) Bring us the outcome you need and an example of how things work today. That might be a customer trying to request a quote, or a staff member copying the same information between two tools. Content, account access, budget and timing help us judge what can be done. We start with that task before settling on features. If a conversation leaves important questions unanswered, we can define a discovery stage with specific outputs, such as a workflow map or prototype. Agree which decision that work will inform. ## Shape a scope people can use The scope sets out what we will deliver, what is excluded, our assumptions and what you or another supplier need to provide. It also names who can approve the work and who should check details such as service information or an integration requirement. Implementation costs are separated from third-party subscriptions, advertising spend, licences and ongoing support. Agree how you will check the result. For a website, that could mean completing an enquiry with representative information and checking what the receiving team gets. For a campaign, it could mean agreeing what counts as a qualified enquiry and how it will be reported. ## Make progress visible We show design and implementation in stages so you can respond while decisions are still practical to change. We explain decisions and note approved changes. Each review should make clear what is ready to check, what needs your input and what comes next. Gather feedback through one client decision-maker, including comments from content reviewers and system users. For example, explain that an enquiry needs a service location so your team can assign it. That tells us what the form needs to do. If a request changes the scope, we discuss its effect on cost, dependencies and timing before adding the work. ## Launch with a handover plan Before a live change, we agree who approves the release, who makes it, which checks are needed and how backup and recovery will work. Account for access held by your team or another supplier. The handover covers the access, documentation and training included in your scope. Agree who will handle everyday updates and where a problem should go after launch. Ongoing maintenance is a separate decision with explicit responsibilities. ## Improve with evidence Once the work is in use, customer behaviour and staff feedback can help choose the next improvement. For example, enquiries may reach the right inbox but lack information the sales team needs. Investigate that gap before proposing more features. We use reliable measurement where it is available. If the data cannot answer the question, we explain what is missing rather than drawing a confident conclusion from it. [Discuss your project](https://webvelopment.co.za/contact/) with an outline of the outcome you need. ## Use acceptance to connect the stages A realistic example can carry through the whole project. For an enquiry page, you might agree that a visitor must be able to choose a service, provide the details your team needs and understand what happens after submitting. Use that example to review the proposed design, test the build and check the release. Include an exception, such as a missing required detail, so the review covers more than the easiest route. Checking the same task helps expose different assumptions about what “finished” means. ## Agree a sign-off artifact for each stage A sign-off artifact is simply something concrete you can review before agreeing to the next step. Depending on the project, that could be: - A discovery summary explaining the options, recommendation and unanswered questions. - A scope listing the deliverables, exclusions, dependencies and how changes will be agreed. - A design or working demonstration reviewed with realistic content. - Test results for the agreed customer or staff tasks. - A release and handover checklist naming who approves, releases, recovers and operates the work. A retainer still needs these decisions; ongoing prioritisation does not replace clear approval or operating responsibilities. [Understand the team roles](https://webvelopment.co.za/about/our-team/) · [Explore technical discovery](https://webvelopment.co.za/solutions/technical-discovery/) · [Discuss the first approval decision](https://webvelopment.co.za/contact/). ## Questions for a better brief A few useful answers before you decide. ### What if we do not yet know the technical solution? Start with the decision you need to make. Discovery can help establish whether to adapt an existing tool, connect systems or build something new. Agree a useful first output, such as a prototype, workflow map or codebase review, and how you will assess it before estimating production work that depends on the answer. ### How are changes to scope handled? We explain what the new request changes before carrying out additional work. That may affect deliverables, dependencies, reviews, cost or timing. We also distinguish a defect from a new request: an agreed field failing to save is different from asking for an extra approval step. You can then decide whether to include the change or leave it for later. ### What should reviewers look at during a demonstration? Try the agreed tasks with representative content. Check that the intended person can complete them, the facts are correct and the receiving system or team gets what it needs. Bring visual feedback too, explaining how it affects the task. ### Who approves a release? The agreement should name the person giving business approval and the person authorised to make the live change. Necessary accounts, backups and recovery steps should be ready first, including anything another supplier controls. Approving a demonstration does not automatically give permission to deploy it. ### What happens when a dependency is delayed? We identify the missing input, who needs to provide it and which work it affects. For example, a delayed content approval may allow layout work to continue while preventing final page checks. We then agree whether to continue, change the sequence or revise the plan, and explain the impact. ### How do you use information after launch? We compare observed behaviour with the original objective and use sales feedback, operational issues and reliable measurement to identify the next decision. Incomplete data may call for better measurement before more development. Launch confirms a delivery milestone; it does not establish a guaranteed commercial outcome. Let’s move things forward ## Start a conversation Tell us what you are working towards. We’ll help you find a practical next step. [Let’s talk](https://webvelopment.co.za/contact/)