Outsourcing Custom Software Development: Scope and Control
A company that outsources an internal commissions tool rarely means to hand over the commission rules. Yet when the legacy ERP returns an order with no sales rep attached, someone has to decide who gets paid, and if the contract is silent, that someone is the engineer writing the code that week. Outsourcing custom software development goes well when you hand over the building and keep four things: product decisions, final authority over architecture, ownership of repositories and accounts, and the right to accept or reject the work. The scope document is where that split is either written down or lost.
What Should Stay In-House When You Outsource Custom Software Development?
Keep the decisions that only your business can make and the assets you need to operate the software without the partner. Hand over the work that turns those decisions into tested code.
| Area | Keep in-house | Hand over | Why |
|---|---|---|---|
| Product decisions | Business rules, priorities, what ships first | Proposals, trade-off analysis, prototypes | Only you carry the consequences with sales, customers or regulators |
| Architecture | Final approval of major design decisions | Design work, recommendations, implementation | Someone on your side must be able to say no to a choice that boxes you in |
| Repositories and accounts | Ownership of code hosting, cloud, app store and third-party accounts | Member access scoped to the work | Ownership by contract is weak if the keys sit with someone else |
| Acceptance | The decision that a milestone meets its criteria | Test suites, demo environments, release notes | Acceptance is how control turns into payment and sign-off |
| Implementation | Review rights | Coding, testing, integration, deployment pipeline | This is the work you are buying |
The split is not a statement about trust. A strong partner will often have better architectural judgment than anyone on your payroll, and in scoped delivery it may lead the design. What you keep is the authority to approve, so that the decisions stay visible and reversible while you still can.
Product Decisions and Business Rules
Product decisions are the rules your business runs on and the order in which you need them. For the commissions tool, that includes how split deals are credited, when a clawback applies after a refund, and whether managers see their team’s pending payouts before the period closes. For a field-service mobile app, it includes which job types technicians can close without a customer signature and what happens when a technician edits a work order offline while dispatch edits the same one in the office.
A partner can and should challenge these rules. Engineers often find the contradictions first, because code forces every edge case into the open. The decision still belongs to a named person on your side, usually the sales operations lead for commissions and the field operations manager for the app, and the scope should say so.
Architecture Authority
Architecture authority is the right to approve decisions that are expensive to reverse: the data model, how the tool reads from the ERP, where calculation logic lives, and how the mobile app stores and syncs data offline. When you have an architect or senior engineer, that person holds approval. Without one, name who does in the contract and require that significant decisions are written up as short decision records you can read and question later.
The ERP boundary is a good test. Reading order and invoice data through a supported interface keeps the commissions tool separate from the ERP’s own upgrades. Writing directly into ERP tables may be faster to build and can break when the ERP is patched. That choice should not be made by default.
Repositories, Accounts and Credentials
Own every account the software depends on. That means the code repository organization, the cloud account, the CI/CD service, the domain, error monitoring, and for the mobile app, the Apple and Google developer accounts under your company’s legal name. The partner’s engineers get member access with the permissions their work needs.
Credentials into the ERP deserve their own line. Issue the commissions tool a dedicated service account with read access to the tables it needs, managed by your team, rather than letting the build run on a contractor’s personal login. When the engagement changes, you rotate one credential instead of reconstructing who had access to what.
Acceptance
Acceptance is the right to say a milestone is done. Keep it with the person who will live with the result: the sales operations lead signs off on a payout run that matches the agreed rules for a sample of reps, and the field operations manager signs off on the mobile app after technicians complete real jobs on test devices.
How Do You Write Scope So Control Survives the Contract?
Write scope as outcomes, boundaries and decision rights, rather than as a bare feature list. A list of screens tells a partner what to build; it does not say who decides when the screens and the business rules disagree.
A scope document that holds up over the life of a contract usually has these sections:
| Scope section | What it settles | Example |
|---|---|---|
| Outcome | What the business can do when the work is accepted | Sales ops runs the monthly payout from the tool instead of spreadsheets |
| Rule ownership | Who defines and changes business rules | Commission plans are configured by sales ops in a rules table; engineers implement the engine, not the plans |
| System boundaries | What the software may touch and how | Reads orders and invoices from the ERP through its supported interface; never writes to ledger tables |
| Decision rights | Which decisions the partner makes, which need approval | Library choices sit with the partner; changes to the data model need written approval |
| Acceptance criteria | How each milestone is tested and by whom | A payout run for last quarter’s data matches the approved calculation for a defined sample of reps |
| Out of scope | What will not be built in this engagement | Payroll export; manager approval workflow |
| Change process | How new requirements enter the scope | Requests go to the named owner, who approves impact on scope and milestones in writing |
The rule ownership line does more for control than any other. When commission plans live as configuration that your team maintains, the next plan change is an edit your sales ops lead makes, not a new statement of work. The same thinking applies to the field-service app: job types, checklists and required photos can be data your operations team maintains rather than code that only the partner can change.
The system boundaries line protects the parts of your business the software does not own. A partner that knows from day one it may only read from the ERP will design around that constraint instead of discovering it at the security review.
Where Do Fixed Scope and Changing Requirements Collide?
Requirements change most when real users touch the software, and the scope has to absorb that without moving authority to whoever is closest to the code.
Field-service work is full of these moments. Technicians testing an early build report that some jobs need two visits, which the work order model never considered. The partner has three options: build a workaround, stop and ask, or quote a change. A scope that names the decision owner and the change process makes the second option the normal one, so the multi-visit question goes to the operations owner with the partner’s recommendation and an estimate of its impact.
Two habits keep the change process honest. Ask the partner to flag any decision it makes on your behalf, even small ones, in the same log as the approved changes. Review that log at each milestone. Patterns show up quickly: a partner that keeps deciding rules for you is telling you the rule ownership section was not specific enough.
Before any of this, make sure the build is the right response to the problem. Gun.io’s essay on starting with the business problem rather than the headcount covers why fragmented data and unclear requirements are rarely fixed by adding engineers.
Which Engagement Model Fits the Control You Want?
The right model depends on who on your side can direct engineering work. Control over product decisions and acceptance stays with you in every model; what changes is who directs the engineers day to day.
With staff augmentation, outside engineers join your team, your technical lead directs their work, and architecture authority sits with that lead by default. This fits a company that already has engineering leadership and needs capacity or a particular depth, such as someone who has built offline sync for a mobile app before.
With scoped project delivery, a partner organizes and delivers a defined initiative and takes a larger part in design and engineering management. This fits a company without a technical lead, such as an operations team commissioning the commissions tool. The scope document carries more weight here, because the approval rights in it are the main way you keep architecture authority.
A small team usually serves a custom build better than a large one. One strong full-stack engineer who understands both the ERP integration and the interface the sales ops team uses often moves with fewer handoffs than a frontend and backend pair. Add a specialist when the problem calls for distinct depth, such as the offline data model on the mobile app. For a first version built to test whether the tool earns its place, the guide to MVP development covers how to size that first release.
What Contract Terms Protect That Control?
The contract should turn the split you decided into enforceable terms. A few clauses do most of the work.
- IP assignment. Copyright starts with the author, and U.S. law requires a signed writing to transfer copyright ownership. Require a written assignment to your company from the partner and every engineer or subcontractor who contributes code.
- Pre-existing code. If the partner brings its own libraries or templates, the contract should list them and give you a perpetual license to use and modify them as part of the software.
- Open-source components. Ask for a list of dependencies and their licenses at each milestone, so nothing with incompatible terms arrives unnoticed.
- Account ownership. State that all repositories, cloud resources, developer accounts and credentials are held in your company’s name.
- Approval rights. Write the decision rights from the scope into the contract, including who approves architecture changes and who signs off on acceptance.
These terms matter most when someone else reviews your software. An investor, acquirer or enterprise customer may ask you to show that you own the code and control its infrastructure, and technical due diligence goes faster when the answers are already on paper. This is general information, not legal advice; have counsel draft the clauses for your jurisdiction.
How Gun.io Scopes a Custom Build
At Gun.io, we start by understanding the problem before deciding who should solve it or under which model. For internal tools built beside an older ERP, that means learning how the business rules work today and where they live, which is often in spreadsheets as much as in the ERP. In a published brief, we describe building a finance and operations layer alongside a legacy ERP instead of replacing it; moving commission calculations into a structured workflow also surfaced missing source data in the old spreadsheet process.
Under staff augmentation the engineers build to your team’s direction. Under scoped delivery we organize and deliver the initiative ourselves, and the written scope records which decisions stay with you. The same applies to mobile work, where we support mobile app engineering under either model. We also take care of contracting and payments for the engineers involved.
Hand Over the Build, Keep the Decisions
Outsource the implementation, and keep product decisions, architecture approval, the accounts and acceptance where they can be exercised. If you are planning a custom build, talk to us about what you’re building, and bring the systems it has to work with, the rules it has to follow and the people who decide them.
Frequently Asked Questions
How Detailed Should Scope Be Before Outsourcing Custom Software Development?
Scope should be detailed enough to settle outcomes, boundaries, decision rights and acceptance for the first milestones, and it can stay lighter on later features. Many teams pay for a short discovery phase first, so the partner can read the existing systems and help write the scope before the build is priced.
Should the Outsourcing Partner Own the Architecture?
The partner can lead the architecture, especially when you have no senior engineer, but someone on your side should hold approval of major decisions. Ask for short written decision records so a future engineer can see what was chosen and why.
Is a Fixed-Price Contract Better for Keeping Control?
A fixed price controls the invoice, not the decisions. It works when requirements are stable; when they are not, each change becomes a negotiation, and partners may make small product calls themselves to avoid one. Milestone-based work with a clear change process usually keeps authority with you more reliably.
What If No One In-House Can Review the Code?
Use scoped delivery with written approval rights, and consider an independent technical review at key milestones. You can still judge outcomes through acceptance tests written in business terms, such as whether a payout run matches the approved rules.
How Do You Build Around a Legacy ERP Without Breaking Its Support?
Integrate through the interfaces the ERP vendor supports, keep the new tool’s data and logic outside the ERP, and avoid direct writes to core tables unless the vendor documents them. Check your ERP support agreement before the build starts, since custom changes inside the system can affect what the vendor will support.
Does Outsourcing Make Sense for Internal Tools?
Yes, when the tool encodes rules your team already understands and the partner can work closely with the people who use it. Internal tools such as commissions, payroll and inventory workflows benefit from engineers who ask how the work is done today, since the edge cases usually live in that process.
