Website audit
Something is wrong with the site you paid for. Pages are slow, something breaks every time you ship, small changes keep costing more than they should - and nobody can tell you why.
Finding out why is the work. I read the code, reproduce the bugs, measure what is slow and name the cause, then put a price on every fix so you can decide what to fund and in what order.
2000-2500 USD
- Every finding written as a problem, a business impact, and a fix.
- The urgent findings separated from work that can safely wait.
- Hours priced per finding, collected in one table with a total.
Experience
I run audits like this as part of my daily work as a senior frontend engineer at Bejamas, on production sites for client teams.
What I find
The things nobody has been able to name for you
Bugs your users hit and you don't
Forms that fail silently, layouts that break on a real phone, features that work on the developer's machine and nowhere else. I reproduce each one and point at the line that causes it.
Why the site is slow, not that it is slow
PageSpeed Insights tells you to defer offscreen images. It does not tell you your hero sits at zero opacity until a reveal script fires, or which marketing tag is holding the main thread. Finding that takes years of doing it, and the report names the line.
Why your next change costs so much
Hardcoded sections instead of components, no design tokens, no types. This is why a one-line copy change gets quoted at three days, and I can show you the count.
What breaks quietly after launch
Dead links, redirects that land on 404s, pages that render empty when a third party is down, error states nobody wrote. None of it shows up until customers find it.
Failures nobody is watching for
No error monitoring, no alerting, nothing measuring the funnel. A checkout that broke on Friday gets found when someone notices the numbers on Monday, if they notice at all.
Security an automated scan will not catch
A scanner checks patterns. I check whether the role check also verifies this user owns this record, whether secrets sit in git history, whether your forms can be used as a spam relay.
In practice
How the audit runs
You send the site and the code
A live URL and read access to the repository. If you have a staging deployment I can hit, the measurements get sharper.
You get a fixed fee and a fixed date
Both set before I start, once I have seen the size of what I am reading. No scope drifting past what was quoted.
You get the report, and a call to walk it
Then you decide what to fund. Hire me for the fixes, hand the list to your current team, or take it into a renegotiation - the report reads the same either way.
Client feedback
What clients say about the work
Augustyn is an incredible contributor and knowledgeable technical resource, and I was impressed by his thoughtful solutions as well as excellent communication skills. [...] I would not hesitate to collaborate with him again on any future projects.
Eric Letsche · Head of Product
I'm extremely pleased with Augustyn. He's an incredibly hard worker, has a great eye for detail, and has helped me get my project over the finish line. He's very responsive on slack and courteous on calls. Couldn't be more happy he's on my team.
John Robert Reed · Head of Marketing
Augustyn has been exceptional across both projects, delivering high-quality work throughout and making a real positive impact. The team has greatly appreciated his support, expertise, and collaborative approach, and he has quickly become a valued and trusted member of the wider team.
Cathy Stroud · Senior Agile Delivery Manager
He also impressed me with his very courteous manner and consistently transparent and precise communication. His response times were always fast. Working with him was extremely pleasant and productive. I highly recommend Augustyn to any team that values reliable and technically skilled developers.
Yves Ernst · Project Manager
Augustyn is a joy to work with! It is clear that he cares about more than just web development - he cares about the users. He works quickly without ever compromising on quality, making him a fantastic collaborator.
Ali McDerment · Project Manager
01 / 05
The report
Every finding is written the same five ways
No score, no dashboard, no ninety-page appendix nobody opens. Read one finding and you know what it is, what it costs you, and what to do about it.
Problem
What is wrong, in plain language, with the file, the URL or the measurement that proves it. Never an opinion on its own.
Why it matters
The consequence of leaving it. Written for the person approving the budget, not for the developer who will fix it.
Key issues
The specifics as short bullets: which pages, how many, which rule, which dependency. Nothing important buried mid-paragraph.
Business impact
What it actually costs you - lost traffic, abandoned forms, slower releases, a launch that has to be pulled.
Recommendations
What to do, in order, each item small enough to hand a developer as a ticket.
How it is organised
A document built to be acted on
The urgent list first
Whatever is actively costing you - or blocking a launch, if you have one coming - sits at the top, in the order I would fix it. Everything that can wait is marked as such.
One table with the total
Every finding's hours in a single table, each row keyed to its finding number. You can see the budget before you read a word of detail.
Every claim referenced
A file, a URL or a measured number behind each finding. Nothing rests on me saying so, and your developers can check my work.
Executive summary at the end
One page you can forward as it is. Whoever only wants the conclusion can start there and stop there.
Questions, answered
Scope and timing
What does the audit cover?
Bugs, performance, architecture and code quality, your content model and how your editors work, and security. Every finding names a file, a URL or a measurement - if I cannot point at it, it does not go in the report.
How long does it take?
Three to five business days, depending on the size of the site and the codebase. I quote a fixed date before starting, not a range that moves once I am inside the repository.
Do you need access to the code?
Yes, read access. Most of what matters is invisible from the outside - I can measure a slow page from the browser, but I cannot tell you which line causes it, or what your next change will cost, without reading the code.
After the audit
Can you fix what you find?
Yes, on a separate quote - or hand the list to the team that built it. The audit reads the same either way, which is exactly why it is priced as its own fixed fee rather than as the first half of a build.
What if the build turns out to be fine?
Then that is the report, and you have an independent second opinion to put in front of whoever asked the question. I do not pad a finding list to justify an invoice - the fee is fixed before I look, so there is nothing to gain by inflating it.
What if my team disagrees with a finding?
Good - that is why every claim carries a reference. Take it to your developers and check it. A finding that does not survive that check does not deserve your budget, and I would rather be corrected than have you fund the wrong work.
Get in touch