How we work

Six engagement models, a few fixed rules.

We do not run every job under the same contract. Delivering a well-defined module at a fixed price is not the same as building and handing over a company’s core system across several years. Below is who each model suits, how it is priced and how it ends.

Engagement models06

Fixed-scope project

Scope and acceptance criteria written upfront; the work ends at delivery.

When the need is clear this is the simplest and cheapest route. Scope, delivery date and acceptance criteria go into the contract, and the work ends at acceptance. Whether you want maintenance afterwards is your choice.

Who it suits

A defined, bounded need
A single system, module or application
A web or mobile product, first release
A specific function added to an existing system

How it is priced: Fixed price, paid against phase milestones.
How it ends: Ends with acceptance, documentation delivery and a warranty period.

Phased programme

Each phase priced and contracted separately, with what the previous one taught.

On a large scope, one contract binds both parties and protects neither. The programme is split into phases, each contracted after the previous one is accepted. You decide whether to continue at every phase boundary.

Who it suits

Multi-module core systems, ERP-scale work
A programme whose full scope cannot be drawn today
Budgets that have to spread across periods
Processes that will go live stage by stage

How it is priced: Fixed price per phase, each priced after a paid preliminary study.
How it ends: Each phase ends at its own acceptance; moving to the next is never obligatory.

Build – Operate – Hand over

We build the system, run it in production for a while, then hand it to your team.

For companies that intend to run the system in-house but do not yet have the team. We build it, keep the live part standing for a period while your team learns beside us, and operation moves to them. It does not suit everyone: without the intention to run the system yourself, a simpler model is the right one.

Who it suits

A company that wants to build its own software team
Systems where operations are critical and downtime is not tolerable
A goal of leaving external software and running it in-house
Long, multi-unit rollout programmes

How it is priced: A development price, plus a monthly operation fee for the live part.
How it ends: Both parties establish that the handover is complete; what follows is your choice.

Three phases and how responsibility shifts03

ResponsibilityfeliXartYou

Build92%

Operate58%

Hand over12%

Build

The system goes live in waves, never in one jump.

Architecture, data model, code quality and delivery are on us. Each wave moves one unit onto the system: trained before the switch, running in parallel with the old system for a while after it.

What happens

Scope and data model fixed by the technical assessment
Training for each unit before its wave
Old and new systems run in parallel for a period
Outputs compared; the switch is decided together once the gap closes
Source code and documentation delivered at every phase acceptance

Responsibility: feliXart
What you hold at the end: A working part of the system, its source code and documentation, at every phase

Operate

Writing a system and keeping it standing every day are different jobs.

From the moment the operations core goes live, the system becomes something that has to be watched and intervened in. We carry this phase while your team learns beside us.

What happens

Production monitoring and incident response
Release management, deployment and rollback plans
Backups, restore rehearsals and infrastructure oversight
Code review, architectural advice and regulatory tracking
Defect fixes under warranty sit outside this line and are free of charge

Responsibility: feliXart, alongside your team
What you hold at the end: A system settled under real load, monitored and backed up

Hand over

The point of this model is to make itself unnecessary.

A handover is not a document delivery; it needs a team to receive it. That team is formed while development is still running, and learns the system as it is born.

What happens

The receiving staff join while development is still running
They take part in code reviews and release processes
User and technical documentation are delivered
Training and a handover rehearsal take place
Completion of the handover is established by both parties together

Responsibility: Your team
What you hold at the end: The whole system, its source code, and your own team able to sustain it

What happens after the handover is your call: the service can end, continue in a narrower scope, or carry on as it is. Because you own the system, that is a choice about continuity rather than a dependency.

Takeover and recovery

We take over a system another team left, and report its condition first.

A half-finished project, a team that left, an unowned codebase. Before promising to take anything over we run a paid review: the state of the code, whether it is worth saving, and its risks, in writing. Sometimes the answer is "do not continue with this", and we say so plainly.

Who it suits

A project that has dragged on and lost its owner
A system whose developer has parted ways
Software running in production that nobody dares touch
An independent technical audit before changing supplier

