01Our approach

Clarity before complexity.

A practical route from a business problem to a web or ERP project that can be scoped, tested and handed over with care.

02The starting point

Start with the task, not the technology.

Before tools, screens or integrations are chosen, agree what someone needs to accomplish and what currently gets in the way.

The detail will differ between a content-led website, an online ordering flow, a portal or an ERP implementation. The discipline is the same: make the current state and the intended change understandable.

03A considered delivery path

Four stages. Clear decisions.

These stages guide the work. The scope, owners and dependencies are agreed for the engagement rather than treated as a template promise.

  1. 01

    Understand the work

    Map the customer or staff task, the people involved, the existing systems and the decisions that will shape the project.

  2. 02

    Define the way forward

    Set the deliverables, responsibilities, assumptions, access needs and criteria for checking the important journeys.

  3. 03

    Design, build and test

    Work in reviewable stages. Test the paths that matter, including error states and hand-offs to people or systems where they form part of the scope.

  4. 04

    Launch and hand over

    Confirm ownership, access, documentation and the next decisions. Any ongoing support or improvement work is defined explicitly.

WHAT WE NEED FROM YOUR TEAM

Good input prevents expensive guesses.

  • A person who can explain the current process and desired outcome
  • Access to relevant content, systems or documentation where it is safe to share
  • Named owners for decisions, approvals and final sign-off
  • Candour about constraints, exceptions and what must not break
WHAT YOU SHOULD EXPECT

A scope you can interrogate.

  • Plain-language deliverables and boundaries
  • Known assumptions and open questions
  • A practical plan for testing and handover
  • No universal promise about compatibility, timing or outcome before discovery
04A useful next move

Bring the uncertainty into the brief.

You do not need a finished specification to start. The most useful briefs identify the business task, current friction, systems involved and the decision that needs support.

Prepare a project brief
Working together

Process questions

Less jargon. More clarity. Here’s what you need to know before we start.

All your questions, answered
Can you work with an existing website or legacy system?
An existing platform can be reviewed as part of the brief. The first decision is usually whether to improve, replace, integrate around, or gradually retire part of the current setup. Access, documentation, data ownership and operational risk all affect that decision.
What affects the cost of a website or ERP project?
Scope affects cost. Typical decisions include content preparation, design, user roles, integrations, data cleanup or migration, approvals, testing, hosting, training and ongoing support. A useful estimate identifies what is included, what depends on discovery and what is deliberately out of scope.
How do we know whether we are ready for ERP?
Readiness is less about having every answer than being able to make decisions. You need a clear operational priority, people who can describe the current process, an owner for the work and enough access to understand the data involved. Our business readiness questions are a simple place to start.
How is information shared in an enquiry handled?
The current contact form prepares an email in your own email application; it does not send an enquiry automatically to a backend. Share only the information needed to describe the work. Read the privacy note for the current site behaviour and how the contact path works.