Legal - Client terms

The terms the work is done under. Accepting a proposal accepts these, and the version you accepted is recorded with your acceptance.

Client terms · version 2026-08-15

Client terms

William Belle LLC · support@williambelle.co · Version 2026-08-15

These are the terms the work is done under. They cover the project itself and the private client area at portal.williambelle.co, where your quotes, your documents, and your handover live.

Accepting a proposal accepts these terms. The accept page says so, and the version you accepted is recorded with your acceptance. A later version does not change a project you have already started.

Together, an accepted proposal and this document are the agreement between us. Where the two disagree, the proposal wins, because it is the one written for your project.

The privacy policy covers what is collected and who else sees it. How access to your work is controlled covers the security of the client area in detail.


1. What I am doing for you

The accepted proposal is the scope. It names the stages, what each one delivers, and what each one costs. Work not described there is not included.

Anything you want that is outside it is a change request, priced and accepted the same way. How that works is published at the change request process.

A stage marked as needing your sign-off finishes when you have reviewed and approved it. Silence is not approval.

If I have asked, sent a reminder, and heard nothing for ten business days, I can sign that stage off on your behalf so the work you have already received can be invoiced. I have to write down why, and you see it on the stage itself, with the date and my name.

That closes the stage and nothing else. No later stage starts until I hear from you. Signing off on your behalf is not permission to keep building. The next stage is usually built on the one waiting, and I am not going to build on something you have not looked at.

If you come back and something is wrong with a stage signed off that way, section 9 applies from the day I signed it rather than the day I delivered it.

2. What you are responsible for

  • Access. The cloud accounts, repositories, and third-party accounts the work needs, at the level named in the setup guide.
  • Answers and decisions, within a few business days. Most delays on a project are here rather than in the code.
  • Your own bills. Cloud and third-party costs are charged to your accounts, in your name, and they are yours. I will tell you what to expect before anything is switched on.
  • Your material. That you have the right to give me whatever you send.
  • Everything compliance asks of your organization: your policies, your staff training, the person you name as responsible, your ongoing review of what could go wrong, and any statement you sign. See section 6.

3. What you may send in

Source code archives and project documents, up to 100 MB per file.

Not database exports. They are refused by file type when you try to send one, including inside a compressed file. This work covers the infrastructure your app runs on, not the records inside it. That boundary keeps your own clients' records out of my systems, along with the obligations attached to holding them.

If a piece of work genuinely needs the records themselves, say so before you send anything. We will agree in writing how it is handled, including a business associate agreement where health records are involved.

What I do with an archive: it is read to check that the code builds, that the database changes are included, and that no passwords or keys were left inside it. That reading happens in memory. The findings are stored as review notes; the archive itself is stored until the project ends.

4. Accepting a proposal

Typing your name on the accept form is a signature. It has the same effect as signing on paper, and you are agreeing to it being used that way.

Recorded with it: the name you typed, the time, the address it came from, the browser it came from, the version of these terms, and a fingerprint of the exact proposal. That fingerprint is what proves later which version you accepted.

An accepted proposal is final. Changing what was agreed means a new version, which you accept again. The old page then refuses acceptance, so nobody can accept a superseded version out of an old email.

Accepting does not start the work. I open the project as a separate step.

5. Fees and payment

What you owe is what the accepted proposal says. Invoices are issued against it and are due within 7 days. They are paid on the payment provider's own pages, and no card number touches my systems.

Some stages are invoiced before they start; the proposal says which. A monthly agreement runs until you or I end it, and ending it stops the work and the billing at the end of the period you have paid for.

If an invoice is more than 14 days overdue I can pause the work until it is paid. I will tell you before I do, and pausing does not cancel anything.

Prices are exclusive of any tax that applies.

6. Compliance: what I deliver and what I do not

I build the technical safeguards: encryption, access control, secret storage, network isolation, sign-in with a second step, and the written evidence of all of it. That is the part of your obligations an engineer can discharge.

Being ready to meet the rules your field imposes is not a technical question alone, and I do not deliver it on my own. What stays yours is in section 2, and it is the larger half. I do not act as your compliance officer, your lawyer, or your accountant, and nothing I deliver is legal or tax advice.

