Skip to content
XSIS
Talk to an engineer

Teams

Project-based delivery

An agreed scope, delivered and accepted against written criteria

XSIS takes responsibility for a defined scope, with milestones, acceptance criteria and a named delivery lead.

Overview

With project-based delivery, XSIS takes responsibility for delivering an agreed scope. We plan the work, staff it, build it, test it and hand it over. You agree the scope and the acceptance criteria, make decisions when we need them, and accept the result.

It suits work with a clear outcome: a new application, an integration between defined systems, a migration, or a release of an existing product. When the scope is not yet clear, we start with a short discovery to make it clear before committing to it.

A named delivery lead answers for the project from start to finish. Progress, risks and decisions are reported in writing. Changes to scope go through change control, so the cost and the plan never move without your agreement.

What we deliver

  1. Written scope

    What is in the project and what is not, the systems involved, the assumptions made and the decisions still open.

  2. Acceptance criteria

    For each part of the scope, the tests and conditions that show it is done, agreed before the build starts.

  3. Delivery plan

    Milestones, dependencies on your teams and third parties, and the points where we need your decisions.

  4. A named delivery lead

    One person at XSIS who answers for the project, runs the team and is your first contact throughout.

  5. Change control

    A simple written process for changes: what changes, what it costs, what it moves, and who approved it.

  6. Progress reports

    Regular reports on progress against milestones, risks and their mitigations, and decisions needed from you.

  7. Tested, working software

    The delivered system, with automated tests, deployed to the environments agreed in the scope.

  8. Documentation

    Architecture notes, configuration, runbooks and user guides, so your team can run and change what we built.

  9. Handover

    A planned transfer to your team or to a support agreement, with walkthroughs and a period for questions.

How we work

  1. 01

    Discover

    We learn the goal, the users, the systems and the constraints, and test the riskiest assumptions early.

  2. 02

    Agree scope and acceptance

    We write the scope and the acceptance criteria with you, and you sign them off.

  3. 03

    Plan and staff

    We set milestones, name the delivery lead and assemble the team the scope needs.

  4. 04

    Build in increments

    We build and test in short cycles and demonstrate working software at each milestone.

  5. 05

    Test and accept

    You test the result against the agreed criteria, and we fix what does not meet them.

  6. 06

    Hand over

    We deploy, hand over documentation and knowledge, and move the system to your team or to support.

Technologies

Languages
  • TypeScript
  • Java
  • Python
Frameworks
  • React
  • Next.js
  • Node.js
  • .NET
Databases
  • PostgreSQL
Cloud
  • Amazon Web Services
  • Microsoft Azure
DevOps and observability
  • Docker
  • GitLab CI/CD
Testing
  • Playwright

Ways to work with us

Project-based delivery

XSIS delivers an agreed scope against written acceptance criteria, with a named delivery lead.

How it works

We agree a written scope and acceptance criteria with you before the build starts.

A named delivery lead plans, staffs and runs the project, and reports progress, risks and decisions.

You accept each milestone against the criteria. Changes go through change control.

When to choose it

The outcome can be described clearly: an application, an integration, a migration.

You want one company responsible for delivering it.

You need a known basis for the budget and the plan before you commit.

How it is governed

Milestones with demonstrations, accepted against written criteria.

Written change control for scope, cost and dates.

Steering meetings with your sponsor at agreed points.

Questions and answers

When is project-based delivery the right choice?

When the outcome can be described clearly and you want one company to be responsible for reaching it: a defined application, an integration, a migration. If your priorities will keep changing, or the work has no natural end, a dedicated team usually fits better.

Link to this question
How is the work accepted?

Against acceptance criteria we write and agree with you before the build starts. At each milestone we demonstrate the work and you test it against those criteria. If something does not meet them, we fix it. When everything in scope meets its criteria, you sign off the milestone or the project.

Link to this question
What happens if our requirements change during the project?

Requirements often change, and that is fine. Each change goes through change control: we describe the change, its effect on cost and on the plan, and you decide. Nothing changes the scope, the price or the dates without your written approval.

Link to this question
How long does a project take?

That depends on the scope, the number of systems and teams involved, how quickly decisions are made, and how ready third parties such as banks or vendors are. After discovery we give you a plan with milestones and their dependencies, and we report against it throughout the project.

Link to this question
How is a project priced?

A well-defined scope can be priced as a fixed price for that scope, with changes handled through change control. Where the scope is less certain, we price discovery separately and then the build, or work on time and materials with a budget we report against. You see the price and the timeline before we start.

Link to this question
Who owns what you deliver?

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. That covers the custom software, designs and documents delivered for you. Any existing tools or libraries of ours used in the project stay ours, are named in the contract and are licensed to you.

Link to this question
What happens after the project ends?

You choose. We can hand the system over to your own team with documentation and walkthroughs, or keep supporting and developing it under a support agreement or a dedicated team. We agree this before the project ends, so there is no gap.

Link to this question

Tell us what you need to build or connect.

Describe the systems, the timeline and the constraints. The right engineers take it from there.

  • Our team will call you within 24 hours during your preferred time slot
  • Our team is available 24/7