What Does Source Code Delivery Actually Include, and How Do You Test It?

A company we spoke with had paid for a bespoke order system four years earlier and had the contract to prove they owned it. They also had a zip file on a shared drive, delivered on the last day of the project, which nobody had opened since. When they went to add a second warehouse and asked another team to quote, the answer came back within a week: the archive contained the application code but no database structure, no configuration notes and no build instructions. It could not be started. On paper the delivery had happened. In practice the system was still only maintainable by the people who wrote it.

Delivery is four parts, and the code is only one

Parts three and four are the ones quietly dropped from most handovers, and they are the two that decide whether the other two are usable. A repository without a deployment procedure is a description of a system rather than the system.

What it costs when the handover is incomplete

The consequences are commercial rather than technical, and they arrive in a predictable order:

• You cannot get a second quote. No competent team will price work on code they have not seen, so every change is a single-supplier negotiation and you have no reference point for whether the price is reasonable.
• Small changes queue behind the supplier's other clients. This is not bad faith; it is capacity. But your production issue sits in someone else's backlog and you have no way to add capacity of your own.
• Continuity risk concentrates in a few people. If the two engineers who know the system move on, the knowledge goes with them whether or not the company still exists.
• Replacement starts from zero. With a complete handover, a new team reads what exists and rebuilds selectively. Without one, they reverse-engineer behaviour from screens and start again, and the years of business rules encoded in the old system are rediscovered one bug at a time.
• The asset does not transfer. In a sale or an audit, software you cannot demonstrate control over is a dependency on a supplier rather than something the business owns.

The cold-start test

There is one test that settles the question, and it takes a day. Run it before final payment if you can, and annually after that if the system matters.

1. 1. Take the delivered package as it stands

   Whatever you were given: repository, schema, documents, procedure. No additions, no follow-up emails, no phone calls to the original developer. The point of the exercise is to find out what the package is worth on its own.

2. 2. Give it to someone who did not build it

   An in-house engineer or a third party. Their unfamiliarity is the instrument. Anything obvious to the original team and absent from the documents will surface within the first hour.

3. 3. Install into an empty environment

   A clean server or a local machine with nothing pre-configured. Note every step that required a guess, and every credential or setting that was not in the documentation but turned out to be necessary.

4. 4. Load a copy of the data and exercise the system

   Restore a backup into the fresh install, then run the three or four transactions the business depends on daily. Confirm scheduled jobs run and that integrations either connect or fail with a clear message rather than silently.

5. 5. Write down what was missing

   That list is the real handover gap, and it is far easier to have it filled while the commercial relationship is live. Repeat the test after any major release, because documentation drifts out of date faster than code does.

The same exercise doubles as a disaster recovery rehearsal, which is why it pairs naturally with the restore testing described in where your data is stored.

Clauses worth reading before you sign

• What transfers, and when. Whether rights in the bespoke work are assigned or licensed, and whether that happens per milestone or at final payment.
• Repository access during the build, not only at the end. If the code exists somewhere you can see from week one, an incomplete handover cannot happen quietly.
• Third-party components listed. Open-source libraries stay under their own licences and that is normal; what matters is that the list exists and nothing in it restricts your use.
• The right to use another supplier. An explicit statement that you may hire anyone to modify or maintain the system, with no penalty and no loss of warranty on the untouched parts.
• Handover contents defined as the four parts above, rather than the word "code" alone.
• No dependency on continued maintenance. If the system stops working when a support contract lapses, you were renting it. Ask the question directly and get the answer in writing.

Ownership without portability is not ownership

A contract can transfer everything and still leave you stuck, because the constraint is not always legal. Four properties decide whether a codebase can actually change hands:

• Standard technology. Widely used languages and frameworks mean the pool of people who can maintain it is large. A proprietary in-house framework narrows that pool to one company by construction, whatever the contract says.
• Configuration outside the code. Environment settings, credentials and endpoints held as configuration rather than compiled in, so a second environment is a settings change rather than a code change.
• A schema that explains itself. Named tables and columns, real foreign keys, and no fields whose meaning depends on knowing which developer added them.
• A repeatable build. One documented command sequence, or better a scripted one, that produces a running system. If the build only succeeds on one laptop, the system lives on that laptop.

These are the same properties that keep maintenance costs predictable over the years after go-live, which is covered separately in what software maintenance actually costs.

Where escrow fits

Source code escrow places a copy of the code and deployment material with an independent party, to be released to you on agreed conditions such as the supplier ceasing to trade. It is a reasonable arrangement when a small supplier runs something critical to your operations and full delivery up front is not on the table. Two limits are worth knowing. An escrow deposit is only as current as the last time it was updated, so the agreement should tie deposits to releases. And escrow returns code, not understanding — if the documentation and deployment procedure are not deposited with it, you have inherited the same problem in a safer building. Where full delivery is available, it makes escrow unnecessary rather than complementing it. For the avoidance of doubt: we do not offer escrow, and we have no arrangement with any escrow provider. The code is handed over at each step, so nothing stays in our custody for a third party to hold.

How we handle it

Repository access from the first commit rather than at the end. The schema and migrations are part of the repository, not a separate favour. Configuration and deployment are documented as the system is built, because documentation written at handover is written by people who have stopped noticing what is non-obvious. The licence is perpetual with unlimited users and no per-seat charge, and maintenance at 12–25% of build cost per year is optional and not a condition of the system continuing to run. Delivery bands are $3,000–6,000 for a focused module over 2–4 weeks, $8,000–15,000 for a multi-department system over 4–8 weeks, and $20,000+ for platform scope over 3–6 months.

The same handover discipline applies across the systems we run: Elevatora SAHA for lift maintenance and field service, Elevatora İMALAT for lift-component manufacturing, SEMP Group for group-wide operations, and PAP for pharmaceutical import and export process tracking.

If you already have a system and have never opened the handover archive, start with the cold-start test rather than a new project. Request a quote, read how to evaluate a software supplier, or compare bands on the pricing page.

Frequently asked questions

What should a source code handover include?

Four parts. The readable source code with its version history; the database schema with the relationships and any migration scripts; documentation covering configuration, integrations and known constraints; and a deployment procedure that installs the system from scratch. Code alone is the part people ask for and the part that is least useful on its own.

How do you test whether a system has really been handed over?

Run a cold start. Give the delivered package to an engineer who did not build the system and ask them to install it in an empty environment and load a copy of the data, without contacting the original developer. If it runs and the data is intact, the handover is real. If they need a phone call, it is not.

What happens if the source code is not delivered?

Every change goes back to one supplier at whatever price and timeline they set, because nobody else can quote for work they cannot see. If the supplier stops trading, changes direction or simply becomes slow, you have an operating system you cannot modify, and the replacement project starts from a blank page rather than from your existing code.

Do we own the code if we paid for the development?

Not automatically. Ownership depends on what the contract assigns and when. Some agreements transfer rights on final payment, some grant a licence to use rather than ownership, and some assign the bespoke work while third-party libraries stay under their own open-source licences. Read the assignment clause and the timing rather than assuming.

When is source code escrow worth arranging?

When the system is critical to operations and the supplier is small enough that its continuity is a real risk. Escrow places a copy with an independent party, released on agreed conditions such as insolvency. It is a fallback for the code, not a substitute for documentation, and an escrow deposit nobody has ever tested restores nothing.

Does KodDelta deliver source code, and is the licence limited by user count?

Yes to delivery, and no to user limits. The source code, the schema, the documentation and the deployment procedure are handed over. The licence is perpetual with unlimited users and no per-seat fee. Maintenance is optional at 12–25% of build cost per year and is not a condition of keeping the system running.