No certification is claimed for my own systems or for yours. Not SOC 2, not ISO 27001. No outside firm has reviewed the client area, which is stated in full at how access to your work is controlled.

I cannot promise how a customer, an insurer, or a regulator will judge your app. What I can do is build to the technical rules and write down what was built.

7. Who owns what

Everything I deliver for your project becomes yours once the stage it belongs to is paid: the code I write, the configuration, the infrastructure definitions, and the handover. That is an assignment of every right in it, and it needs no further paperwork.

Your cloud accounts, repositories, and domains are in your name throughout. Nothing about the arrangement ties you to me.

Two things do not transfer, and neither is specific to you:

  • My own tools and components — the general-purpose libraries, scripts, and templates I bring to every project. You get a permanent, paid-up license to keep using them in your app, including after we stop working together.
  • What I know. General knowledge, methods, and experience stay mine, which is what lets me do this work for the next client.

Third-party and open source components keep their own licenses. I will tell you what a project depends on, and the handover lists it.

Anything you give me stays yours.

8. Confidentiality

Each of us will keep the other's non-public information to ourselves and use it only for the project. That covers your code, your systems, your customers, and your commercial terms, and it covers mine.

It does not cover anything already public, anything either of us knew before, or anything a court or regulator requires be produced. If I am required to produce something of yours, I will tell you first unless the law says I cannot.

This continues for three years after the project ends, and for as long as the law requires for anything regulated.

I will not name you as a client without your written agreement, in a case study, on the site, or anywhere else.

9. What I warrant, and what I do not

I will do the work carefully and to a professional standard.

If something I delivered does not do what the proposal said, tell me within 30 days of that stage finishing and I will fix it at no charge. That is the remedy for a defect in my work.

For a stage I signed off on your behalf under section 1, the 30 days run from the day I signed it.

Beyond that, everything is delivered as it is. Software is not error-free, and I do not warrant that yours will be, that it will never go down, or that it will satisfy a third party who reviews it. Sections 6 and 2 say why.

The client area itself carries no uptime commitment. It holds copies of your material for convenience, not as your only copy, so keep your own copies of anything that matters. I can suspend access if an account is being misused or I have reason to think it has been taken over, and you will be told why.

10. Limits on what either of us owes

My total liability for a project is capped at what you paid me for it in the 12 months before the claim.

Neither of us is liable to the other for lost profits, lost data, lost business, or any indirect loss, however it arises.

You cover me for claims arising out of material you gave me, out of your own clients' records, and out of what happens to your app after the handover, where the claim is not caused by my own failure to do section 9's work carefully.

Nothing here limits liability for fraud, for willful misconduct, or for anything Ohio law does not allow to be limited.

11. Ending it

Either of us can end a project on 14 days' written notice. A monthly agreement ends at the end of the period you have paid for.

If it ends, you pay for the work done up to that point and you keep all of it — every stage delivered, the accounts, the code, and the handover. Your access to the client area ends with the project, and before it does you can ask for everything I hold for you, including a full record of every access to your material. There is no charge for that.

Sections 7, 8, 10, and 12 survive.

12. The rest

Independent contractor. I am not your employee, your partner, or your agent, and neither of us can bind the other.

Changes to these terms. I can publish a new version. The version you accepted governs your project until you accept a proposal under a newer one, so nothing changes underneath a project already running. Every version stays published at its own address.

Subcontractors. I may use them, and I remain responsible for their work and bound by section 8 for it.

Notices. Email is enough, to support@williambelle.co and to the address you sign in with.

Assignment. Neither of us assigns this without the other's agreement, except to a buyer of the whole business.

Delays outside either of our control — outages at a cloud or third-party provider, and anything genuinely beyond reasonable control — pause the obligations they affect rather than breach them.

If a clause fails, the rest still stands.

Ohio law governs, without regard to its conflict of laws rules, and disputes belong in the state and federal courts sitting in Ohio.

Questions about any of this go to support@williambelle.co, and they are welcome before you accept rather than after.

Twenty minutes, and no pitch.

I'll tell you what I'd fix first in what you've built, and why. No pitch.