Collaborative Models

Flexible Ways to Work With EKSTRUH

Five ways to structure the work, from extra capacity inside your team to a delivered outcome. The right one depends on how defined the work is and how closely you want to direct it. This page does not set rates, start dates or staffing guarantees.

Start a Project

Five collaborative models

01

Staff Augmentation

Additional specialist capacity that works with your team, on your backlog, under your direction.

When it fits

You already have a product owner and a codebase, and the constraint is engineering time or a missing specialism — not the absence of a team.

How we work

We agree the skills, the working rhythm and the boundaries before anyone starts. Your team keeps product direction. Day-to-day priorities stay with you. The specialist arrangements — dedicated engineers, AI, cloud and DevOps, and QA — are described on Staff Augmentation.

Key characteristics

  • Client-led priorities
  • Scope that can move with the backlog
  • Delivery shared with your existing team
  • Individuals or a small group, not a handed-over project

Who it suits

Teams that want to stay in control of the product and add capacity, rather than hand the work to a supplier.

02

Software Development Outsourcing

EKSTRUH takes responsibility for an agreed piece of software work, from understanding the requirement through to the delivered result.

When it fits

You want a defined outcome more than extra seats, and you do not want to manage the engineering day to day.

How we work

We clarify the scope, the risks and what acceptance looks like, then plan and build. You stay involved at the decision points. You are not expected to direct every task. Changes to the agreed work are made deliberately, not absorbed silently.

Key characteristics

  • A described outcome
  • Scope agreed up front and changed on purpose
  • Delivery ownership with EKSTRUH for the agreed work
  • A delivery team for that engagement, rather than people embedded in yours

Who it suits

Organisations that need software built or improved and would rather a supplier owned the delivery.

03

Dedicated Development Team

A stable team that stays with your product over time, across the technologies the product actually uses. This is not an ASP.NET Zero-only arrangement.

When it fits

The work is ongoing — a product, a platform or a programme — and a rotating set of individuals would cost more in lost context than it saves.

How we work

We agree the team shape, the ways of working and how priorities are set. The skills follow the product. That can include ASP.NET Core, ASP.NET Zero, ABP.IO or Angular where those are already in use, and other skills where they are not. The team is not assembled around a single framework.

Key characteristics

  • Continuity on one product
  • A defined team, rather than ad-hoc cover
  • Scope that evolves with the product
  • Planning shared between your direction and the team's delivery

Who it suits

Organisations with a long-running product who want a consistent engineering group, rather than a one-off project or occasional extra capacity.

04

Project-Based / Milestone

Work organised around an agreed outcome and staged checkpoints, so progress is visible before the next stage is committed.

When it fits

The result can be described well enough to plan stages, even if the detail of a later stage will depend on what the earlier one shows.

How we work

We break the work into milestones and review at each one. A later stage can be adjusted from what the previous stage made clear. The point of the checkpoint is a decision, not a ceremony. This page does not set how long a milestone takes.

Key characteristics

  • An outcome, staged
  • Scope confirmed at each checkpoint
  • Delivery ownership agreed for the stage
  • A team sized to that stage, not a standing department

Who it suits

Organisations that want to see the work and confirm direction before the next stage, without pretending every detail is known on the first day.

05

Agile / Time & Material

Iterative delivery where the scope is guided by a backlog, and time is used against priorities you keep choosing.

When it fits

The problem is real, but the full scope is not stable enough for a milestone plan — or you expect to change direction as you learn, and want that to be normal.

How we work

Short planning cycles, visible work in progress, and a regular decision about what happens next. Commercial terms are agreed before work starts. They are not published here, and they are not a promise of a rate, a start date or a duration.

Key characteristics

  • Scope that is allowed to move
  • Close involvement in what is prioritised
  • Delivery shared through the backlog
  • A team shape agreed for the engagement, then used against the current priorities

Who it suits

Organisations that expect the scope to move, and want that movement to be part of the work rather than an exception.

How the five compare

A reading aid, not a contract. The engagement is agreed from the work in front of us. Nothing in this table is a rate, a staffing promise or a delivery time.

Comparison of five collaborative models by client involvement, scope flexibility, delivery ownership, team structure and best fit
Comparison point Staff Augmentation Outsourcing Dedicated Team Project / Milestone Agile / Time & Material
Client involvement Day-to-day direction of the backlog Decision points, not every task Ongoing product direction A review at each stage Regular priority decisions
Scope flexibility High, within the agreed capacity Lower. Changes are explicit Evolves with the product Staged. Later stages can be reset High. Movement is expected
Delivery ownership Your team, with our engineers contributing EKSTRUH, for the agreed work Shared, with a stable team Agreed for each milestone Shared through the backlog
Team structure Individuals or a small group in your team A delivery team for the engagement A standing team on the product Sized to the stage Agreed for the engagement
Best suited to Extra capacity inside an existing team A defined outcome you do not want to manage day to day A long-running product Work that can be staged Work whose scope will keep moving

Where the work applies across industries is on Industries. Staff augmentation, including the specialist arrangements, is set out on Staff Augmentation.

Questions about these models

Is a dedicated development team limited to ASP.NET Zero?

No. A dedicated team is shaped around the product. ASP.NET Zero is one framework EKSTRUH works with, not the boundary of the model.

Do you publish rates, start dates or guaranteed availability?

No. Rates, timing and who is available depend on the work. They are discussed on enquiry. This page does not promise a price, a start date, a team size or a delivery time.

Can more than one model apply?

Yes. An organisation might add capacity now and later commission a defined project, or move from a milestone plan to a standing team once the product is live. The model is agreed before work starts, and it can be revisited when the work changes.

Have a Software Project in Mind?

Whether you're building something new, modernising an existing application or need specialist development support, let's discuss what you need.