Fixes your team applies: why our first month runs on read access

The usual first step of a website engagement is a request for access: the admin login, the hosting panel, the database, sometimes all of them in one email. It saves the vendor time. It also means that from that day, changes happen on your site that nobody on your side has seen.

Our first month of fixes works the other way. We ask for read access. We work out each fix. Your team applies it.

What that protects

• Nothing we do can break your site. We can’t change it. Every change goes through your own people and your own process.
• You always know what changed. Each fix arrives as a change you can read, with its reason. There is no “the agency did something last week”.
• Your credentials stay with you. No admin passwords in someone else’s notes, and no customer records outside your systems.
• Your team learns the site. Applying a fix that comes with its explanation teaches more than finding it already done.

What “ready to apply” means

A fix is not a paragraph that says “improve your titles”. Each one comes with four things:

1. The change itself: the code, the setting or the exact text.
2. Where it goes: the file, the page or the screen.
3. How to check it worked, in a minute.
4. How to undo it, if you need to.

Then we go through it with whoever applies it. If something doesn’t fit how your site is built, we correct the fix, not your site.

We don’t need your database

A missing title, a slow page, a tracking tag that never fires, a redirect chain, a form that hides on a phone: none of these needs customer data to diagnose or to fix. Asking for the database “just in case” creates a risk with nothing to gain, so we don’t ask. The same goes for the audit that comes before.

What it costs, honestly

It asks something of you: someone on your side has to apply the fixes. If nobody can, tell us before we start, and we plan the list around who will do it. Many fixes are settings and content that need no developer, only exact steps.

When read access stops being enough

For a first month, it is enough. Later, if the work continues and you would rather we applied the changes ourselves, that is your decision: we agree exactly what we can touch, on your own accounts and your own repository. By then you have seen a month of our work, which is a better basis for trust than a proposal.

See how the site fixes work