How it is priced: A fixed-fee review first; the decision to continue follows, by work order or fixed price.
How it ends: Ends with the review report. You are under no obligation to continue.

Dedicated team

Reserved monthly capacity, with priorities you set.

For continuously evolving products whose scope cannot be written in advance. We reserve a set capacity for you and you decide sprint by sprint what gets built. Unlike fixed price, what is bought here is time, not scope.

Who it suits

A live product under continuous development
A roadmap whose priorities shift often
Capacity added alongside your own team
Work mixing maintenance, improvement and new features

How it is priced: A fixed monthly capacity fee. Unused capacity does not roll over.
How it ends: Either side can end it with written notice.

Advisory and audit

Review, architecture and a roadmap only. No development.

Some companies need a decision, not software. An audit of the existing system, an evaluation of supplier proposals, a second architectural opinion or a roadmap can all be commissioned on their own. You are not obliged to continue with us afterwards.

Who it suits

Independent assessment before an investment decision
Technical comparison of incoming proposals
An audit of the existing system and team
A second architectural opinion

How it is priced: A fixed fee, based on duration.
How it ends: Ends when the documents are delivered.

Whichever model04

The source code is yours

Delivered at every phase acceptance and kept on your own servers. There is no per-user licence.

Acceptance criteria are written down

When a phase is done is defined in the contract: tests, data reconciliation, training, documentation.

No fixed price for undefined scope

A price given before scope is clear is either too high or gets overrun. Where needed, a paid preliminary study comes first.

No single-shot cutover

Go-live runs in waves; old and new run in parallel for a period and the switch is decided together.

Principles01

01Data ownership: Whether a system is independent is decided by where its data is born. In our setup business data is born in your database from day one, and only what is needed goes outward. When you decide to leave an external system, the only action is closing a connection — nothing has to be rewritten.
02One connection layer: Every link to the outside — your existing software, the e-invoicing provider, vehicle tracking, the payment gateway — is gathered into a single module. The rest of the application does not know those services exist. When a provider changes, one place changes.
03Rollout in waves: The system goes live in waves, not in one jump. Each wave brings training for the unit involved, a period of old and new running in parallel, a comparison of both outputs, and a switch decided together once the gap closes. We do not do irreversible cutovers.
04Designed for handover: This is not build-and-leave work. The people who will take the system over join while development is still running and learn it as it is born. When documentation, training and a handover rehearsal are complete, operation moves to your side.
05The AI does not decide: We use AI where it solves a concrete problem, not as a demo. Everything it produces has the status of a suggestion: no record is committed without user approval. All AI functions live in one service layer, independent of the model provider.

Commercial discipline02

01No fixed price for undefined scope: A fixed price given before scope, boundaries and budget are clear is either too high or gets overrun. Both work against the client. That is why larger programmes start with a paid technical assessment.
02Each phase is its own contract: A programme is not tied to a single contract. Each phase is signed after the previous one is accepted, priced with what that phase taught us. Signing today for scope nobody has seen binds both parties and protects neither.
03Acceptance criteria are written down: A phase is complete when the written test scenarios pass, data reconciles against the existing system, user training is done, user and technical documentation is delivered, and the parallel-running period has finished cleanly.
04The source code is yours: Ownership of the source code transfers to you once payment obligations are met. Code is delivered at every phase acceptance and lives on your own servers, with unlimited rights to use, change and develop it with your own staff.
05Warranty is separate from operation: Fixing bugs under warranty is free of charge and runs independently of the monthly operation fee. What that fee pays for is not bug fixing but keeping the live part of the system standing every day.

Where we start03

Once we have chosen the model together the order is simple: a direct quote where scope is clear, measurement first where it is not. Whatever the size, the first step is a conversation.

Technical assessment

Where scope is unclear we measure first: a code audit, a process map and a roadmap that can be priced.

→02

Building the system

Starting from the operations core and going live wave by wave.

→03

Operation and handover

Oversight of the live system while your own team is trained.

→

Does this structure fit you?

Tell us where you are and we will work out which step you should start from.

Get in touch See our services