Corrections - My Virtual Girlfriend
The log
This is where every factual fix on My Virtual Girlfriend gets recorded: a price that was off, a free allowance that had gone stale, a policy that moved, a wrong statement name, or a sentence that claimed more than it should have. Each entry shows the date, the page, the old wording, the new wording and the source for the corrected fact.
| Date | Page | The error | What it says now |
|---|---|---|---|
| - | - | Nothing to correct yet | - |
You are looking at an empty log because My Virtual Girlfriend has only just launched. I am not claiming every page is flawless. Prices and policies around these apps move constantly, and some of what is written here will prove wrong or go stale. Each time that happens, the fix shows up right here, publicly and with a date.
A blank log on a site with years behind it would be suspicious; on a brand-new one it just means the clock is barely running.
Normal updates stay out of the log. If an app bumps its price and I update the record on a regular check, that is housekeeping, and the fresh date shown on that page is proof enough. A correction is a different thing: the site showed something that was already false when it went up, or kept showing something after it had stopped being true. Only those cases belong here.
A sample entry
Entries are brief and exact. Say a review gave one figure for an app's lowest plan, while the pricing screen showed another figure on publication day. The entry would give the fix date, the review's name, both figures and a link proving which one is right.
If that figure also sat on a list or in a comparison table, I would mention those pages as well, since those pages all update at once.
Entries never shelter behind vague lines like "updated for accuracy". Each one states the error plainly, so anyone who relied on the old figure can spot it. Where the error might have cost a reader money, say a price shown below the real one or an allowance shown above it, the entry says that too.
Why this log is public
Any site that reviews apps asks you to believe numbers that are hard to verify on your own. The fair way to earn that belief is to show you exactly what happens when one of those numbers turns out wrong. A silent fix saves the writer's face; a logged fix looks after the reader.
If you ever made a choice based on a wrong price, you have a right to know it was fixed, and on what day.
I have a second reason, too. Keeping the log public stops me from taking shortcuts. With each fix written down beside its source, you can tell straight away whether I was sloppy or the app just moved.
Over the months, the log reveals the kinds of errors this site tends to make, and it tells me which of my checks need tightening.
What counts as a correction
- A wrong fact. A price, allowance, plan name, content policy or statement name that already disagreed with its source on the day it went up.
- An outdated fact. Something correct at the check date that stayed up once the app had moved on, at a point where I should have spotted the change.
- An overreach. A sentence claiming more than the record backs up, like an opinion stated as fact, or another reviewer's finding worded as if it were my own.
- A mislabelled review. One marked as a paid-plan review when I only used the free plan, or the reverse.
- A link that misleads. Any button or link that promises one destination and delivers another.
Typos, layout tweaks and clarity edits are not logged, unless they changed what a sentence means. If I cannot decide, it gets logged; a log that runs a little long is far less harmful than a fix nobody can see.
- Apps tried
- 90hands-on, 34 with a paid subscription
- Total paid
- $1,349subscriptions on my personal card
- Apps on file
- 78each price has a check date
- Latest hands-on
- FunFun AI
Pulled from the review database at build time. Every page shows the same figures. How I check the apps
A correction in four steps
Each correction follows the same four steps, whether a reader spotted the problem or one of my regular checks did.
Step one: I confirm the corrected fact against a source. The best sources come from the app itself: its pricing page, help centre, terms, privacy policy or its listing in a store. A dated screenshot taken while signed in to the app's pricing screen counts too.
A forum thread or video can tip me off, but neither is enough to change a record by itself.
Step two: I fix the record, not the page. All pages on My Virtual Girlfriend are generated from a single record per app, which is where the correction goes, with a new date and a link to its source. The old value gets copied into the entry in this log, which keeps the history intact.
Step three: I rebuild the site. The review, any list, any comparison table and any deals page that carried the old fact all switch to the new one together. That is how a fix here avoids leaving one page correct and a different page still wrong.
Step four: I add the fix to this log. The entry names the error, the page's new wording and the source of the corrected fact. When a reader flagged it and wants credit, their first name goes into the entry; when they would rather stay anonymous, it does not.
Prices get extra care
Readers rely on prices more than on anything else, and prices are also what changes most. Every price here has a check date, and once thirty days pass without a new check, the build stops showing it. That will not catch something that changed yesterday, but it does guarantee an old figure disappears rather than hanging around for months.
A different price is not always an error. Apps may charge differently depending on country, device, account age or whether you pay inside an app store, meaning a reader can see a different figure at checkout for reasons invisible to me. In cases like that, the page may get a note explaining the difference rather than a new price, and the log stays unchanged. I still write back to whoever reported it and explain why.
Regular checks between reports
I catch most changes before any reader has to flag them. Because a price disappears after thirty days, each one needs checking again at least monthly to stay on the site. Those routine passes are where I find most changes in this space: a new plan, a tier with a new name, a free allowance that shrank.
If a routine pass reveals the site was already showing something false, that is a correction and it gets logged. If it reveals the app changed after my previous check, I just update the record and its date.
Labels and claims of first-hand use
My rule on first-hand claims is strict: no page may describe my own use, spending or testing unless the record holds a dated log to support it. Each review on the site rests on my own dated notes, and its label shows which plan they came from. 34 reviews are labelled "Hands-on test, paid plan", and 56 are labelled "Hands-on test, free tier".
Prices and policies are still taken from each app's own pages and terms, each with a check date, and anything other reviewers found is credited to them.
Should any page break that rule, say by describing a paid feature from the inside for an app I only used for free, that is a correction, and it goes into this log. The same applies if another site's finding ever gets written up as something I experienced myself. The build scans for sentences like these before any page is published, but scans miss things, so please tell me about anything that got through.
How to report an error
Found a mistake? Email [email protected] or head to the contact page. The reports I can act on fastest include:
- the page's web address,
- the exact sentence or figure that is off,
- what you are seeing instead, and on which screen or site,
- your country, when it concerns a price.
The quickest confirmation is an image of the app's price list or a link to one of its help articles. You will always hear from me, either that the page is fixed or why I left it as it is. Send it even if you are unsure; looking into something that proves harmless costs me a minute.
You do not need a special form or formal wording. A two-line email naming the page and the figure gets me going, and I will ask for anything more I need. If you caught the error while comparing apps, let me know which other pages you had open, since the same fact often shows up on several.
If the app itself is the issue
Some reports are not about this site but about an app falling short of its own promises: a free plan that ran dry faster than advertised, a cancel button hidden away, a charge that looked unexpected on a statement. Reports like these still help. They do not alter what an app officially publishes, but they can shape the warnings I give, and I may add a line noting that readers have run into the gap.
I cannot resolve your issue with the app; each review sets out what is known about refunds and cancelling for that app.
Opinions and corrections are different
Disagreeing with me does not always mean I made an error. My verdicts, meaning who an app is good for and who should look elsewhere, are opinions resting on the facts in each record. If a verdict feels too tough or too kind to you, that is a fair debate, and it might change the page, but it only enters the log if the verdict relied on a wrong fact.
When a verdict shifts because the facts behind it shifted, the fact is what gets fixed and logged, and the verdict just comes along.
When an app closes
Apps in this space shut down, merge or stop taking new sign-ups more often than people expect. When one does, I mark its record, its prices stop appearing and its review explains what happened and on what date. I count that as an update, not a correction, unless the site kept recommending the app after it closed. If it did, the entry says so, along with how long the page stayed wrong.
More reading
My editorial policy sets out the rules for records and labels. The affiliate disclosure explains how My Virtual Girlfriend makes money and what that money can and cannot influence. For who runs the site and what it covers, see the about page.
Why a one-woman site does all this
I could skip all of it and just patch pages quietly whenever something breaks. I do not, because this corner of the web has a trust problem. Plenty of review pages talk about weeks of testing nobody did, and prices get copied between sites long after the apps have moved on.
Anyone who got burned that way has good reason to be wary of the next site too. A new site has few things to offer that are as hard to fake as an open, dated log in plain words, because anyone can compare each entry with what the app itself publishes.
It also keeps me honest on days when honesty is inconvenient. Knowing that an error will end up here with a date beside it is a great reason to double-check a fact before publishing it.
My promise about this log
I will never tidy this log. Once an entry is posted, it is not deleted or toned down, however red-faced it makes me. If an entry is itself mistaken, a new entry fixes it, and both remain. A corrections log is only worth anything if it works this way.
And if you ever spot a fix that happened with no entry here, please report that as well; a missing entry is its own mistake, and it gets logged the same as the rest.