Working together

Engagement Models

Four ways to work with us. Which one fits depends on how well defined the work is and who will own it afterwards. We will tell you which we think it is, including when that is the cheaper option for you.

Discuss a project How we work

The models we work under

Fixed scope

Best when The requirement is clear and unlikely to move

A defined deliverable at a defined price. We scope it properly first, because a fixed price on a vague brief is a fixed price on a guess.

One agreed scope and one price
Stage payments tied to delivered work
Changes quoted separately as they arise
Handover and documentation included

Not this one if The scope is still moving. Fixed pricing on an unclear brief costs both sides more than it saves, because every conversation becomes a negotiation.

Dedicated team

Best when The work is ongoing and the direction will change

A team working only on your product, month to month. You set the priorities, we run the engineering. Closest to having an in-house team without the hiring.

A named team, not a rotating pool
Your priorities, re-set as often as you like
Monthly billing, no change requests
You keep the same people as the product grows

Not this one if You need one specific thing built and then nothing. Paying monthly for a project with an end date is the expensive way to buy it.

Staff augmentation

Best when You have a team and a gap in it

Our engineers work inside your process, your repository and your standups. Useful when you need a specific skill for a while rather than a whole team.

Engineers who work to your standards, not ours
Inside your tools and your workflow
Scale up or down with notice
No attempt to take over the architecture

Not this one if Nobody on your side has time to direct the work. Augmentation needs an owner internally, or it turns into an expensive way to produce code nobody asked for.

Support and maintenance

Best when Something is live and has to stay live

Ongoing care for a system already in production, whether we built it or not. Agreed before you need it, so nobody is negotiating terms during an outage.

Named response times, agreed in advance
Who is on call and how you reach them
Security updates and dependency maintenance
Monitoring, with someone actually watching it

Not this one if You want new features rather than continuity. Support keeps a system healthy; a roadmap needs one of the models above.

Not sure which one this is?

Describe the work and who will own it afterwards. Choosing the model is part of scoping, and we do it before quoting.