Terms of service — Anyfront

These are the terms for Anyfront’s engineering services: the free check, audits, sprints, retainers and quoted projects. They are in plain English, because you should be able to read what you are agreeing to. Where a term exists to protect us rather than you, it says so.

If you are a customer of the Anyfront website service, your terms have not changed. They are at /terms/website.

Who you are dealing with

Anyfront is a service of Anystack G.K. (Anystack合同会社), a company registered in Japan. In these terms, “we” and “us” mean Anystack G.K., and “you” means the business that accepts a proposal or requests a free check. Your contract, invoices and receipts are with Anystack G.K.

The work is performed by Aaron Culbert. Nobody else works on your engagement without your written agreement. That is the point of a principal-led service: you know who has access to your code, and who answers for what comes back.

“In writing” includes email, so a written confirmation, rejection or notice never needs anything more formal than a reply.

Scope

The scope of every engagement is what the accepted proposal says it is: the work, the deliverables, the price, the dates and the access needed. The schedule below sets the standard shape of each offer, and the proposal fills in the detail.

If the proposal and these terms disagree, the proposal wins on scope, price and dates, because it is the more specific document. On everything else these terms apply, unless the proposal names the clause it changes.

Work outside the agreed scope is never started on a guess. We tell you, and it is quoted, or added to a retainer, only when you agree.

Why: a fixed price is only fair to both sides if the scope it buys is written down.

Offer schedule

Prices are published on the pricing page in US dollars, Australian dollars and Japanese yen, each set in its own currency. They exclude GST / consumption tax where applicable. The accepted proposal states the price and the currency you are invoiced in.

Offer	What it includes
Code and product audit	Written report, business-impact ranking, remediation plan and a 60-minute readout. Delivered in 5–10 business days from access granted. Read access only.
Production-readiness sprint	2 weeks of work, with a fixed scope taken from the audit findings, delivered as pull requests (PRs).
Advisory retainer	Up to 4 hours a month: async review of PRs and decisions, and a monthly call.
Engineering retainer	Up to 20 hours a month, one active request at a time.
Fractional retainer	Up to 40 hours a month, roadmap and architecture ownership, and a weekly call.
Modernisation / tech-debt project	Quoted after an audit or a discovery call. The proposal sets the scope, milestones and price.

The free check costs nothing and has its own section below.

Accepting a proposal

A proposal is accepted when you confirm it in writing or when you pay for it, whichever happens first. From then on, the proposal and these terms together are the contract.

Why: some clients sign and some just pay. Either way, there should be no doubt that an agreement exists, or about what it says.

When work counts as delivered

Audits. An audit is delivered when the report has been sent and the readout has taken place. If you find a factual error in the report, something we got wrong about your code, product or setup, tell us within 5 business days of delivery and we will correct it in one round of revisions. Disagreeing with a judgement is welcome in the readout, but it is not a factual error.

If a time for the readout cannot be found within 10 business days of the report being sent, the audit counts as delivered when the report was sent, and the readout stays on offer for 30 days.

Why: a report is only useful if it is accurate, and a fixed price is only possible if revisions come to an end.

Sprints. Sprint work arrives as PRs. Each PR is accepted when you merge it, or 5 business days after we deliver it, unless before then you reject it in writing and say how it does not match the agreed scope. We then fix the mismatch and deliver it again, and the 5 business days start over.

Why: you stay in control of what reaches your codebase, and the sprint still has an end. A rejection has to point at the agreed scope so that acceptance cannot turn into a second, unpaid round of scoping.

Changes we merge under delegated access. Where you have chosen delegated access (see “Data handling and repository access”), a change we merge ourselves is delivered and accepted as the proposal’s access-mode schedule says, because there is no PR for you to merge.

Retainers and projects. A retainer request is done when its PR or written answer is delivered. A quoted project is accepted milestone by milestone, in the same way as sprint work, unless its proposal says otherwise.

Payment

