Frequently Asked Questions
Straight answers to the questions we hear most before a project starts. Still unsure about something? Ask us directly — we reply within two business days.
Working together
Engagement & pricing
What does a typical R consulting engagement look like?
Every engagement runs end-to-end: a scoping call to clarify the question, the data and the deliverable; a written fixed proposal; the analysis or build itself; and a handover where you receive the code, documentation and a walkthrough. You always talk directly to the person doing the work — we keep the team small on purpose.
How much does it cost?
Pricing depends on scope. Small, well-defined tasks (a single analysis, one figure set, a short report) are quoted as a fixed price; larger builds — Shiny applications, reporting pipelines, R packages — are scoped into milestones with a fixed price each. After the scoping call you receive a written proposal with the price, timeline and deliverables spelled out, so there are no surprises and no open-ended hourly meters.
How long will my project take?
A focused statistical analysis is usually days, not weeks. A production Shiny dashboard or a parameterised reporting pipeline typically runs two to six weeks depending on data readiness and the number of review rounds. The scoping proposal gives you a concrete timeline before any work begins.
Do I get the code, or just the results?
You get the code. Every deliverable is generated by scripts you receive and own outright — the analysis, the figures and the report all come from one reproducible pipeline. There are no black boxes and no vendor lock-in: your team can rerun, audit and extend everything after handover.
Data & tooling
Data, tools & confidentiality
Is my data kept confidential?
Yes. We treat all client data as confidential and are happy to sign an NDA or data-processing agreement before you share anything. Where the analysis allows, we can also work on a de-identified or synthetic extract so that raw identifiers never leave your systems.
Can you migrate our analysis from SPSS, Stata or Python to R?
Yes — this is common work. We reproduce your existing results in R first to confirm an exact match, then rebuild the workflow as a clean, documented and reproducible R pipeline. The result is easier to maintain, version-controlled and free of per-seat licence costs.
What R skills and packages do you specialise in?
Our core is statistics and biostatistics: hypothesis testing, regression and mixed-effects models (lme4), survival analysis (survival), and power analysis. On top of that we build with the tidyverse for data work, ggplot2 for publication-quality graphics, shiny for interactive apps, and quarto / R Markdown for reproducible reporting. We also develop internal R packages with tests and CI.
Do you build and deploy Shiny apps to our own infrastructure?
Yes. We deliver Shiny applications wherever you need them — your own server, Posit Connect or shinyapps.io — and can wire in authentication, scheduled data refreshes and logging. For lightweight, serverless demos we also ship Shinylive apps that run entirely in the browser (see our live demos).
Academia & getting started
Academic work & next steps
Do you support academic research, theses and dissertations?
Yes — clinical and health-sciences research is where our methodology was forged. We help with study design and sample-size planning, run the analysis, and produce APA-ready tables and figures with full assumption diagnostics. Our Clinical R toolkit shows the kind of analyses we run every day.
Can you help with journal submission or reviewer statistics?
Yes. We can prepare the statistical methods section, generate the exact tables and figures a journal expects, and respond to reviewers’ statistical comments — including additional sensitivity analyses or re-runs requested during revision.
Do you work remotely? Where are you based?
We work remotely with clients worldwide and communicate in English and Turkish. Scoping calls, interim check-ins and the final walkthrough all happen over video, and everything is delivered as code and documentation you can open anywhere.
How do we get started?
Send a short description of your data, your question and your timeline through the contact page. We reply within two business days, usually with a couple of clarifying questions and a suggested time for a short scoping call.
Clinical & regulatory
SAS to R, validation & regulatory work
Can you migrate our SAS programs to R?
Yes. We run SAS-to-R migrations as a five-phase programme: assessment (inventory, risk classification, macro reuse), conversion to R functions and packages, equivalence testing by dual programming with documented numerical tolerance rules, the validation and SOP documentation your quality system needs, and sponsor or regulator adoption support. We recommend starting with a fixed-scope Phase 1 assessment so the later phases are priced on evidence rather than assumptions. See the SAS to R migration page.
Is R accepted by regulators such as the FDA and EMA?
Yes. The FDA’s Statistical Software Clarifying Statement says no specific software is required, and the R Consortium’s R Submissions Working Group pilots have delivered fully R-based submission packages that the FDA received and reviewed. What regulators expect is a documented, validated process: pinned package versions, package risk assessment, qualified installations, independent QC and traceability. We set that up as part of a migration. Background: Is R accepted by the FDA?
How do you validate R for clinical use?
Validation is a property of the process, not the licence. Our R validation plan covers environment qualification (pinned R and package versions with renv, installation and operational checks), package risk assessment with riskmetric and documented acceptance criteria, independent dual programming of datasets and TLFs with numerical tolerance rules, a traceability matrix from specification to program to output, deviation management, and a validation summary report. Templates and the evidence trail are part of the deliverable. Details: How to write an R validation plan.
Why do SAS and R give slightly different numbers?
Most differences come from a handful of conventions, not from errors: SAS rounds half away from zero while R’s round() rounds half to even; SAS has special missing values and sorts missings first while R has a single NA that propagates; default variance and sums-of-squares types differ in ANOVA; tie handling differs in some nonparametric tests; and floating-point display differs. Each difference is triaged and documented during dual programming, and most are resolved by matching the convention explicitly in R. Read: Rounding differences between SAS and R.
Do you work with CDISC standards (SDTM, ADaM, define.xml)?
Yes. ADaM derivations are built with the pharmaverse admiral family, tables and listings with rtables, tern and gtsummary, and outputs are checked against the shells and the SAP. We follow CDISC implementation guides and CORE conformance rules and can produce the programmer and QC documentation that accompanies a submission.
Didn’t find your question? Get in touch — a real person will answer.