Who Owns Custom Software Code and Data? A Client Portal Checklist

You are about to pay for a client portal, and nobody has told you what you will own when it launches. Who owns custom software code and data is the question that decides whether you can leave, hire someone else or sell the business with the system intact. For client portals for small service businesses, ownership has four parts: the code, your data, the accounts behind the integrations, and the hosting. Each one is settled in a different clause. Below is how each works, what a subscription never hands you, and the questions to ask before you sign.

The short answer: four things, four different clauses

Paying for software does not automatically make you the owner of it. Ownership is whatever the contract says, and a contract that is silent usually favors the person who wrote the code.

Here is how the four pieces usually split in a custom build:

• Code: owned by you only if the agreement says so in writing, by assignment or by a work-made-for-hire clause.
• Data: your customers, documents, messages and records. They are yours in any sane agreement, but you still need a way to get them out.
• Integration accounts: payment processor, email sender, text-message provider and accounting links. These should sit under your login, not the developer's.
• Hosting and subscriptions: the servers and third-party services the portal runs on. These are recurring bills, and someone has to hold the account.

Our stated position is that you own what we build under the project agreement. That is a position about code and deliverables. It does not erase the other three rows, so we walk through each one before work starts. Nothing here is legal advice. Have your own attorney read any agreement before you sign it, ours included.

Code: why "I paid for it" is not enough

Copyright in software starts with the person who writes it. The U.S. Copyright Office explains in Circular 30 that a "work made for hire" makes the hiring party the author and owner. That happens in two situations: the creator is an employee doing regular duties, or a certain type of work is created under an express written agreement.

The second situation is the one that catches business owners. An outside developer is not your employee. The Circular describes commissioned work as qualifying only for certain types of work, under a written agreement. Custom software does not obviously fit those types. So the usual fix is a plain written assignment: the developer transfers their rights to you in a signed document.

If your contract has neither, you may hold only a license to use the portal. That license can be narrow. It may not let another developer edit it, or let you copy it to a second location.

What "owning the code" should actually include

A real handover is more than a zip file on the last day. Ask for:

• The full source code in a repository you control, with the history of changes.
• Setup notes: how to run it, which services it calls, and which settings it needs.
• The database structure and any scripts that load or migrate data.
• A list of every outside library and its license.

That last item matters. Most modern software is assembled from open-source libraries, which come with their own license terms. No developer can assign you ownership of someone else's library. What you should get is a clear list of what is included and the right to keep using it.

Whose tools are in the build?

Developers often reuse their own internal components across projects. That is normal and can lower your cost. Ask the agreement to say that the finished portal is yours, and that any reused component comes with a permanent license to use and modify it inside your portal. If a clause reserves "background tools" to the developer, read that clause twice.

Your data: owning it and getting it out are different things

Almost every agreement says the customer owns the customer's data. The problem is practical. Data sitting in a database is not much use if you cannot export it in a form another system can read.

Portability is a known hard problem, not a vendor excuse. The Federal Trade Commission announced a 2020 workshop on data portability and noted that it raises challenges, including how data moves from one service to another. Standards bodies treat it the same way: NIST covers portability and interoperability as their own topics in its cloud computing standards roadmap (version 2, 2013). That document is old, so read it as background, not current guidance.

For a portal, a usable export covers more than a spreadsheet of names. Check each of these:

• Records: clients, contacts, cases or jobs, notes and status history, in CSV or a similar open format.
• Files: every uploaded document, with its original name, date and the client it belongs to.
• Messages: portal conversations and who sent them, not just the latest thread.
• Audit trail: who viewed, signed or approved what, and when.

Then test it. Ask for a sample export in the first month, before you have 2,000 documents in the system. A restore from backup into a clean environment is the better test, because it proves the data is complete and not only downloadable.

One more point: customer data in a portal often includes personal or regulated information, such as tax or health details. Who may hold it, and for how long, is a question for your accountant, attorney or compliance adviser. We build the system. We do not advise on the rules.

Integrations, hosting and subscriptions: the bills outside the build

A portal rarely runs alone. It sends email, takes payments, texts a reminder or posts to your accounting software. Each connection has an account, and the account has an owner.

The rule we work from: accounts that hold your money, your customers or your domain go in your name. That includes your payment processor such as Stripe, your accounting file such as QuickBooks, your domain registrar and your email-sending domain. The developer gets access, and you can revoke it. If the developer's own account is the one connected, you cannot fire the developer without breaking the integration.

Hosting works the same way. Where the portal runs, plus the database, file storage and backups, is a recurring cost. It is not part of a one-time build price, and we do not resell it. Hosting, third-party subscriptions and ongoing support are scoped separately in our proposals. You can hold the hosting account yourself, or give us access to manage it. Either way, the proposal should name the provider, the account holder and the monthly cost.