Payments go through Stripe: Checkout for fixed-price offers, Invoicing for quoted work and Billing for retainers. We never see or store your card details.

Offer	Upfront	Balance
Audit	100% at booking	None
Production-readiness sprint	50% at booking	50% on delivery of PRs, net 7
Retainers	Month 1 at signup	Monthly in advance, auto-charged
Modernisation / tech-debt projects	30% deposit	Milestone payments per proposal, net 14
Overage	None	Billed monthly in arrears

No work before the upfront payment. Work does not start until the upfront payment is received. Receiving it reserves your dates, and it is when we request the access the proposal needs. The moment work actually starts, which decides refunds, is defined under Refunds and cancellations.
How to pay. Audits and retainers can be paid by card or by a local method Stripe supports. Invoices above US$5,000 can be paid by bank transfer, through Stripe Invoicing or Wise, so that neither side loses a percentage to card fees.
Tax. Prices exclude GST / consumption tax where applicable. Where a tax applies to you, the invoice shows how it is handled.
Late payment. Work pauses after an invoice is 14 days overdue, and resumes when it is paid. We remind you before that happens.

Why: a principal-led practice cannot carry unpaid work for long, and pausing is gentler than ending the engagement.

Refunds and cancellations

When work starts. Refunds turn on when work starts, so it has one meaning throughout these terms:

For an audit, work starts when access is granted.
For a sprint or a quoted project, work starts on the start date in the proposal, or when access is granted if that is earlier.

“Access granted” means you have given us the access agreed in the proposal and we have confirmed in writing that we received it. We record the time of that confirmation.

Why: until we can see your code, nothing has been spent on your engagement but calendar time. Once access is granted, the time is committed. The written confirmation means neither of us has to guess when that moment was.

Audits. If you cancel before access is granted, the audit is refunded in full. Once work starts, the audit fee is non-refundable.

Sprints. The 50% deposit is refunded in full if you cancel before work starts, and is non-refundable once work starts.

Why: a two-week sprint reserves two weeks that cannot be filled at short notice. Once its start date arrives, those weeks are spent whether or not access has come through. This term protects us rather than you.

Retainers. Either of us can end a retainer with 30 days’ notice in writing. Hours are a monthly cap, not a balance: unused hours do not roll over to the next month.

Overage. Work beyond a plan’s monthly hours happens only with your prior approval. It is billed monthly in arrears at the plan’s effective hourly rate, which is the monthly fee divided by the plan’s hour cap.

Why: a retainer is a reserved share of Aaron’s month. Notice gives both sides time to plan, hours that rolled over without limit would turn a capped plan into an uncapped one, and prior approval means no bill ever surprises you.

Projects. The proposal for a quoted project sets its own cancellation terms. If it says nothing, the deposit is treated like a sprint deposit.

If we have to cancel. If we cancel an engagement, or Aaron cannot do the work for longer than a short delay, we tell you promptly. You then choose between a new date and a refund of what you paid for work not yet done.

Why: a principal-led service depends on one person, and that risk should sit with us, not you.

Audit credit

If you book a production-readiness sprint within 30 days of your audit readout, the audit fee you paid is credited against the sprint price.

Why: the audit is the scoping for the sprint, and you should not pay for that work twice.

No security guarantee

An audit is a professional review of your code, product and setup against the scope in the proposal. It is not a penetration test, a certification or a guarantee that your app is free of vulnerabilities. The same is true of the free check, sprints and retainers.

We report what we find and what it means for your business. Not finding a problem does not prove it is not there.

Why: no honest reviewer can promise that a problem does not exist, and a report that implied otherwise would give you false confidence.

Liability

Our total liability for any claim connected with an engagement is capped at the fees paid for the engagement that gave rise to the claim.

Neither of us is liable to the other for indirect or consequential loss, such as lost profits, lost revenue, lost data or harm to reputation.

Nothing in these terms limits liability that the law does not allow to be limited, such as for fraud, wilful misconduct or gross negligence. Nothing removes rights you have under consumer law that cannot be excluded, including the Australian Consumer Law where it applies.

