Working Together
Software Development Engagement Models
Our software development engagement models describe how a piece of work is shaped, staffed, tracked, and ended. Different problems need different structures, so here is how each one actually operates.
What an engagement model actually decides
An engagement model is not paperwork. It decides four practical things: who defines the scope, who sets the priority order, how progress becomes visible to you, and what happens when the work reaches its natural end. Choose the wrong one and you spend the project fighting the structure instead of the problem.
These models are not tiers, and none is more serious than the others. They are answers to different questions. If your requirements are settled, a fixed scope project removes ambiguity. If they are still moving, locking them early just converts every new idea into a negotiation. Most long relationships pass through more than one model as the work matures, and moving between them is expected rather than exceptional.
Whichever model you choose, the underlying commitments do not change. You own the output, you can see the work in progress, and you can leave with everything you paid for. Those are covered further down, and they hold regardless of which of our technology solutions company disciplines the work touches.
Fixed Scope Projects
A defined piece of work with an agreed deliverable and a finish line. The most predictable model, and the one that depends most on the requirements being genuinely settled before anyone starts building.
What it suits
Work you can describe completely today: a first release with a known feature set, a migration between two systems you both understand, a redesign of something that already exists, or an integration where both ends are documented. It suits organisations that need certainty about what will be delivered more than they need the freedom to change direction along the way.
How it is scoped
A short discovery phase before anything is committed. We walk the workflows, list the integrations, agree what is explicitly out of scope, and write it down as a specification you sign off. Out of scope matters as much as in scope, because most disputes on fixed work come from an assumption nobody wrote down. If discovery shows the requirements are not stable, we say so and recommend a different model rather than fixing a scope we both know will move.
How work is tracked
Against the agreed deliverables, phase by phase, with a demonstration at the end of each phase rather than one reveal at the end. Change requests are handled as a small written amendment naming the effect on scope and timeline, so you always approve the consequence rather than discovering it.
How it ends or renews
It ends on acceptance. You test against the criteria agreed at the start, we resolve anything that fails them, and the code, accounts, and documentation transfer to you. Many clients follow it with a support arrangement, but that is a fresh decision rather than an automatic rollover.
Retained Ongoing Capacity
A reserved, continuing allocation of our team to your work, with priorities set by you at the start of each cycle. Built for products that keep evolving rather than projects that finish.
What it suits
Live products with a roadmap that keeps moving, where the next three months are directionally clear but the details are not. It suits teams who want to reprioritise as they learn from real usage, and who would find the paperwork of repeated fixed scopes more expensive than the flexibility is worth.
How it is scoped
Not once, but continuously. We agree the outcomes for the coming cycle at a planning session, break them into work items, and start. Anything that arrives mid-cycle goes into the backlog and gets ordered at the next planning session rather than displacing work already underway. You control the order of the list at every one of those sessions.
How work is tracked
In your board, in the open, with a demonstration at the end of each cycle and a written summary of what shipped against what was planned. Where the two differ, the summary says why, because a plan that always matches reality is usually a plan nobody updated honestly.
How it ends or renews
It renews by default at the end of each period and either side can give notice under the terms agreed at the start. Because everything lives in your repositories and accounts throughout, ending it is a matter of the last cycle closing cleanly rather than an extraction project.
Embedded Team and Staff Augmentation
Named engineers who work inside your team, to your process, under your technical direction. The closest thing to hiring, without the hiring timeline.
What it suits
Organisations that know what to build and have the leadership to direct it, but not the hands to deliver it in the window they have. It also suits teams who need a specific specialism for a season, where a permanent hire would be hard to justify or hard to find.
How it is scoped
By role and duration rather than by deliverable. We agree which skills you need, for how long, and what a successful first month looks like. You interview the people before they join, and you can ask for a change if the fit is wrong. Scope of work is then whatever your roadmap says, because you own the backlog.
How work is tracked
Entirely inside your systems. Our engineers attend your standups, work your tickets, open pull requests into your repositories, and are reviewed by your reviewers. We add a light monthly check-in on our side covering engagement health and anything the individuals need, which is deliberately separate from your day to day management of the work.
How it ends or renews
It runs on a rolling basis with a notice period, and scales in either direction at agreed intervals. Because the work has been in your repositories and your process from day one, an engineer rolling off leaves nothing behind that only they understood, provided the pairing and review habits have been kept up.
Advisory and Fractional Leadership
Senior technical judgement on a part-time basis, for organisations that need the decisions made well without needing a full-time person to make them.
What it suits
Companies at a decision point: choosing an architecture, assessing a system they inherited, planning a replatform, setting engineering standards, or building an in-house team from a standing start. It also suits non-technical founders who need someone accountable for technical decisions while the company is still too small to warrant a permanent leader.
How it is scoped
Around questions and outcomes rather than deliverables. We agree the decisions that need making, the rhythm of involvement, and what you should have in hand by the end. Where a written artefact is expected, such as an architecture review or a hiring plan, we name it explicitly so the engagement has something concrete to point at.
How work is tracked
Through a standing session at an agreed frequency, a written record of each recommendation and its reasoning, and availability between sessions for the decisions that will not wait. The written record matters most, because advice nobody wrote down cannot be revisited when circumstances change.
How it ends or renews
It typically winds down rather than stopping, reducing in frequency as your own capability grows. That is the intended outcome. If it is still running at the same intensity a year in, one of us has misjudged what the engagement was for.
Support and Maintenance
Continuing care for a system that is already live, covering the unglamorous work that keeps software healthy long after the build is finished.
What it suits
Anything in production that people depend on. Dependency and security updates, defect fixes, small improvements, monitoring, and being reachable when something breaks. It suits organisations without an in-house team to carry that load, and teams who have one but would rather it spent its time on new work.
How it is scoped
By service level rather than by feature list. We agree which systems are covered, what counts as an incident, response expectations by severity, coverage hours, and how much routine improvement work is included alongside reactive fixes. If we did not build the system, this starts with a review so we are not agreeing to support something we have not read.
How work is tracked
Through a ticket queue you can see, with every incident logged, categorised, and closed with a written cause. The monthly report covers what came in, what patterns are emerging, and which recurring issue would be cheapest to fix permanently rather than absorb repeatedly.
How it ends or renews
It renews on a rolling term with notice on both sides. Ending it includes a handover pack: runbooks, environment and access documentation, known issues, and a walkthrough with whoever is taking it on. Related infrastructure and uptime work is covered on our managed hosting page.
Contracts, IP ownership, and leaving cleanly
These terms are the same across every model, because they are not negotiating chips. They are the baseline that makes the rest of the relationship workable.
You own everything we produce
Source code, designs, infrastructure definitions, documentation, and data models transfer to you. We keep no ownership stake in what we build for you and we do not resell your work to anyone else. Where we use open source components, we tell you which and under what licence.
No lock-in by design
Work lives in your repositories and your cloud accounts from the first commit, not in ours. There is no proprietary framework you would have to keep paying us to maintain, and nothing about the setup requires our continued involvement to keep running.
Exit terms written before you need them
Every agreement states notice periods, what a handover includes, and how confidential material is returned or destroyed. Agreeing that while everyone is happy is far easier than agreeing it in the middle of a change of direction.
Side by side
Engagement model comparison
| Dimension | Fixed Scope Projects | Retained Ongoing Capacity | Embedded Team and Staff Augmentation | Advisory and Fractional Leadership | Support and Maintenance |
|---|---|---|---|---|---|
| Scope definition | Fixed upfront in writing | Set each cycle | Your backlog | Decisions and outcomes | Service levels |
| Who sets priorities | Agreed at the start | You, every cycle | You, continuously | Jointly, by question | Severity and queue |
| Handling change | Written amendment | Reorder the backlog | Change the ticket | Change the agenda | Within agreed levels |
| Reporting rhythm | Per phase demo | Per cycle summary | Your standups | Written recommendations | Monthly incident report |
| Typical horizon | Has a finish line | Rolling, open ended | Rolling by role | Reduces over time | Rolling term |
| How it ends | On acceptance | Notice at cycle end | Notice, roll off | Winds down | Notice plus handover |
Moving between engagement models mid-flight
A build finishes and becomes a support arrangement. An embedded team shrinks to advisory once your own hires land. Two commitments make those handovers safe.
We flag the mismatch rather than absorb it
If a fixed scope project is accumulating change requests faster than it is closing tickets, that is a signal the structure is wrong. We raise it directly instead of quietly running the friction and letting it show up as a delay.
Transitions happen at a boundary
We switch at the end of a sprint, a phase, or a billing period, never halfway through a piece of work in flight. Anything unfinished is either completed under the old terms or explicitly carried across in writing.
Engagement model FAQs
Usually fixed scope, provided discovery shows the requirements are genuinely stable. If discovery keeps surfacing open questions, retained capacity is a better fit, because a scope that moves during a fixed engagement turns every improvement into a negotiation.
Yes, and it happens often. We switch at a clean boundary such as the end of a sprint, phase, or billing period, and anything in flight is either finished under the old terms or carried across in writing so nothing falls between the two.
You do, in every model. Source code, designs, infrastructure definitions, and documentation are yours, they live in your repositories and cloud accounts throughout, and we retain no ownership stake in what we build for you.
We do not publish figures, because a number without a scope is a guess. After a discovery conversation we run a short scoping exercise that fixes the deliverables or the shape of the commitment, and the written proposal that follows is what you can plan around.
With staff augmentation our engineers work under your technical direction, on your backlog, inside your process. With retained capacity we carry more of the planning and delivery management ourselves and report against outcomes you set each cycle.
Yes. Most of our work is alongside an internal team rather than instead of one. We agree the split of ownership early, review each other's pull requests, and keep the boundary explicit so nobody is guessing who owns a given area.
Still deciding?
Not sure which model fits, book a call and we will tell you
A short conversation is usually enough for us to point you at the right structure. No pitch, no pressure.
Book a callContact Us
Lahore, Pakistan · London, U.K · Austin TX, U.S · Toronto, Canada