Third-party services deserve their own line. Text-message providers, e-signature tools, mapping services and AI model providers bill by usage. A portal that looks cheap at 20 clients can cost noticeably more at 200, so ask for the usage-based items listed separately. If an AI feature drafts replies or reads documents, ask where a person reviews its output before a client sees it.

For a worked example of a build with outside connections, see the booking site and captain's CRM we built for Sand Bar Joe's, which is a customer-facing site tied to an internal tool. The charter-specific version of this question is in our post on a customer portal for shore charters and tour operators.

What a white-label subscription does not give you

A white-label portal is someone else's product with your logo and colors on it. It can be a fine short-term answer. Just be clear about what you are renting.

In a typical white-label subscription, you do not receive:

• The code. You hold a license to use the service. The vendor owns the software and can change it.
• Control of the roadmap. A feature you rely on can be repriced, moved to a higher tier or removed.
• A complete export. What you can pull out is whatever the vendor built an export button for.
• The workflow. The portal follows the vendor's model of a client, not the steps your staff actually follow.
• A clean exit. Your branded login page, your client URLs and your clients' habits belong to a product you cannot take with you.

These are common patterns, not a rule for every vendor. Read the terms of the specific product, especially the sections on termination, data return and price changes.

This is not an argument that you should always build. Subscriptions are cheaper to start and faster to launch. Our post on what three years of a portal subscription versus a custom build costs works through the money, and choosing between custom software and a subscription covers which problem to fix first. Ownership is one input to that decision, alongside price and fit.

Questions to ask before you sign

Bring these to every proposal, ours included. Good answers are short and written down.

1. Who owns the finished code, and does the agreement say it by assignment or work-made-for-hire language?
2. When do rights transfer: at signing, at final payment or at launch?
3. Will you get the source repository, setup notes and a list of outside libraries and licenses?
4. Which components does the developer keep, and what license do you get to them?
5. What can you export, in what format, and can you test it in the first month?
6. Which accounts (payments, email, text, domain, hosting) sit under your login?
7. What are the monthly costs outside the build, and who is billed for each?
8. If you stop working with the developer, what happens to hosting, and how long is the handover?
9. Who maintains the portal after launch, and is that support priced separately?
10. Does anything in the agreement stop you from hiring another developer to extend the portal?

Two of these are easy to skip. Question 2 matters because some agreements transfer rights only after the final invoice is paid, which is reasonable but should be stated. Question 10 matters because some contracts bar you from using the code with anyone else, which defeats the point of owning it.

What we put in writing

Our stated position is simple: you own what we build under the project agreement, and the things outside the build are scoped separately. That means hosting, third-party subscriptions and ongoing support appear as their own lines in the proposal. We do not resell hosting, and we do not bundle it into a build price where it hides.

The same applies to larger systems. The WRAPT wholesale operations platform has a 9-stage lead-to-delivery pipeline, a client portal and a support hub with the TAMI web-chat agent. A system with that many connected parts is exactly where the account and export questions above matter most. If you want a portal built around how your office already works, our customer service software and client portal work is the place to start.

For a sense of scale, our custom-app tiers run from $15,000 to $100,000+, depending on how many roles, integrations and workflows the portal needs. We can only price a portal after we know what you do today.

What we do not know: your jurisdiction, your industry's record-keeping rules and your existing contracts. Those need your attorney and your accountant, not us.

Frequently Asked Questions

Who owns custom software code and data after the project is finished?

It depends entirely on the agreement. Code ownership transfers to you only if the contract says so in writing, usually through an assignment or work-made-for-hire clause. Your data is normally yours, but you need a tested export to prove you can move it. Have your own attorney confirm both points before you sign.

Does paying a developer mean I own the software?

Not automatically. Copyright starts with whoever writes the code, and the U.S. Copyright Office says commissioned work counts as made for hire only for certain types of work under a written agreement. Without a signed assignment you may hold only a license. Ask for the transfer to be written out, along with when it takes effect.

Can I take my client data with me if I leave a portal subscription?

Only what the vendor lets you export. Check the terms for data return on termination, the export formats and any fee or time limit. Test an export early. A spreadsheet of names is not the same as files, messages and history, so confirm the full record set is covered.

Who pays for hosting and third-party services on a custom portal?

You do, as a separate cost outside the build price. Hosting, text-message and e-signature services and similar subscriptions are billed monthly or by usage. Ask the proposal to name each provider, who holds the account and what it costs, so nothing is billed to you later without warning.

Prices in this article are starting ranges published on iolab.co/pricing. Hosting, third-party subscriptions and ongoing support are scoped separately in your proposal.

Talk through ownership before you commit

If you are comparing a portal subscription with a custom build, send us the proposal you are weighing, or ask us for ours. We will go through who owns the code, the data, the accounts and the hosting line by line. We are based in Medford and work with businesses across Burlington County, South Jersey and the Philadelphia area, and with clients nationwide.