Where R help makes the biggest difference
Most people who ask for help with R are not stuck on statistics. They are stuck on the layer between the idea and the output: getting a messy spreadsheet into shape, persuading a function to accept the data, or working out why a model returned something odd. That is where we spend most of our time.
- Importing and wrangling with readr, readxl and haven (for .sav and .dta files), then reshaping and recoding with dplyr and tidyr.
- Modelling with lm and glm, mixed-effects models in lme4 or glmmTMB, survival analysis, ordinal regression, and structural equation models in lavaan.
- Post-hoc work and reporting with emmeans, broom and gtsummary, so estimates move cleanly into tables.
- Visualisation in ggplot2, from a simple boxplot to a faceted interaction plot that a journal will accept.
If you are still deciding which model fits your question, our statistics help covers test selection before any code is written.
Errors we untangle every week
R's messages are precise but rarely friendly. A few come up again and again, and the cause is usually one of a small number of things.
| What R says | Usual cause |
|---|---|
object 'x' not found | A typo in a variable name, or a line further up that never ran |
could not find function | The package is installed but not loaded with library() |
non-numeric argument to binary operator | A column imported as text because of a stray symbol or comma decimal |
boundary (singular) fit | A random-effects structure too complex for the data in a mixed model |
unused argument | Two packages exporting a function with the same name, such as select() in dplyr and MASS |
We fix the immediate problem, then show you how to recognise it so the same message does not cost you another evening.
How we work on your R project
Everything is built inside an RStudio project with a clear folder structure: raw data that is never overwritten, a script for cleaning, a script or document for analysis, and an output folder. Scripts are commented in plain language, and we record package versions so a reviewer can reproduce your numbers a year from now.
You choose the pace. Some clients want a finished script with notes to study; others prefer screen-sharing sessions where they type and we guide. Either way, nothing is a black box. If you later need to switch to Stata or explain a model in your methods chapter, the logic is already written down.
What to send and how long it takes
A useful first message includes your data file (or a sample with identifiers removed), your research questions or hypotheses, any code you have so far, and the error or output that worries you. Tell us your deadline and whether you need a reproducible document or just working code.
Debugging a single script is often done within a day or two. A full thesis analysis with cleaning, several models and figures usually takes one to two weeks, depending on data quality. Send the details through our quote form and you will hear back within a few hours with a plan and a price.
Why we teach the code rather than just hand it over
If your name is on the analysis, you will be asked about it, perhaps in a viva, perhaps by a reviewer who wants a robustness check. Code you cannot read is a liability at that moment. That is why every script comes with explanations, and why we are happy to walk through it line by line.
For thesis work, you remain the analyst and author, and you should follow your university's rules on assistance. For taught courses where the code itself is assessed, we work as tutors on your own attempts. Our academic integrity approach sets out exactly where those lines sit. To see the kind of reasoning we bring to a model, our regression analysis guide is a good starting point.
What you get
- A commented R script or Quarto/R Markdown file that runs top to bottom without manual steps
- Cleaned data with a short log of every recoding, exclusion and derived variable
- Publication-ready ggplot2 figures and APA-style tables
- A plain-English walkthrough of the output, including what each coefficient or estimate means
- A recorded or live session to go through the code together, on request
- A package list or renv lockfile so the results can be reproduced later
What we don't do
- Graded programming assignments completed for submission; for coursework we tutor you through the concepts and review the code you write
- Building R Shiny apps or production software for commercial use, which sits outside academic support
- Choosing results to fit a hypothesis; we report what the data show, with any limitations stated openly
How it works
Describe your project
Level, deadline and what you need help with.
Agree a written scope
What's included, the price and the timeline.
Work in stages
Check-ins so you can steer the work.
Review and ask
Explanations and follow-up questions included.