Skip to content

A service, and its conflict

Help fixing what the report found

A report tells you what a first real user, an app store reviewer or somebody poking at your API would find. Some of it is a five-minute change and some of it is a week. This is us doing the work with you, if you would rather not do it alone.

Read this part first

A company that rates applications and also sells repairs has a financial interest in finding faults. That is arithmetic, not an accusation, and it is true of us. You should be sceptical of this page, and we would rather say so than have you notice it yourself two paragraphs later.

What follows is not a promise to behave. The incentive exists whether or not anybody acts on it, so the answer is four separations that do not depend on us being good — each one a fact about how the code is built.

What stops it mattering

  1. 01

    The scoring code cannot see this service

    The module that computes a score may not import the module this service lives in, and may not declare it as a dependency. The build fails if either is ever added. Not “does not use it” — cannot.

  2. 02

    Whoever did the work cannot review the result

    Recorded in the database, and refused there. A reviewer named against an engagement is rejected however they reach the decision: the console, a script, or a path nobody has written yet.

  3. 03

    The price never depends on what was found

    Fixed fee or hourly, and nothing else exists. “Per finding resolved” is the obvious way to price this and the one that would pay us for every fault we report, so there is nowhere in the code to put it.

  4. 04

    You are told, wherever the score appears

    If we were paid to work on an application, its verification page says so — beside the score, not in a policy you would have to go looking for.

None of this makes the conflict disappear. It makes it visible and inert, which is the most any rater who also sells services can honestly claim. If that is not enough for you, decline — and nothing about your assessment, your badge or your place in the review queue changes.

What is included

  • A written plan: what to change, in what order, and why that order
  • The work itself, on a branch you review and merge — we never push to your main branch
  • A walkthrough of what changed, so the next one you can do yourself

And what is not

  • Any influence over your score. The people who do this work cannot review your assessment, and the scoring code cannot see that this engagement exists
  • A guarantee that your score will rise. What the next assessment finds is what it finds — anyone promising you a number is selling you one
  • A faster or softer review. The queue and the threshold are the same ones everybody else gets

How it is priced

  • A fixed fee

    Agreed before anything starts, from the plan. It does not move if the work turns out to be larger than we thought — that is our estimate to get right, not your risk to carry.

  • By the hour

    For work whose shape is not clear until it is opened. You set a ceiling and we stop at it rather than asking for more.

There is no third option, and there was never going to be. A price per finding resolved would pay us for every fault we report.

How to stop

Say so. An engagement is fixed-fee or hourly and stops when you stop it; nothing recurs, and declining it changes nothing about your assessment, your badge or your place in the queue.

What your verification page will say

VibefyCode was paid to help fix this application. That work had no part in this assessment: the score is produced by the published rubric from evidence, no one who worked on the application may review it, and there is no path by which any payment can change a finding or a score.

Word for word, beside your score, for as long as the badge is live. If that sentence would cost you more than the work is worth, do not buy the work — that is a reasonable conclusion and we would rather you reached it here.

The independence policyWhat an assessment does