Named engineers, testers and designers on your plan
Named engineers, testers and designers join a client’s team for an agreed term, work its hours and backlog, and commit to its repository under its own accounts. We are a small firm. Staffing is confirmed role by role.
- Named people the client interviews first
- Code and accounts in the client’s name
- Roles that cannot be staffed are declined early
This model suits product teams that need extra hands for a release or a migration, and it suits a business whose only developer has resigned. Companies use it to get engineers whose hours overlap their own, with no local entity registered, no payroll run and no employment contract signed. We are a small team. That size decides how many people can be committed, how fast one can be added, and why an unsuitable name never reaches a contract.
Where staffing gaps slow delivery
A single developer who has resigned
One person wrote the system, holds the deployment knowledge and is serving a notice period, while nobody else has seen the release steps. Hiring a replacement takes a long time. Every change meanwhile is a gamble.
Temporary work that needs more people
A release or migration brings extra work. It will not last. Permanent hiring for it leaves surplus salaried headcount once the work is done, while hiring nobody pushes the delivery date out and strains the existing team. Neither fits.
Profiles that change after the sales stage
The CV shared during the sales conversation belongs to one person, and someone else joins the first call, and nobody explains the change. The experience differs from the proposal. Trust drops early.
Code held outside the business
The repository, the cloud account and the deployment scripts sit with the vendor, so the application runs while the business holds no source code it paid for. That is a trap.
A skill needed for a short period
A mobile release, a database migration or a security fix calls for a skill that a full-time hire would not use again. The existing team may lack the time. Doing it wrong costs more.
Time zones that delay answers
Questions sit in an overnight queue. They come back half understood, and each clarification costs a day, so the hourly rate on the invoice says little about how much working software is finished by Friday.
Handover as a source archive
The people leave and only source code remains. There are no notes, no runbook and nobody to ask why a service is configured the way it is, so the next team spends weeks guessing.
A business here needs a known person. That person works inside the business’s own process, and the code and knowledge build up in its accounts and its repository, never in a supplier’s shared drive.
Named people, your backlog, your repository
The roles are agreed first and the client interviews each person proposed, who then works to the client’s plan, in the client’s tracker, for the committed term. Every commit lands in the client’s repository from day one, and documentation is written as the work happens, so a handover exists before anyone discusses ending it. The cloud accounts follow the same rule.
Interview and approval
The person met is the person placed. If a change becomes necessary, the client hears first and interviews the replacement too, before that person touches the codebase or any production credential.
Accounts held by the client
Repository, cloud console, app store listings and documentation all belong to the client, so nothing needs extracting from GullySystem if the engagement stops. Nothing was ever kept here.
Honest staffing limits
A small firm cannot field a large group of senior engineers at short notice, so the client gets a start date, a name and a plain account of experience. Some roles get a refusal.
What changes with a dedicated team
What the business gets, before any talk of technology.
Extra capacity alongside recruitment
An engineer joins the client’s sprint while the permanent role is still being advertised, so the release plan stops depending on a hiring cycle. Start dates are confirmed role by role.
The same person on the work
One consistent engineer slowly learns the data models, the habits of customers and the awkward screens that nobody documented, and that context is where the value sits. It cannot be rushed.
Assets held in the client’s systems
Commits sit in the client’s own history under its branching rules, and credentials live in its accounts, while documentation stays in the repository. Nothing waits on a GullySystem drive.
Working hours that overlap
Agreed overlap with the client’s hours means a question raised in the morning is answered that day, and where overlap is thin the plan names which tickets run asynchronously. Live calls cover the rest.
Team size changed on agreed notice
When a burst of work ends, the team shrinks on the notice written into the agreement, so the client never carries a permanent salary for work that was temporary. The budget shrinks too.
Handover notes written during the work
Runbooks, architecture notes and decision records appear as the work happens, so the end of the engagement is a transition with material in hand. Nobody chases people who have left.
What a dedicated team engagement includes
Everything from the first discovery session to production and long-term upkeep.
Role definition and sizing
Headcount, seniority, skills and term are worked out with the client, and the same review says whether a dedicated team or a fixed-scope project suits the work better. The reasoning is written down.
Candidate presentation and interviews
The client meets each proposed person and questions them on code, tooling and past releases, and nobody joins without that approval. A weak interview ends the proposal.
Full-Stack engineers
Developers work across web front ends, APIs and databases in the stacks we use daily, joining the client’s existing codebase and following its conventions. They never start a parallel codebase beside it.
Mobile developers
Android, iOS and cross-platform work includes release management through the client’s Play Console and App Store Connect accounts, with builds tested on older handsets as well as new ones. Customers still carry old phones.
QA and test engineers
Manual and automated testing runs inside the client’s release cycle and builds a regression suite that stays with the client. Developers do not mark their own work. That separation is the point.
DevOps and infrastructure engineers
Pipelines, environments, monitoring and cloud cost tracking are set up in the client’s own cloud accounts, with every configuration file committed to the repository as code. A new engineer can read it.
UI and UX designers
Journeys, wireframes and clickable prototypes are produced in the client’s Figma files and reviewed with its users, then pass to development with empty, error and loading states already drawn. Nothing is left to guesswork.
Business analyst and product support
Requests from business teams become written acceptance criteria and a prioritised backlog, so engineers work from a clear list instead of guessing what a stakeholder meant in a meeting. Ambiguity is cheap to fix early.
Technical lead and code review
A senior engineer reviews the team’s pull requests, sets coding standards and makes architecture decisions, which suits businesses with no technical person of their own. Standards are written down. They do not live in one head.
Onboarding and ramp-up plan
The first stretch covers environment setup, an early small fix and shadowing of the client’s releases, so that ramp-up is visible instead of being billed in silence. Nothing is hidden.
Knowledge capture as you go
Runbooks, architecture notes and decision records are written during the work and kept in the client’s repository, so understanding stays with the team and not in one person’s memory.
Exit and handover support
A defined wind-down covers recorded knowledge transfer sessions, completed documentation and the handing over of every credential, with an overlap alongside the incoming team agreed in advance.
Where this arrangement is used
The processes this service is most often asked to set up and automate.
Product company covering a resignation
A product company’s only backend developer resigns. An engineer overlaps with the outgoing developer, records walkthroughs of deployment and third-party integrations, and keeps releases moving while a permanent hire is recruited in parallel.
Manufacturer with an internal technical lead
A manufacturer has a portal to build. Its technical manager has no developers. Engineers and a tester work to the manager’s plan, in the manager’s repository, inside the client’s stand-ups, while architecture decisions and supplier relationships stay with the client.
Company wanting overlapping hours
An overseas firm wants overlapping hours. The team works those hours, joins the daily call and commits to the client’s repository, so no local company is registered and no employment relationship is created.
Agency with delivery overflow
A design agency has several projects landing in one quarter and little development capacity, so engineers work under the agency’s project manager for the agency’s own client. Naming GullySystem is agreed in writing.
Growing business needing a specialist skill
A database migration and a slow reporting query call for a senior engineer who has handled both before, and who documents each change and the reason behind it. The engagement ends on the agreed date.
Startup better served by a fixed-scope project
A founder has an idea and no specification. Nobody can direct a team. A dedicated team without direction burns budget and produces little, so we propose a fixed-scope first version instead and revisit the team question once a product exists.
Is this the right service for you?
It suits businesses that have outgrown manual processes and want a system they can rely on.
Product teams needing capacity for a period
A release or migration is real but temporary. Permanent hiring for it can leave surplus salaried headcount once the burst has passed, which is why a defined term suits better.
Businesses whose developer has resigned
One person holds the code, the deployment and the context, and the priority is keeping the system running while a replacement is found. Release steps get written down.
Companies wanting overlapping hours
These businesses want engineers whose hours overlap their own, and they avoid setting up a local entity, employing people directly or running payroll abroad. The engagement stays a service contract.
Agencies and studios with overflow
Design and consulting firms sometimes sell more than they can build in a quarter, and need engineering capacity that works under their own project management.
Businesses with a technical lead but no team
Somebody internal owns the architecture and the priorities. What is missing is the hands to do the work under that direction, with reviews that follow the owner’s own standards. We supply those hands.
Cases where a fixed-scope project fits better
Well-defined work with an end suits a fixed-scope project, where delivery risk sits with GullySystem and the price is agreed before work starts. If nobody on the client side can direct a team, a dedicated team has no clear output, and if the need is permanent hiring in-house is the sounder route. We say which applies before any proposal.
What it can do, in plain terms.
Named individuals
Each person is met before starting. Any change is discussed first.
Your tools and process
Work follows the client’s tracker, repository, branching rules, stand-up and definition of done, and GullySystem’s own process never replaces them. The client’s rules win.
Overlapping working hours
Hours are agreed to overlap the client’s own, so a question raised in the morning is answered the same working day. The overlap is written down.
Code and accounts in your name
Repository, cloud, app store and third-party accounts belong to the client, and our people are added as ordinary users and removed on the day the engagement ends. Nothing lingers.
Structured ramp-up
A small change ships early, so the client can see progress on an unfamiliar codebase through merged pull requests and not through status slides. Nobody disappears into reading for a fortnight.
Senior review available
A senior engineer gives code review and architecture guidance. This matters most where the client has no technical lead who can say yes or no to a design before it is built.
Notice-Based scaling
People are added or removed on agreed notice. Capacity follows the workload instead of a fixed contract, so the team is never larger than the backlog needs and the monthly bill stays honest.
Replacement and continuity terms
The agreement sets out what happens if a person falls ill, resigns or does not suit the team, and it covers overlap and handover. It is written before it is needed.
Documentation as a deliverable
Runbooks, architecture notes and decision records are produced during the work, as part of each ticket that changes how the system behaves. Nobody writes them in the last week.
Confidentiality and ip assignment
A non-disclosure agreement and a written assignment of intellectual property are signed before any code is written or any repository access is granted. No exception is made for small tasks.
Visible progress reporting
Work is visible in the client’s own tracker, and a weekly summary lists what moved, what is blocked and which priority changed since the last one.
Planned exit
Knowledge transfer sessions, an overlap with the incoming team and the handing over of access follow an agreed sequence, so the exit is orderly and nothing is left unexplained.
How the work runs, step by step.
From the first conversation to a release your team uses every day. Each step says what you provide and what you get back.
- 01
Understand the need
We review the work, the existing team and the timeline, and say whether a dedicated team, a fixed-scope project or an in-house hire fits. We need codebase access or a walkthrough.
- 02
Roles, availability and terms
GullySystem states which roles it can staff, from what date and with which people, along with rates, notice periods and replacement terms. The client names who directs the work. It also gives a realistic start date.
- 03
Interviews and selection
The client meets the people proposed and runs its own technical conversation, which needs interviewers able to judge them and a decision inside an agreed window. Availability is held for that window. It is not reserved indefinitely.
- 04
Onboarding and ramp-up
Access, environments and context are set up, and a small change ships early, reviewed by the client’s lead. We need access on day one. We also need a named contact for questions.
- 05
Working in your rhythm
Daily work runs in the client’s tracker and stand-ups. Reviews follow the client’s process. A groomed backlog is needed from the client, because a team without prioritised work has little to deliver, whatever its weekly summary says.
- 06
Review, scale or wind down
Size and shape are reviewed at intervals, and a planned exit follows when the engagement ends, with notice as agreed and a person ready to receive the knowledge. Both are named early.
What you receive when the work is done.
Everything needed to run, maintain and extend the software without depending on us.
It connects to the systems you already use.
Tools that work stay. The new system is joined to them rather than replacing them.
Source and Delivery
- GitHub
- GitLab
- Bitbucket
- Azure DevOps
- Your own branching and review rules
Planning and Tracking
- Jira
- Linear
- ClickUp
- Trello
- Azure Boards
Communication
- Slack
- Microsoft Teams
- Google Meet
- WhatsApp for urgent escalation
- Shared documents
Cloud and Environments
- AWS
- Azure
- Google Cloud
- DigitalOcean
- Your own staging and production accounts
Design and Documentation
- Figma
- Notion
- Confluence
- Repository-based documentation
- Recorded walkthroughs
Chosen for reliability and a long life.
Picked to match your scale and to stay maintainable for years.
Backend
Frontend
Mobile
Infrastructure
Quality
Why owners choose GullySystem.
Staffing limits stated up front
GullySystem has no large bench. It is a small firm, and if the right person cannot be placed by the client’s date, we say so in the very first conversation.
The person you meet joins the team
No profile is sent as bait. If somebody has to change, the client hears first, meets the replacement and gets an overlap so that context is not lost.
Repository held by the client from the start
Work goes into the client’s source control and cloud accounts from the first commit, so ownership is a setting switched on at the start. It is more than a contract clause. It is checked on day one.
Documentation written during the work
Runbooks and decision records are part of the job and not a final-week deliverable, so an engagement ends with material a successor can pick up at once.
Plain account of ramp-up
Nobody is productive on day one. We plan a visible ramp-up with an early small fix, in place of a silent fortnight of reading that nobody can inspect.
Alternatives named when they fit
If the work is well defined, a fixed-scope project moves delivery risk to GullySystem, and if the need is permanent an in-house hire is the better route. We state both before a monthly arrangement is proposed.
How the engagement can be shaped.
Each model says what it suits and how the work is scoped. Pick the one that fits, or ask which one we would suggest.
Single engineer extension
For a team with a backlog and a single skill gap, such as a tester or designer. Billing runs monthly for the person, who adopts the client’s tools and process. A developer, tester or designer reports to the client’s lead, who sets daily priorities. Reordering the backlog costs nothing extra. Notice applies on either side, and the engineer leaves notes, code and access behind.
Dedicated team
Suits a product needing steady capacity across several skills. One monthly charge covers the named team, with a minimum term agreed at the start so ramp-up can settle. A senior engineer reviews the developers’ and tester’s output. The client’s product owner is the single contact and sets the backlog order. Scope shifts inside the sprint are absorbed. When the term ends, the team stands down and returns repositories and access.
Managed team with a lead
For an owner with no technical person on staff. A delivery lead plans each sprint, reviews code and reports weekly, while developers and a tester do the building. The monthly fee covers the lead and the team. The owner sets priorities. A change of direction is recorded in the weekly report and priced before it displaces planned work. Notice ends the arrangement, and repositories and credentials are handed back.
Short-Term specialist
Meant for a defined problem, such as a migration, a slow query or a single release. The task is scoped in writing and invoiced as one job, ending when it is done. A senior engineer takes it on, while the client’s technical contact provides access and review. Added work needs its own estimate. Code and notes are handed over on the last day.
Each part of Dedicated Team and Staff Augmentation, in its own page.
Questions owners ask first.
Plain answers to the questions asked before work starts.
How many people can you actually provide, and how quickly?
Roles and dates decide. GullySystem is a small company, and people come from the same team that does project work, so a few can be placed sooner. Larger groups mean recruiting. We call that recruitment, not a bench. Unstaffable roles get a plain no.
Who owns the code and the intellectual property?
The client does, and the agreement says so before any work starts, while in practice work is committed to the client’s repository and deployments run in client-owned cloud accounts. App store listings sit under the client’s developer account and documentation lives in the repository, so nothing needs extracting from GullySystem at the end because nothing was held here.
What happens if the person assigned to us is not suitable?
The person is replaced. Early notice from the client helps. Notice and the cost of the overlap are written into the agreement before the engagement starts, and the replacement overlaps with the first person so context passes across. Because the client interviews every candidate itself, a mismatch is less likely, though it can still happen, and we treat it as ours to fix.
What if somebody resigns mid-engagement?
The client hears as soon as we know. A replacement is proposed and interviewed by the client, with an overlap arranged so that knowledge moves across and nothing is lost. Documentation is written during the work and everything lives in the client’s repository, so no single person is the only route to understanding the system.
How is this different from hiring a fixed-scope project?
The difference is risk and direction. A fixed-scope project has a defined outcome and a price, with delivery risk sitting with GullySystem, and it suits work clear enough to specify in writing. A dedicated team gives capacity, with direction coming from the client, and it suits an evolving backlog or ongoing product work. A well-defined requirement with an end fits a project. Without direction, a dedicated team fails.
Do your engineers work our hours?
Overlap is agreed at the start and written down. Where the client’s day and ours share most hours, working together is easy. Where they share only a few, the plan covers those shared hours and asynchronous work for the rest. Night shifts are not part of the arrangement. Realistic overlap is stated before the agreement is signed.
Can our own lead direct the work?
Yes. Our people join the client’s stand-up, work from its backlog and follow its review process, definition of done and branching rules even where ours differ. Where the client has no technical lead, a senior can be added to plan, review and report, while priorities stay with the business. A team without prioritised work has little to deliver, so a groomed backlog is the client’s main duty, kept in a tracker the whole team can read.
What is the minimum commitment?
Minimum terms depend on the roles. Short terms rarely cover the ramp-up, since an engineer joining an unfamiliar codebase needs time to become useful. Short specialist work is the exception. A migration, a performance problem or a single release can be scoped in weeks when the person has done it before. Notice for reducing or ending runs in both directions.
How do you handle confidentiality and our customer data?
A non-disclosure agreement and an assignment of intellectual property are signed before anything starts, and a masked copy of live data is preferred for testing. The masked copy keeps the shape of real records without exposing names, phone numbers or financial values, so developers can reproduce bugs without ever seeing a customer’s details. Production access, where necessary, is limited to named people, logged, and removed when the engagement ends, and work can stay inside the client’s own environment where policy requires it.
What does it cost, and what is included?
Pricing is a monthly rate per person, varying with seniority and skill, and it covers time, equipment, leave cover, senior code review and the documentation produced during the work. Cloud costs sit in the client’s accounts. Travel for on-site work is agreed in advance. We do not publish a rate card. Each figure follows from which roles you need and how long the engagement runs, and it is fixed in the proposal that comes after scoping.
What happens at the end of the engagement?
A planned wind-down takes place. Knowledge transfer sessions run with whoever takes over, recorded where the client wants them, and documentation and runbooks are completed before access is handed over in a set sequence. An overlap period follows. The code, accounts and documentation were the client’s throughout, so the end is a transition and nothing needs to be extracted or negotiated. Planning starts in the last month.
Can you work under our brand with our clients?
Yes, where that is agreed in writing. Agencies and consultancies often need this. Our people can work under the client’s project management, use its email addresses and stay out of the client conversation wherever the agreement says so. Misrepresenting employment is not part of it. Signing in the client’s name is not either. The arrangement is set out at the start, so there is no doubt later about who speaks in a client meeting.
Should we do this at all, or just hire our own people?
If the need is permanent, hire in-house. A monthly rate for a role that will exist for years costs more over time, and an in-house person builds context the business keeps. This arrangement fits temporary needs. Examples are bridging a resignation or a hiring cycle, a skill needed for weeks, capacity without an employment relationship, and a trial before committing to headcount. Some engagements end when the client hires.
Read before you decide.
Practical notes on the questions this service raises, not product marketing.
Staff Augmentation or a Fixed-Scope Project: Which Fits Your Work
Added engineers buy capacity you direct. A fixed-scope project buys a defined outcome. How to tell which one your work needs, and when hiring is better.
What to Put in a Staff Augmentation Agreement Before Anyone Starts
Named people, replacement terms, code ownership, notice, live data access and exit. The points to settle in writing before an augmented engineer starts.
Signs Your Staff Augmentation Arrangement Is Not Working
Swapped profiles, commits outside your repository, overnight question queues and no handover notes. How to spot a failing arrangement and what to check first.
Staff augmentation vs dedicated team: how the two differ
Compare staff augmentation, a dedicated team and a managed team with a lead on who directs work, named people, term, replacement and account ownership.
More guides on this page’s topic
- Onboarding plan for an augmented engineer: access, repo and first task
- Your only developer has resigned: how to keep the product running
- How to interview the engineers a staffing vendor puts forward
- Hire your own or augment: deciding how to add engineers
- Questions to ask a staff augmentation vendor before you shortlist
- Offshore team answers arrive a day late: fixing the time zone gap
- Your code lives in a vendor’s repository: how to take it back
- Handover plan when an engineer leaves: knowledge transfer and access
- Who manages what in a staff augmentation arrangement
- How to hire a developer without getting burned
- Offshore or onshore software development: how to decide
- In-house team or outsourced development: how to decide
Let’s Build the Right Software for Your Business
Tell us about your current operational challenge, spreadsheet bottleneck, or software requirement. An experienced engineer will review your workflow and reply within one business day.
- No obligation consultation
- Senior engineer reviews your brief
- Your operational details stay 100% confidential
Start with your requirements
Seven short steps that tell us what you need. A senior engineer reads them before anyone gets in touch.
Share your requirementsRelated services.
Custom Software and Product Engineering
When the work is defined enough to price as a project, with the delivery risk sitting with us and not with your backlog.
Software Maintenance, Support and Rescue
Taking over an application whose original developer has gone, rather than staffing a team to keep it alive indefinitely, with the code audited first.
QA and Software Testing
Independent testing alongside your developers. Test cases and automation scripts stay with you.
Technology Strategy and Product Consulting
Before staffing anything, a written view on what to build, buy or fix, and what the team should actually be working on.