Package 2

Turnkey software modules

A defined function, a fixed price, a deadline written into the contract.

Delivery runs in two- to four-week sprints. Each one ends with working software (an increment) and a review with your team.

Outline your case
Starting point

When this package applies

A single module, not a team

The need concerns a specific function, not additional headcount.

The team is committed elsewhere

The skills are available but tied up in higher-priority work.

A requirement for predictable cost

The cost has to be known before the work starts, not after it ends.

A project with no end in sight

Hourly billing has stopped leading to a closed scope.

Stage one

Initial analysis: one to two weeks

Closing the scope is work, not a formality — which is why the analysis is a separate, priced stage. It produces an ordered backlog with acceptance criteria, an architecture outline, a register of assumptions and risks, and a price range. All of it remains your property regardless of the decision to proceed.

No documentationWe produce it together — workshops with your team, a description of the scope, the acceptance criteria, the interfaces and the data.
Documentation insufficient for a quoteA review, the gaps filled in, and the document closed to the point where a price and a deadline can be given.
Documentation completeA review confirming completeness against the criteria below, followed by the quote.

The initial check is free of charge. We assess your document against the list below and establish whether it is sufficient for a quote and how much work closing it would take.

Criteria

What has to be settled before a price can be given

Scope and exclusions — what the work covers and what is explicitly excluded from it.
Acceptance criteria — the conditions under which the work counts as complete.
Interfaces and integrations — what the module connects to and on what terms.
Data — the model, the migration, access to test data.
Non-functional requirements — performance, security, the expected load.
Environments and deployment — the target environments and how changes are delivered.
Decision-making — who settles disputed points on your side, and within what time.
Process

Delivery in increments

The scope is divided into increments. Each is built in its own sprint, made up of the same recurring activities: plan, build, test, review. A sprint ends with working software and a partial acceptance.

Initial analysis Final acceptance 1. Plan 2. Build 3. Test 4. Review Sprint 1 Increment 1 1. Plan 2. Build 3. Test 4. Review Sprint 2 Increment 2 1. Plan 2. Build 3. Test 4. Review Sprint 3 Increment 3

After every increment the code is deployable. The tests run in the pipeline and deployment requires no manual steps. There is no final integration phase.

Engagement

Two models to choose from

Not every project can be closed on scope at the outset. Where it can, we fix the scope. Where it cannot, the budget and the deadline stay fixed.

Model A

Fixed scope and fixed price

For modules that can be described and closed. Scope, price and deadline agreed before the work starts, billed by increment.

Fixedscope, price, deadline
Flexiblethe order of the work
Model B

Fixed budget and fixed deadline

For work where the direction is settled and the detail is not. The scope is delivered in order of value, and you set the priorities before each increment.

Fixedbudget, deadline
Flexiblescope and priorities

Scope exchange at no extra costAn item that has not been started can be exchanged for another of comparable size — with no change to the price and no change to the deadline. Changes that enlarge the scope are quoted separately and carried out after written approval.

Outcome

Deliverables

A working module — deployed in the agreed environment.
Source code and documentation — together with the deployment instructions. The rights to the code pass to you on the terms set out in the contract.
Tests and the pipeline — a set that allows subsequent changes to be verified.
The accepted analysis — the backlog and the criteria against which the module was accepted.

After acceptance the module can be placed under maintenance: library and security-patch updates, adjustments to changes in its environment, minor extensions, an agreed response time. That is a separate contract. Remedying defects covered by the warranty remains our responsibility and is not part of that fee.

Questions

Frequently asked questions

What if the requirements change along the way?

Exchanging an item that has not been started for another of comparable size carries no extra charge. A change that enlarges the scope follows the standard path: an assessment of its effect on price and deadline, presented in writing, carried out after your approval.

Do you work in agile?

Delivery runs in increments, each with a review and collected feedback. In model A it is the scope that is frozen, not the way of working — the order can change. In model B the scope is flexible as well, within the agreed budget and deadline.

Who is responsible for testing?

The tests on our side are part of the work and run in the pipeline. Acceptance tests on your side are mandatory: after each increment for what has been built, and at the end for the whole. Acceptance follows the criteria established in the analysis.

What if we decide not to proceed after the analysis?

The backlog, the acceptance criteria and the architecture outline remain your property. You can have them built by your own team or by another supplier. We prepare them so that they can be quoted outside us as well.

What about defects found after acceptance?

Defects present at the time of acceptance are remedied under the warranty, on the terms set out in the contract, at no additional charge. Maintenance of the module — responding to changes in its environment and minor extensions — is covered by a separate contract.

Can we take the module over with our own team?

Yes, and that is provided for from the outset. We hand over the code, the documentation, the pipeline and the deployment instructions, and on request we run the handover together with your engineers.

How do you use AI tools?

The rules for working with AI tools, including how your code and data are handled, are set out in a separate document provided before the work begins. We apply to ourselves the same rigour we require in the code audit.

Whether this can be closed as a package

Tell us what needs to be built and by when. The initial assessment of the starting point is free of charge.

Outline your case