Frequently asked questions.
A few useful details about how we work together. If something important is missing, start a conversation and we will give you a direct answer.
What kinds of organisations are a good fit?
We work with ambitious teams whose important customer or operational work is being held back by unclear processes, disconnected tools, or difficult digital journeys. We are especially useful when product, operations, and technology stakeholders need to get aligned around a practical next step.
What does a typical engagement look like?
Most engagements move through discovery, definition, design, and delivery. The exact mix depends on the question: some teams begin with a short discovery; others already have clear evidence and need design or engineering. We agree the scope and decision points before work begins.
Can you work alongside our internal team?
Yes. We regularly collaborate with internal product, engineering, operations, and leadership teams. We make working decisions visible, share artefacts in agreed tools, and adapt to existing review and delivery rhythms rather than introducing process for its own sake.
How do you approach accessibility?
Accessibility is considered from research and structure through interface design and implementation. We use semantic patterns, keyboard testing, readable contrast, clear focus states, and assistive-technology checks appropriate to the product. We agree any required standards and verification approach with you at the start.
Who owns the design and software you create?
Ownership, licence, and any third-party components are stated in the project agreement. After payment for agreed work, clients generally receive the project-specific deliverables described in their agreement. Existing studio tools and third-party software remain subject to their own terms.
Can you connect to our existing systems?
We can assess and design integrations with your existing products, subject to their APIs, permissions, technical constraints, and operating costs. Integration feasibility is discussed early; we do not assume that every system can or should be connected.
Do you provide ongoing support after launch?
We can agree a support or product-evolution arrangement for a project. This may include issue triage, maintenance planning, training, or a further improvement phase. The scope, response expectations, and fees are set out in a separate written agreement.
How do you handle security discussions?
We discuss data flows, roles, access, hosting, and relevant security expectations during discovery and technical planning. Specific controls depend on the product and infrastructure. We document assumptions and recommend specialist review where a client requirement calls for it.
How long does a project take?
Timing depends on scope, available decision-makers, integrations, content, and the pace at which feedback can be reviewed. A focused discovery can take a few weeks; a custom software programme can take several months. We provide a phased estimate after understanding the work.
How should we think about budget?
We discuss budget early so the scope can be shaped responsibly. An initial conversation helps us understand constraints; a written proposal then explains the phases, assumptions, fees, and payment schedule. If the full ambition is not feasible now, we will identify a smaller useful first step.
What if we are not sure what we need yet?
That is a reasonable place to begin. Share what is getting harder, who is affected, and any constraints you know about. We can help determine whether a short discovery, an existing tool, or a more substantial design and software effort makes sense.