Why: the cap keeps the price of the work proportionate to the risk of doing it. Without one, a fixed fee would have to price in every possible outcome for your business.

What we ask of you

Give the access, information and answers the work needs, when agreed. Delays on your side move the delivery dates.
Make sure you have the right to share the code, data and accounts you give us access to.
Decide what to merge and deploy. At arm’s length you merge every change, so you stay in control of production. Under delegated access, you decide the scope within which we merge and deploy for you, and what still needs your approval first.
Keep your own backups.

Why: we work inside your systems as a guest, and these are what make that workable.

Intellectual property

Deliverables become yours on full payment. When an engagement is paid in full, we assign to you the rights in the deliverables made for it: the code in its PRs, its reports, plans and documents. The assignment covers every right that exists in them, however they were produced, and includes the rights under Articles 27 and 28 of the Japanese Copyright Act. We will not assert moral rights against you or anyone you authorise. Until full payment, you may use the deliverables for the purposes of the engagement.
Our tools stay ours. Pre-existing tools, templates, checklists, scripts and know-how, meaning anything we had before the engagement or build for general use, remain with Anystack G.K. Where they form part of a deliverable, you get a perpetual, non-exclusive, royalty-free licence to use them with the deliverables.
Open source stays under its own licence. We tell you before adding any dependency whose licence would require you to publish your own code.

Why: you are paying to own the result. We need to keep using our own methods for the next client without carrying any of your work along with them.

Confidentiality

Confidentiality is mutual. Each of us keeps the other’s confidential information confidential and uses it only for the engagement. This lasts for 3 years after the engagement ends, and for trade secrets for as long as they remain secret.

It does not cover information that is public through no fault of the side that received it, that the receiving side already had, developed independently or received lawfully from someone else. If the law requires disclosure, the receiving side tells the other first, where it legally can.

We do not name you as a client, or show any of your work, without your written consent.

We may ask whether you would agree to an anonymised case study about your engagement. It is a separate, optional request: saying no changes nothing about the price or the work. If you agree, you see the final text before it is published, nothing is published until you sign it off, and identifying details, such as your name, your product’s name or your URL, need your separate written consent.

If you want a signed agreement before you share anything, for example before a discovery call, a mutual NDA is available. Ask at aaron@anyfront.co.

Why: you are showing us unfinished code and business plans. What happens to them should be as clear as what happens to your money.

Data handling and repository access

These rules keep the access we hold as small as the work needs, and keep it visible to you. Access is given in one of two modes. Arm’s length is the default. Delegated access applies only where your proposal says so, and only within the scope its access-mode schedule sets.

Arm’s length (the default)

A dedicated account. Access goes to a dedicated Anyfront account on your code host, or to a project invite on a build platform, never to a personal account, so you can see it and remove it at any time.
Least access. Audits get read access only. Write access is requested only for sprints, retainers and quoted projects.
PRs only. Every change is delivered as a PR. We never push directly to your default branch, and you merge.
No production secrets. We never ask for production secrets. Where the work needs credentials, they are staging or scoped credentials only, shared through your secret manager or a one-time share, never pasted into chat or email.

Delegated access (only where the proposal says so)

Within the agreed scope. Within the scope the proposal sets, we may merge, deploy, and change infrastructure and architecture without asking you to approve each change. Anything outside that scope, and anything the proposal lists as needing your approval first, stays at arm’s length.
You stay the owner. You remain the owner of every account and every repository. Our access is a role or an invitation on your own accounts that you can remove at any time. We never ask for, or accept, root or owner credentials or a shared login.
Version control and a change log. Every change, to code, configuration or infrastructure alike, goes through version control with its full history, and is recorded in the change log the proposal defines. You receive the final change log with the handover notes.
Secrets stay with you. Secrets stay in your secret manager or your platform’s settings, where the delegated role reaches them only as far as the scope needs. None is sent to us by email or chat.
Yours to end. You can end delegated access at any time, by removing the role or telling us in writing. The rest of the engagement then continues at arm’s length.

