Overview
R is free, open source and extended by thousands of CRAN and Bioconductor packages, which is why it dominates in ecology, biostatistics, psychology methods and much of the social sciences. That breadth is also the challenge: there are several ways to fit a mixed model, three plotting systems and competing styles of data manipulation. Beginners often copy code from different tutorials that do not fit together.
We work in a consistent, modern style: a project folder with relative paths, tidyverse or data.table for wrangling depending on your data size, well-established modeling packages, and ggplot2 for figures. Every analysis is a script or Quarto document that starts from raw data, and package versions are recorded with renv so the project still runs when packages update.
You can ask us to write and explain the analysis, review your own scripts, or tutor you through writing them. Many clients start with a delivered analysis and then use it as a template for later chapters.
Who it’s for and the problems it solves
This is for you if you are…
- Doctoral researchers in ecology, psychology, public health and the social sciences whose lab or supervisor works in R
- Master's students moving from SPSS or Excel to R for a thesis
- Researchers who need mixed models, generalized additive models, Bayesian models or other methods best supported in R
- Authors asked by a journal to share code and data alongside a manuscript
Common problems we help with
- Code from different tutorials does not work together, or breaks after a package update
- Errors such as 'object not found', 'could not find function' or 'contrasts can be applied only to factors with 2 or more levels'
- lme4 reports 'boundary (singular) fit' or convergence warnings and you do not know whether to trust the model
- Categorical predictors are coded differently from what you intended, so coefficients are hard to interpret
- Figures need to meet journal specifications for size, resolution and fonts
- Your analysis runs on your laptop but not on your supervisor's
What’s included — and what isn’t
Included
- Project setup in RStudio or Positron with an .Rproj or folder-based project, relative paths via here(), and a README
- Import from CSV, Excel, SPSS, Stata or SAS files with readr, readxl and haven, keeping value labels where useful
- Data wrangling with dplyr and tidyr: filtering, joins, pivots, recoding factors with forcats, and date handling with lubridate
- Modeling: lm and glm, mixed models with lme4 or glmmTMB, generalized additive models with mgcv, survival models, and SEM with lavaan when in scope
- Model checking with performance and DHARMa, and post-hoc comparisons or marginal means with emmeans or marginaleffects
- Publication-quality figures with ggplot2 and tables with gt, flextable or modelsummary
- Quarto or R Markdown reports that combine code, output and narrative, rendered to Word, PDF or HTML
- renv lockfile and set.seed() calls so the environment and any random steps can be reproduced
- Commented scripts and an explanation session
Not included
- Choosing models to reach a desired p-value, or reporting only the best-looking of many specifications
- Writing the thesis or paper text you submit for assessment
- Developing a full R package or Shiny application beyond the analysis (available separately as a programming project)
- Guaranteeing that code will run unchanged on future R releases — we document versions so it can be restored
What you receive
- R project folder
- Scripts or Quarto files organized as data-raw, R, output and figures, with a README explaining the order to run them.
- renv lockfile
- An renv.lock file recording the R version and package versions, so renv::restore() rebuilds the same library.
- Rendered report
- A Quarto or R Markdown report in Word, PDF or HTML with the key tables, figures and short explanations.
- Figures and tables
- ggplot2 figures exported at the required size and resolution, and tables formatted for APA or your target journal.
- Code walkthrough
- A session explaining the code logic, model choices and how to read the output.
How it works
Scoping
You share research questions, data description and any existing code. We confirm which models fit the design and whether R is the right tool.
Project setup
We create the project structure, import the data and record the environment with renv.
Wrangling and checks
Data are cleaned and reshaped in code, with summaries and plots to confirm that nothing unexpected happened.
Modeling and diagnostics
We fit the agreed models, check assumptions and convergence, and discuss choices with you before finalizing.
Report and handover
You receive the project, a rendered report and a walkthrough, plus a round of follow-up questions.
Packages and methods we commonly use in R
- Data handling
- tidyverse (dplyr, tidyr, readr, forcats, stringr), data.table or arrow for large files, janitor for cleaning names, haven for labeled SPSS/Stata data.
- Regression and GLMs
- lm, glm with appropriate families and links, MASS::polr for ordinal outcomes, nnet::multinom, and sandwich for robust standard errors.
- Mixed and multilevel models
- lme4 and glmmTMB for random intercepts and slopes, with checks for singular fits and alternative optimizers when convergence fails.
- Flexible and Bayesian models
- mgcv for smooth terms, and brms or rstanarm when a Bayesian approach suits the question and your field accepts it.
- Inference after fitting
- emmeans and marginaleffects for contrasts, predictions and marginal effects that match your hypotheses.
- Reporting
- ggplot2 and patchwork for figures; modelsummary, gt or flextable for tables; Quarto for reproducible documents.
Code that reads like an analysis plan
Good R code tells a reader what was done in the order it was done. We use descriptive object names, keep one step per pipeline stage and add short comments explaining why, not only what. Numbered scripts (01_import.R, 02_clean.R, 03_models.R) or a single Quarto document make the order obvious.
We avoid setwd() and absolute file paths, which are the most common reason an R project fails on someone else's computer. Paths are built relative to the project root with the here package, and the first script creates any output folders it needs.
Interpreting model output in R
R's summary() output is compact but assumes you know the coding of your predictors. By default, factors use treatment contrasts, so each coefficient compares a level with the reference level, which may not be the comparison you care about. We set reference levels deliberately, use sum or custom contrasts when the design calls for it, and use emmeans or marginaleffects to report the estimates that answer your hypotheses directly.
For generalized linear models we translate coefficients from the link scale (log-odds, log counts) into odds ratios, rate ratios or predicted probabilities. For mixed models we explain the random-effect variances, why lme4 does not print p-values by default, and the options (for example Satterthwaite degrees of freedom via lmerTest, or likelihood-ratio tests) that fit your field's norms.
Warnings worth taking seriously
Not every R warning is a problem, but some change what you can conclude. We explain which ones matter for your model.
- 'boundary (singular) fit' — a random-effect variance is estimated at or near zero; the random structure may be too complex for the data
- 'glm.fit: fitted probabilities numerically 0 or 1 occurred' — possible complete separation in logistic regression
- 'NAs introduced by coercion' — text values such as 'n/a' or '5+' in a column converted to numbers
- Many-to-many relationship warning from a dplyr join — duplicate keys that will multiply rows
- Package masking messages, for example dplyr::select masked by MASS::select, that make code behave unexpectedly
R versions, RStudio, Positron and renv
R itself is released by the R Core Team, with a new minor version each spring; R 4.6.0 appeared in April 2026. Most people use it through an IDE from Posit, the company formerly called RStudio. RStudio remains supported, while Positron is Posit's newer IDE that treats R and Python equally. Either works for our deliverables; we match your setup.
Because CRAN packages change, we snapshot your project library with renv. The renv.lock file records the R and package versions used, and renv::restore() reinstalls them on another machine. We also call set.seed() before any bootstrap, simulation or cross-validation so random results can be reproduced exactly. For a deeper audit of an existing project, see our code review and reproducibility service.
What the work can look like
Illustrative example — fictional data
Sample note: diagnosing a singular mixed-model fit
A doctoral researcher modeled reaction times from 42 participants across 120 trials with random slopes for condition by participant and by item. The numbers are invented to illustrate our notes.
What the warning meant
The model returned 'boundary (singular) fit'. VarCorr() showed the by-item random slope variance estimated at 0.00 and a correlation of −1.00 with the intercept, so the data could not support that term.
What we did
Following a documented simplification sequence, we removed the correlation term, then the by-item slope. The reduced model converged normally, and a likelihood-ratio test showed no meaningful loss of fit (χ²(2) = 1.84, p = .40).
How it is reported
The condition effect was 38 ms, 95% CI [21, 55], from the reduced model. The script keeps both models and the comparison so the decision is transparent in the supplementary code.
Illustrative example with invented data. Real notes depend on your design, data and field conventions for model simplification.
What you’ll need to provide
- Data files and a codebook or data dictionary
- Research questions, hypotheses and any preregistration or analysis plan
- Existing scripts and the full text of any error messages
- Your R version (from R.version.string) and any packages your lab standardizes on
- Target output format and journal or department requirements
You don’t need everything ready to ask for a quote — tell us what you have and we’ll say what’s missing.
What affects price and turnaround
Price depends on
- Number of research questions and models
- Complexity of models, for example mixed, Bayesian or generalized additive models
- State and size of the data, including the number of files to join
- Whether you need a full Quarto report or scripts and tables only
- Delivered analysis, code review or tutoring format
Turnaround depends on
- Completeness of data and documentation at the start
- Model run times, especially for Bayesian or large mixed models
- How quickly you can confirm modeling decisions
Every project is quoted individually. How we price our work.
Questions people ask before starting
Do you use tidyverse or base R?
Mostly tidyverse for clarity, with base R or data.table where they are simpler or faster. If your lab has a house style, we follow it.
Can you translate my SPSS or Stata analysis into R?
Yes. We reproduce the existing results first to confirm the translation is exact, then document any differences in defaults, such as how contrasts or standard errors are computed.
Do I need RStudio, or can I use Positron or VS Code?
Any of them works. Our scripts and Quarto files run in RStudio, Positron, VS Code or the plain R console. We only need to know which you use so instructions match your screen.
My code worked last year and now fails. Can you help?
Yes. This is usually a package update that changed a function's behavior. We identify the change, then either update the code or restore the older versions with renv and document why.
Will you write my results section?
No. We provide the analysis, tables, figures and an explanation of the results. You write the section; we can check your draft for accurate statistical reporting.