01 — Discover
We understand the goal, users, constraints and the real problem to solve.
Our process keeps decisions visible, work moving and the solution tied to your business goal.
We understand the goal, users, constraints and the real problem to solve.
We shape the scope, priority outcomes, timeline and practical success measures.
We create, test and refine the experience with regular checkpoints.
We prepare the handover, content, access and launch essentials.
We use performance, feedback and support priorities to keep moving forward.
Scope changes are agreed before additional work begins. Clients confirm they have rights to supplied content. Projects begin after agreement and deposit; proposals set the exact terms.
We begin by clarifying the problem, the people affected and the outcome you need. That discussion leads to a scoped proposal or a focused assessment when more information is required. Delivery then follows agreed milestones, client reviews and handover requirements, with ongoing support arranged separately where needed.
A useful brief records the business objective, intended users, current systems, constraints and the decisions that must be made. Existing documents, sample reports, website links and fault histories can help. We ask for enough information to define the work without expecting you to arrive with a complete technical specification.
Some requests are ready to quote immediately; others need a discovery phase to establish feasibility. The proposal should explain deliverables, exclusions, responsibilities, expected approvals and assumptions. Any licences, subscriptions, hardware or third-party services should be visible so the full cost is easier to understand.
During delivery, feedback is most useful when it refers to the agreed objective and comes through a nominated contact. For a website, this may mean reviewing structure and content before fine visual details. For software, it may mean testing a complete workflow. For infrastructure, it may involve agreeing the installation plan before work starts on site.
Changes are normal, but their effects need to be clear. A new feature or additional content can affect scope, cost and timing. We agree the change before treating it as part of the original commitment. This keeps the project understandable and prevents a sequence of small requests from quietly becoming a different assignment.
The completion review checks the agreed deliverables and the practical steps needed for use. That can include access, training, documentation, content approval and functional checks. The handover should identify what the client manages, what Mamba supports and which services remain with external providers.
Ongoing improvement is a separate conversation about evidence and priorities. A maintenance plan keeps agreed systems cared for; a marketing retainer delivers recurring growth activity; a software support agreement defines technical care and changes. Each should have its own scope rather than leaving support expectations to informal assumptions after launch.
A nominated decision-maker or small review group helps keep feedback consistent. They should be able to coordinate input from relevant staff and confirm decisions at the agreed checkpoints.
Missing content, unavailable access, unresolved decisions, new requirements and third-party dependencies can affect delivery. The project plan identifies known dependencies, while changes are reviewed for their impact on timing and cost.
Bring the goal, current problem, relevant systems or website, key users and any deadline or budget constraint. Examples of existing forms, reports or customer questions can make the discussion more concrete.