In both modes

Local copies. Any local copy of your code or data is kept on encrypted storage and deleted when the engagement ends.
Access ends with the work. At the end of an engagement we revoke our access to every repository and account it covered, and confirm it in writing, unless a retainer continues.
Critical exposures. If we find a critical exposure during the work, such as a leaked key or an open database, we report it to the owner immediately, not in the next report.
Personal data. If your systems hold personal data, we process it only to do the work and only as you instruct. Under delegated access, the role you grant may reach personal data held in your accounts, and we use it only as far as the agreed scope needs. If your law requires a written data processing agreement, tell us before access is granted. Our privacy policy covers the personal information we collect about you.

Why: every credential we hold is a risk to you. These rules keep that risk small, and under your control. Delegated access lets us do more for you, so its scope, the approvals it still needs and the record of every change are written down before it starts.

AI-assisted delivery

We use AI tools in delivery, under Aaron’s direction, and Aaron reviews everything before it reaches you. Your code and data are processed by AI tools only under business terms that exclude training on inputs, so nothing you share becomes training data.

You may opt out of AI-assisted processing of your code and data in the proposal. If you do, the proposal reflects any effect on timing.

Why: AI tools make the work faster, and you are entitled to know when they are used and to say no.

The free check

The free check is an automated scan of an app’s public surface, followed by a review by Aaron.

Who can request it. Only the owner of the app, or someone the owner has authorised. By requesting a check, you confirm that you are one of them.
What it looks at. The public surface only: what the app serves to any visitor, read with the same kind of requests a browser makes, at a gentle rate. It does not sign in, submit forms or change anything. Where it looks at a database named in the app’s public code, it records only table names and row counts, never the rows themselves.
No private code. The free check never reads or scans private code, and it needs no access to your repositories. Reviewing your code is a paid engagement, such as the audit.
When it runs. Scanning starts only after ownership of the app is verified: by your email domain, a DNS record, a meta tag or file, or a read-only repository invite, or, when you ask Aaron directly, by his record of that request. A repository invite is used only to verify ownership: nothing in the repository is read for the check. A check requested online at anyfront.co/check also waits until you have confirmed your email address.
What you get. Results are labelled “Automated results” until Aaron reviews them, and then “Reviewed by Aaron”. Until then they are automated, and can include false positives. Each version of an online report can also be downloaded as a PDF from its page. A check run by hand is reviewed before it reaches you, as a PDF by email.
No guarantee. The check covers a small part of what an audit does. A clean result does not mean the app has no problems.
Nothing is published. Your app, your results and your name are never published without your written consent.
No obligation. Requesting a check does not commit you to anything.

How long check data is kept is set out in the privacy policy.

Why: scanning an app without its owner’s permission is not something we do. So the check runs only for its owner, and only on what is already public.

Ending an engagement

Either of us can end an engagement in writing if the other seriously breaches these terms and does not put it right within 14 days of being told. Work done up to that point is paid for, subject to the refund rules above. When an engagement ends for any reason, our access is revoked and local copies are deleted.

Why: both sides need a way out of an engagement that has stopped working, and neither should lose what was fairly earned or shared along the way.

Changes to these terms

These terms are versioned and dated, and the version and effective date are shown with them. A new version applies to proposals accepted after its effective date. An engagement stays on the terms in force when its proposal was accepted, unless we both agree in writing to move it.

Why: the deal you accepted should never change underneath you.

Governing law

These terms are governed by the laws of Japan, where Anystack G.K. is registered. The Tokyo District Court has exclusive jurisdiction as the court of first instance. Before either of us goes to court, we try to settle a disagreement by talking it through.

These terms are published in English and in Japanese, at /ja/terms. A contract concluded in Japanese, such as a proposal accepted or a free check requested on the Japanese site, is governed by the Japanese version. Any other contract is governed by this English version.

Questions about any of this: aaron@anyfront.co. Aaron answers.