Skip to main content
Xalicon

How we work

A delivery method we can explain in detail

Eight stages, adapted per engagement. Each produces something you can review rather than a status update — which is what makes progress verifiable instead of asserted.

Operating principles

Four things that hold across every engagement

  • Fixed cadence, flexible scope

    Dates and budgets are held steady; scope is managed against them with a visible priority order. Adding something means deferring something else, and you see that trade-off in writing before it is made.

  • One team, shared standards

    Our engineers work inside your repository, review process and definition of done. Where you do not have those yet, we establish them with you rather than imposing ours.

  • Demonstrated progress

    Weekly demos of working software in a real environment. Written sprint summaries record what shipped, what slipped and what changed.

  • Escalation without drama

    Risks are raised as soon as they are identified, with options attached. A surprise at the end of a project is a process failure, not bad luck.

The process

Discovery to continuous support

Not every engagement uses all eight stages. Where one is skipped, we say why.

Discovery

We start by understanding the business outcome, the users and the constraints. Short, focused and always ending in a written brief you can act on — including where we disagree with the original framing.

Outputs

  • Problem statement
  • Success measures
  • Constraints and risks

Product strategy

Scope shaped around outcomes rather than a feature list. We sequence work so the riskiest assumptions are tested first and the first release is small enough to actually ship.

Outputs

  • Scoped release plan
  • Prioritised backlog
  • Deferral list

UX design

Information architecture, journeys and interface design produced as a reusable system. Prototypes are validated with real users before engineering time is committed.

Outputs

  • Journey maps
  • Prototypes
  • Design system

Architecture

Data model, service boundaries, integration points and non-functional requirements agreed and written down, with the reasoning recorded so future teams understand the trade-offs.

Outputs

  • Architecture document
  • Decision records
  • Environment plan

Agile engineering

Two-week cycles ending in working software in a real environment. Weekly demos, a visible backlog and no status that only exists in a slide.

Outputs

  • Working increments
  • Demo recordings
  • Sprint reports

Quality assurance

Automated tests at the right layers, accessibility and performance checks in the pipeline, and exploratory testing on critical journeys before every release.

Outputs

  • Test suites
  • Quality reports
  • Release readiness criteria

Deployment

Staged rollout through automated pipelines with monitoring in place before traffic arrives, and a rollback that takes one action.

Outputs

  • Release plan
  • Runbooks
  • Monitoring and alerts

Continuous support

Post-launch monitoring, incident response, dependency upkeep and a steady flow of improvements — or a structured handover to your team.

Outputs

  • Support agreement
  • Monthly reporting
  • Improvement backlog

Delivery cadence

What a typical two weeks looks like

  1. Planning

    Sprint scope agreed against the prioritised backlog, with estimates and known risks written down.

  2. Build

    Daily standups, continuous integration, pull requests reviewed within a working day.

  3. Demo

    Working software in a real environment, reviewed with you at the end of each week.

  4. Retrospective

    What slowed us down and what we change next sprint. Actions tracked, not just noted.

Engagement models

How teams are structured

  • Dedicated Developers

    A team that needs specific skills and already has engineering management in place.

    Individual engineers who join your team full time, work in your repository and your process, and report to your leads. You direct the work day to day.

    Managed by
    You
    Commitment
    Monthly, typically three months minimum
    Read more about Dedicated Developers
  • Team Extension

    Scaling an existing team quickly while keeping product direction fully in-house.

    A group of engineers integrated into your existing team structure. Your leads set priorities and run the process; we handle recruitment, retention, performance and continuity.

    Managed by
    You, with our engineering support behind the team
    Commitment
    Monthly, typically three months minimum
    Read more about Team Extension
  • Managed Delivery Pods

    Owning an outcome end to end when you do not have management capacity to spare.

    A cross-functional pod — engineers, QA, design and a delivery lead — that takes a defined scope and runs it. You set priorities and review outcomes; we run the delivery.

    Managed by
    Xalicon
    Commitment
    Quarterly, aligned to a defined scope
    Read more about Managed Delivery Pods
  • Offshore Development Centre

    Building a durable long-term engineering capability outside your home market.

    A dedicated long-term team operating as your extended engineering function, with its own hiring plan, career development and delivery structure aligned to your organisation.

    Managed by
    Shared governance between your leadership and ours
    Commitment
    Annual, with a defined growth plan
    Read more about Offshore Development Centre

Questions

Questions about how we deliver

Discovery and foundation. We agree the problem, the success measures and the constraints, then set up the repository, environments, pipeline and a deployed skeleton. You have something running in a real environment before any feature work begins.

Start a conversation

See the process on a real project

Start with a discovery conversation. You will leave with a written problem statement and an approach, whether or not you engage us.

Prefer email? contact@xalicon.co