What are the four engagement models?
The four engagement models differ in who sets direction, where the engineers sit and who owns the system after launch. Most technology leaders use more than one over time. The full detail is on how we work.
Model | Who sets direction | Where engineers sit | After launch | Fits when |
|---|---|---|---|---|
Resource augmentation | Your team lead | Inside your team, your tools, your process | You own it | You have a backlog and a process but not enough hands |
Forward deployed engineers | Jointly, from inside the business | Alongside the people doing the work | Engineers stay to get it live | You know AI or automation could help but not where to start |
Project delivery | Agreed scope and date | FetchSky team | Handover, builders still reachable | You have a defined product to ship |
Managed services | FetchSky, within agreed limits | FetchSky, on call | FetchSky runs, monitors and improves it | You want the outcome without running the system |
Resource augmentation scales up or down as you need. Project delivery ends with a handover where the builders remain reachable. Managed services means the engineers who wrote the code are the ones on call. The trade-offs between the first and third are explored in resource augmentation vs project delivery, and the second model in what is a forward deployed engineer.
How does an engagement start?
An engagement starts with a conversation, not a proposal. FetchSky's sequence is conversation, scoping, proposal, start, and the whole sequence usually takes a few weeks. The conversation establishes what you are trying to do and which model fits. Scoping turns that into a written description of the work, the systems it touches and the people it needs. The proposal states scope, team and cost before any work begins. The start date is set once both sides have signed off. The scoping step is where most risk is removed, because it is where unstated assumptions about data, access and approvals come into the open.
What should you have ready?
You should have three things ready before scoping: the systems the work will touch, the people who can grant access to them, and the decision-maker who can approve the scope. For a banking build the list is longer and more specific. Digital onboarding, for example, needs the KYC provider, the core banking integration, the compliance sign-off path and the test environments agreed before an engineer writes a line. That checklist is in what a bank needs ready before a digital onboarding build. The general rule holds across industries: the fastest engagements are the ones where access and approvals were sorted out before the start date.
What does good delivery look like?
Good delivery looks like short cycles, review on every change, a staging environment that mirrors production, and a rollback plan that has been tested. Short cycles mean you see working software every one or two weeks rather than a status report. Review means a second engineer reads every change before it merges. Staging means you can try a release with real integrations before customers do. Rollback means that when a release goes wrong, the previous version is back within minutes rather than after a late-night rebuild. None of this is unusual. What matters is that the partner does it by default, in your environment, and shows you the evidence rather than describing the process.
What happens after launch?
After launch, one of two things happens depending on the model. Under project delivery, the system is handed over with documentation and the builders stay reachable for questions. Under managed services, FetchSky keeps running, monitoring and improving it, with the engineers who wrote it on call. The choice depends on whether you want to run the system yourself. The real cost of each path, including hiring, on-call rotas and the knowledge that leaves when people do, is worked through in managed services vs in-house: the real cost of running software.
What is specific to mobile and cloud work?
Mobile and cloud work each add constraints that a general software engagement does not have. On mobile, the first decision is native versus cross-platform, and for a regulated app the answer is shaped by security review, biometric and device APIs and store policy. That decision is set out in native vs cross-platform for a regulated app. Mobile also means living with OS updates and store policy changes after launch, which is why FetchSky's Bonsify product builds, releases and then maintains native iOS and Android apps for Shopify stores; see turning a Shopify store into a mobile app. On cloud, the questions are where data lives, who holds the keys and who is on call at 3am. FetchSky's cloud and digital infrastructure work covers these, and its own website runs on Devrims, its managed cloud hosting and DevOps product.
Two banking specifics also recur: identity verification, covered in how digital KYC verifies identity in seconds, and brand monitoring, covered in what is social listening.
Why does a partner that runs its own products behave differently?
A partner that runs its own products behaves differently because it cannot walk away from its own engineering decisions. FetchSky started as a product company in 2015 and still runs six products: Peekaboo Connect, Auto Finance, Mintly, Whistles, Bonsify and Devrims. Peekaboo Connect is live at 15 banks. Bonsify apps have to survive every iOS and Android release. Devrims hosts FetchSky's own website. Each of those creates a standing obligation to monitor, patch, support and improve, which is the same obligation a client has after launch. The reasoning is set out in why we run our own products.
Go deeper
- What is a forward deployed engineer?
- Resource augmentation vs project delivery
- What a bank needs ready before a digital onboarding build
- Native vs cross-platform for a regulated app
- Managed services vs in-house: the real cost of running software
- How digital KYC verifies identity in seconds
- What is social listening?
- Turning a Shopify store into a mobile app
- Why we run our own products
Read the detail of each model on how we work.
Frequently asked questions
How long does it take to start an engagement with an engineering partner?
At FetchSky, conversation, scoping, proposal and start usually take a few weeks in total.
Can we switch engagement models partway through?
Yes. Many clients begin with project delivery and move to managed services after launch, or add resource augmentation when the backlog grows. There are no contractual constraints on switching; in practice, every client moves onto a retainer for support and improvements once a project is delivered.
Who is on call after launch under managed services?
The engineers who wrote the code. FetchSky runs, monitors and improves what it built.
Does the partner work in our tools or theirs?
Under resource augmentation, in yours: your repositories, your ticketing, your process. Under project delivery, FetchSky's, with handover at the end.
How big is FetchSky?
50+ engineers, founded in August 2015 in Karachi, with offices in Lahore, Muscat, Leicester and Santa Ana.