Terms of Service
The clause this page explains, in its published form, alongside the rest of the site terms.
Ownership
The published position on custom code, the two categories that stay outside the transfer, and why there is no proprietary framework to be locked into.
Unless otherwise agreed in writing, on receipt of full payment for a project the client owns the custom deliverables created for that project outright. That sentence sits in Schkovl's Terms of Service, and this page exists to explain what it means rather than to add to it.
Ownership here is not a licence to use something Schkovl continues to control. It is the custom work itself: the repository, the custom code and the assets built for that engagement, handed over so the client can take them anywhere.
The trigger is payment in full for the project, not a milestone or a renewal. There is no ongoing licence fee attached to the deliverable and no mechanism by which the work reverts to Schkovl later. The same position is stated on the Apps and Platforms service page in the plainest available terms: full source ownership on payment, no proprietary framework lock-in, and a repository the client can hand to any team afterwards.
Two categories are excluded, and both are named in the same published clause. Neither is a client's build.
These two categories are the ones stated on this site. Anything beyond them would be a matter for the individual written agreement.
Ownership is only meaningful if the thing you own can be maintained by somebody else. Schkovl builds on open, standard tooling that can be handed to another team afterwards rather than on a proprietary framework only its authors can operate.
That is also why website builds here are custom code rather than a site assembled inside a hosted builder. A build on someone else's platform carries monthly builder fees, a ceiling on what can be added later, and a migration problem the day the business outgrows it.
The practical test is simple: can the repository be handed to any competent team and continue to run? If the answer is no, the ownership clause is decorative.
Ownership also has to survive the end of the relationship in a boring, practical sense. That means the deliverable runs on tooling with public documentation, its dependencies are the ones a new team would expect to find, and nothing critical is hidden behind an account only Schkovl can log into. A handover that requires a long verbal explanation is a handover that has not really happened.
Schkovl's published guide to vetting a development agency puts ownership first among the questions to bring to a kickoff call: who owns the code and intellectual property from day one?
A good answer is that the client owns the repository, the custom code and the assets on payment, with access provided immediately. A bad answer is that the agency hosts it on a proprietary framework. The difference is not a detail — it determines whether the business can change vendors later without rebuilding from zero.
The same guide flags the adjacent failure: code committed behind closed doors with no client visibility. Access to shared communication channels, the repository itself and a live staging environment is what makes the ownership claim checkable during the project instead of only at the end.
Schkovl retains the right to display completed work in its portfolio, unless the client requests confidentiality in writing. That request is a normal part of an engagement and is honoured when it is made.
In practice the published portfolio is deliberately narrow. The case studies page carries dated engagements with re-runnable measurements rather than a wall of client logos, which means a confidentiality request costs the client nothing in scope or price.
Ownership of client deliverables is separate from ownership of this website. The content on schkovl.com — text, graphics, logos, icons, images and software — is the property of Schkovl or its licensors and is not reproducible without express written permission. That is an ordinary site notice and has no bearing on what a client receives.
The ownership clause also opens with a qualifier worth reading: unless otherwise agreed in writing. The written agreement for an engagement can define something different, and if it does, that document is what governs. This page describes the default, not a promise that overrides a signed contract.
The clause this page explains, in its published form, alongside the rest of the site terms.
Where in the sequence the handover sits, and when billing starts.
The standard-tooling rule that makes a handover possible in the first place.
The practice where source ownership and framework lock-in matter most.
The five questions to ask before signing, including the ownership question.
The facts on this page were last checked against published Schkovl sources on .
Everything here is drawn from material already published on this site. If something looks wrong, our editorial standards and corrections policy explains how to have it corrected.