Software development with an outsourcing company: the contract and the first 90 days
A working engagement with an outsourcing company has a recognizable shape. In the first two weeks you get a written kickoff plan and environments provisioned in your own cloud account. After that, every sprint ends in something you can open, every week brings a written report with the hours spent on it, and every milestone ends in a demo you either sign off on or return with comments. What the contract has to settle before any of that starts is who owns the code, how a deliverable is accepted, and what a change costs.
Most of the risk in software development outsourcing is not in picking the wrong company. It sits in the clauses the contract leaves vague and in the habits the two teams fall into during the first quarter. A project that feels wrong at month six rarely broke at month six. It drifted earlier, in a week when nobody had agreed who signs off on what, and the cause is buried in a scope document nobody re-read.
This article covers the part that comes after the shortlist: what the agreement has to settle before you sign, and what the first 90 days should produce. If you are still comparing vendors, our overview of software outsourcing companies and what makes a suitable contractor is the better starting point.
We have written this from our own side of the table. Ronas IT runs projects against an internal project management standard, and most of what follows is drawn from rules our managers are held to, including the ones that put obligations on us as well as on the client.
What a software development outsourcing contract has to settle
A software outsourcing agreement usually comes in two parts: a master agreement that governs the relationship and rarely changes, and a statement of work that describes the specific build. Twelve things have to be settled between them. Three of them are the ones we see argued about later, because they are the ones both sides assume are obvious.
| Clause | What it has to say | What happens without it |
|---|---|---|
| Scope | Deliverables named one by one, with assumptions written down | Every disagreement turns into an argument about what was said |
| IP assignment | Copyright in the work is assigned to you, with the trigger named | The vendor may keep copyright in code you paid for |
| Acceptance | A pass signal per deliverable, not just a name | Nothing is ever formally finished |
| Change control | Written approval and re-estimation before extra work starts | Scope grows quietly and the budget follows |
| Warranty | Which defects are free fixes and for how long | Every bug turns into a billing argument |
| Confidentiality | What counts as confidential and how long it binds | Much harder to get recourse if your idea travels |
| Payment | Trigger, currency, invoicing cycle, late terms | Cash flow surprises on both sides |
| Termination | Notice period and what the vendor must hand over | You can leave, but not with a running system |
| Data and access | Whose accounts hold the infrastructure and the data | Your product lives inside someone else's account |
| Data processing | Where personal data is involved, a written data processing agreement naming the data, the purpose, and whose instructions govern it | Processing personal data with no such agreement can be a breach on its own |
| Liability | What each side is on the hook for, and up to what amount | One incident turns into an open-ended argument |
| Governing law | Which country's law applies and where disputes are heard | The fight about the forum costs more than the disagreement |
Four of the twelve belong with your lawyer rather than with your delivery plan. Confidentiality, payment terms, liability and governing law are closed by counsel on both sides, and we have nothing more useful to say about them than your lawyer does. One of them still deserves a careful read: the liability cap and its exclusions are negotiated on most deals.
One row on that list is a legal requirement. If the work touches personal data, and either side is established in the EU or the product serves or tracks people in the EU, Article 28 of the GDPR requires a written data processing agreement: what data is processed, for how long, for what purpose, which obligations sit with which side, and the rule that the vendor processes that data only on your documented instructions. A confidentiality clause does not cover this, and a vendor that works with EU clients will usually have a template ready. The sections below take the ones that decide how the engagement actually runs.
Who owns the code
Ownership does not follow the invoice. Section 101 of the US Copyright Act, which governs work created on or after 1 January 1978, says a commissioned work can be a work made for hire only if both sides sign a written agreement calling it one and the work falls into one of nine categories: contributions to collective works, parts of audiovisual works, translations, supplementary works, compilations, instructional texts, tests, answer material for tests, and atlases. Software is not on the list. That is why custom development contracts transfer ownership through an explicit assignment of copyright rather than by calling the work made for hire. The clause should also name what fires the transfer, usually signature, payment of the milestone, or acceptance of the deliverable, because until that moment the copyright has not moved. Rules differ by jurisdiction, so have counsel read the assignment against the vendor's country as well as your own.
The clause is the legal half. The practical half is where the product physically lives. We start every project in the client's own cloud account rather than ours. Our DevOps team sets the environment up there, and the repositories are opened there too, before anyone writes a feature. Production error tracking is also created in the client's account. Both the accounts and the code stay yours, which is what makes an exit clause enforceable in practice. That also removes the main reason people ask for source code escrow, where a third party holds a copy of the code in case the vendor disappears. You already have the original rather than a promise of a copy.
How deliverables get accepted
Acceptance criteria turn a deliverable from a name into something that can pass or fail. A screen, an API, a migration script, or a test report each needs a stated pass signal, and the contract should say what happens when a deliverable is rejected. Our own standard puts a rule on the client side too: a refusal to accept work has to come with specific comments, and “I don't like it” is not one of them. It also splits bugs into warranty work and new requirements, so the classification is settled before the first argument rather than during it.
How scope changes are priced
Assume the scope will move, and agree in advance what moving costs. Our managers cannot start work outside the agreed scope without written approval, and critical decisions need written confirmation from the client. Design is where this gets tested first: a mockup tweak that reads as cosmetic can add development days. We raise design changes as they come up, during pre-sale and again while the interface is being drawn, and we re-price at a point both sides fixed in advance instead of after every comment. A note on the mockups counts as answered once the change is in the file, and a stage does not hand over while notes are still open.
What the estimate is actually promising
An estimate before design is a conditional statement, not a commitment. Ours arrives with the assumptions it stands on written down next to the number, so you can check them against your own project. When you read a vendor's number, look for the same thing, and treat any figure without stated assumptions as a sales pitch.
If you want a firmer number, buy the scope first. Our analysis phase starts at $2,000 to $3,000 and runs from one to two weeks. You come out of it with the user stories, the flows, a feasibility read on the parts that look hard, and a scope someone can put a price against. That is the same groundwork a discovery phase covers, and the document it produces is what a fixed price can honestly be attached to. Our guide to estimating website and mobile app development covers how the number is built.
How the engagement ends
Read the termination clause as if you were already leaving. It should name a notice period, say what happens to work in progress, and list what the vendor hands over: repository access, infrastructure credentials, documentation, and any accounts opened on your behalf. A vendor confident in its work will not resist this part.
“Most of the negotiating effort I see goes into the parts about staying together, and almost none into leaving. So ask where the cloud account sits and whose name is on the repositories. If nobody on the vendor side can answer that quickly, you have learned something more useful than anything in the loyalty clauses.”
Roman Surikov, CEO at Ronas IT
Which engagement model fits
The commercial shape of the deal decides who carries the risk of the unknown. Three shapes cover almost every project, and the right one depends on how well the scope is defined rather than on how much you want to spend.
| Model | Best when | What you carry | Ronas IT starting point |
|---|---|---|---|
| Fixed-scope project | Scope is written down to acceptance criteria | Change requests, because every change is a renegotiation | Basic MVP from $15,000, from 4 weeks |
| Dedicated team | The product will keep evolving for months | Direction, since idle capacity is still billed | From $12,000 per month |
| Team augmentation | You have a working process and need specific skills | Management, because your leads run the work | $60 per hour |
Those starting points are for a general build. Industry tiers on the same price list start higher, with fintech and marketplace products from $75,000 and healthcare from $60,000, so check the tier that matches your product.
A hybrid usually beats a pure model. Buy the analysis phase at a fixed price, attach a fixed price to the specification it produces, which for a first release is usually an MVP build, then move to a monthly team once the roadmap outlives that release. The combination to avoid is a fixed price on a scope nobody has written down, because the vendor prices the risk into the number and you pay for uncertainty twice.
The kickoff plan: what a project should start from
A project starts from a written plan, not from a call. Ours covers the product's purpose and business value, the target users, the feature set with priorities, third-party services, the stack we build on including infrastructure and testing, the state of the design, the metrics that will count as success, the schedule and milestones, the risks and constraints, roles and responsibilities, the communication format, and a check that the access, data, and resources needed to start are actually in place.
Success criteria go through two people before work begins. The project manager confirms them with the client, and the tech lead checks them separately for feasibility, internal contradictions, and room for optimization. The split is written down: the manager owns the client side, requirements, priorities, change requests, and release expectations, while the tech lead answers for the engineering requirements, who sits on the team, and the plan for building it. When those two roles blur into one person, feasibility stops being checked by anyone. This is also the practical argument for a full-cycle team over separate design and development vendors: the handover between stages has an owner.
“My part of kickoff is unglamorous. I read the success criteria and ask whether they can be built the way they are written. Quite often two of them quietly contradict each other, because they were agreed in different meetings and nobody had put them side by side. That takes an hour to sort out in week one. In month three it is a rebuild.”
Evgeny Leonov, CTO at Ronas IT
That review applies to whatever the client brings, including finished work. On Lainappi, a peer-to-peer rental app for the Finnish market, the client arrived with a ready-made design and asked us to build it. Our review found problems with the logic, the visuals, and how difficult the screens would be to implement, so the first task became rebuilding the design rather than coding it. We also turned down one requested feature, a section where users could post requests for items they wanted to rent, because the scenario was unlikely enough not to earn its build time. In both cases our job was to show the cost and the risk before the build started. Both conversations belong at kickoff rather than at acceptance.
Requirements then have to survive the trip into the tracker. Every requirements ticket we write has to name the job, the result that counts as done, the way it will be checked, and the material behind it: a screenshot, a design link, a reference. It sits in the tracker as a template rather than as a guideline, because guidelines get skipped on busy weeks. If you are preparing the input yourself, our guide to writing an IT project description covers the same ground from the client side.
The first 90 days, stage by stage
The first quarter should produce working software, a rhythm, and evidence. Here is what each stage should have delivered by its end, and what you should be doing while it runs.
| Stage | What should exist by the end | Your job |
|---|---|---|
| Days 1 to 14 | Signed-off kickoff plan, one named point of contact, environments provisioned in your cloud account, repositories scaffolded, first sprint planned | Grant access, name your decision maker, confirm the success criteria |
| Days 15 to 30 | First sprint delivered as something you can open: a dev server update, an interface you can test, or designs in the mockups. First weekly report with hours spent | Open it, use it, and send specific comments rather than impressions |
| Days 31 to 60 | A steady sprint cadence, the first milestone demo that ends in either a signature or a list of comments, an account manager check-in outside the project manager's reporting line | Attend the demo with both your technical contact and your decision maker |
| Days 61 to 90 | Releases going out on a versioning scheme you can read, a backlog you recognize, and defect numbers reported in a way you can interpret | Check that reported progress matches what you can open yourself |
Sprints run one to three weeks and each one has to end in something the client can open, which is a deliberately higher bar than a status update. An unfinished screen ships with a stand-in pulled from our shared component set, so a demo never lands on a blank page that looks like a bug. Both rules exist to keep the demo honest rather than impressive.
Our own release tags carry the semantic version plus the year and ISO week of the release. That is a house convention rather than an industry standard, and any scheme works as long as the date is in it. What you want is to be able to read a tag and know whether the fix you are waiting for is in it.
Ask about defect numbers in the same conversation. A raw count of bugs rewards a team that ships less, so we divide defects by delivery volume instead, counting everything in the tracker including the closed items. A vendor quoting you a bug count with no denominator is showing you a number that cannot go wrong.
What the vendor owes you every week
Our project management standard rests on five principles: the client always knows the real state of the project, the manager sees problems before they turn critical, every agreement exists in writing, the manager owns the outcome instead of blaming circumstances, and the manager understands the business goal rather than only the task list. Those principles turn into a handful of commitments you can check against any vendor.
- A reply within 24 hours on business days. An answer, which can be an acknowledgement that names when the real reply is coming.
- One point of contact. Routing questions through several people is how context gets lost.
- A weekly report. Progress, hours spent, and the plan for next week, in writing.
- Final documents as files, not as links to editable ones. A PDF cannot change after you approve it.
- An account manager who checks in separately. Roughly every two weeks, outside the project manager's reporting line, and required to raise concerns rather than sit on them.
The last one matters more than it looks. If the only person who can tell you a project is in trouble is the person responsible for it, bad news travels slowly. Which manager takes a new project is decided on the delivery side rather than by whoever closed the deal, for the same reason.
What you owe the vendor
Client-side obligations are the half of the engagement that contracts usually skip, and the half that stalls projects. Three of them are worth writing into your own calendar.
- The same 24-hour reply. Our onboarding asks the client for it in return, because a team waiting on a decision burns paid time.
- Both the technical contact and the decision maker at key acceptances. Where those are different people, a deliverable approved by only one of them risks being re-opened later.
- Specific feedback, closed in the same place it was raised. A note on the mockups stays open until the change is in the file, which is how either side can see what is still outstanding.
Silence is treated as a risk rather than as consent. If two deliverables in a row come back without comment, we log it and raise it internally, because a quiet client is usually not a happy one.
What happens when it goes wrong
Most long engagements have a bad month. What separates recoverable from terminal is whether there is a route for the problem to travel. Ours has three steps, and the trigger for the first one is deliberately sensitive: the manager escalates at the first sign the client doubts the direction, measured as a change from that client's own baseline rather than an absolute level of irritation. A normally terse client going quiet counts.
- The project manager raises it with the account manager, who is already in touch with the client independently.
- If it does not resolve there, it goes to the CEO.
- Where the conversation has turned emotional, it moves to a call whose only purpose is to listen and capture every comment. The reasoned answer goes out in writing afterwards.
Two things our standard rules out: replying to an angry email straight away, and offering a binary choice. Asking a client whether to continue or stop while they are annoyed invites them to stop. The manager proposes a concrete next step instead.
Some problems are nobody's fault and still need an owner. On Lainappi, two of the Google services the app relied on were retired while the project was live, and replacing them was in nobody's original scope. What mattered was who had to absorb the change, which is why the support arrangement deserves as much reading as the build contract.
Red flags in the proposal and the contract on your desk
You can read most of this off the paperwork before you ever sign. Five signals are worth checking, and each maps to something above. They apply to the vendor you have already chosen; if you are still comparing candidates, the criteria in our rundown of software outsourcing companies come first.
- A number with no stated assumptions. No proposed stack, no team shape, and no list of the external services the build depends on means the estimate is a guess dressed as a quote.
- Deliverables listed without acceptance criteria. A named screen with no pass signal cannot be finished, only abandoned.
- Infrastructure in the vendor's accounts. Convenient at the start, expensive at the exit.
- No change procedure. If nothing describes how extra work gets approved, extra work will get approved on a call and invoiced later.
- One person doing everything. When the same individual sells, manages, and reviews feasibility, nobody is checking anybody.
One honest disqualifier from our side, since the reporting rhythm above is not free. Project management is a separate line on our price list, quoted on top of development from $400 per week, because someone has to run the planning, the reports, and the acceptance. If you already have a project manager who will own scope, priorities, and sign-off, do not buy a second one: take the hourly augmentation route and keep the process you have. The managed route is worth its overhead when you want the outcome owned rather than the seats filled, and our dedicated development team page describes what that looks like.
What to do next
If you are about to sign or have just signed, work through these in order. Each one is cheap now and expensive in month six.
- Have the intellectual property clause written as an assignment with the trigger named, rather than as the phrase work made for hire.
- Get the answer about cloud accounts and repository ownership in writing before the first commit lands.
- Ask what a valid rejection looks like: what has to be in it, how long you have, and who pays for the re-estimation that follows.
- Get the change procedure in writing: who approves work outside the agreed scope, and when it gets re-estimated.
- Name your decision maker alongside your technical contact, and book both of them into the milestone demos now, while the calendar is still empty.
- Agree the reply window in both directions, and say out loud what happens when either side misses it.
- Buy an analysis phase before committing to a fixed price on anything larger than a proof of concept.
- Put a reminder in your calendar for day 30 with one question on it: can you open what has been built, or can you only read about it?
A good contract will not rescue a bad team, and a good team will still drift without one. What the two together buy you is the ability to tell, by the end of the first quarter, which one you have. You can see how we structure the work end to end on our custom software development page, or read the stage-by-stage version on how we work.
Frequently asked questions
What should a software development outsourcing contract include?
What is a statement of work in software outsourcing?
Who owns the code when you outsource software development?
How long does it take to onboard an outsourced development team?
Fixed price vs time and materials: which works better for outsourcing?
How much does it cost to start working with an outsourcing company?
Do I have to pay for project management if I already have a PM?
How often should an outsourcing vendor report progress?
What happens if you want to end an outsourcing contract early?
Related posts
Related Services
Custom Web App Development Services
Build secure, scalable web applications with Ronas IT’s custom web app development services. Our team covers the full cycle — from concept and UI/UX design to development, testing, and ongoing support — using leading tech like React and Laravel. With 200+ custom apps delivered across various industries, we ensure intuitive interfaces, smooth integration, and solutions tailored to your business goals.
CTO as a Service for Startups
Accelerate your startup’s growth with Ronas IT’s CTO as a Service. Get expert tech guidance, architecture design, comprehensive audits, and ongoing strategic support — without hiring a full-time CTO. We help align technology with your business goals, ensure secure and scalable systems, and optimize your development processes so you can focus on launching your product and gaining market traction.
Dedicated Development Teams
Ronas IT’s dedicated development teams consist of skilled specialists — including developers, designers, and project managers — who focus exclusively on your product. Get fast onboarding, flexible team scaling, transparent workflows, and ongoing support. Skip hiring hassles and keep your attention on business growth while we deliver quality results on time and within budget.