Everyone has their own version
Several people use the same tool, each on a copy that drifted a bit further. Nobody dares to merge, and results are getting hard to compare across the team.
Freelance research software engineer for labs & spinoffsStart focusing on your research
I'm Marine Guyot, a freelance research software engineer. I turn the code your lab shares, and the code you're about to publish, into something reproducible, reliable and yours to maintain.
Get a free first look at your code See what I've built
When labs call me
Three moments when research code stops being a side issue
Your code works well enough for one person, one experiment, one paper. Then something changes.
Your project changes scale
A new instrument, a new probe, more users, more data. The script that did the job needs to become a tool the whole group can rely on.
Your paper needs its code
More and more journals require the code behind your results. Nature journals ask for a Code availability section and can send your code to reviewers. Is yours ready to be read, run and cited?
Building a company out of your lab work? Before incorporation, I help founders do a bit more research on the points still open, or take an existing project to production.
"We'll just do it with AI"
Your AI, or mine?
Yes, you can. AI makes a great proof of concept. But when it's time to publish, you need something solid, something you can build on for years. I use AI too. The difference is what goes around it.
AI on its own
- A working script, fast
- Checked by running it and looking at the plot
- Duplicated code, abandoned attempts left in place
- Parameters that quietly changed along the way
In a 2026 study of 527 researchers who code with AI, only 3% mentioned automated tests and 2% a review by someone else: How Researchers Use and Verify AI Coding Assistants. On parameters changed without noticing: O'Brien, CHI 2025.
AI + an engineer who knows what to check
- One shared codebase instead of personal copies
- Tests on the results that matter for your paper
- Code that does what the methods section says
- Documentation your next PhD student can follow
A proof of concept is a start. What you publish has to hold.
Confidentiality comes first. I use Claude only when you agree to it and when it makes sense for what we're building. Otherwise, I work with local models, so your code and data never go to a third-party service.
What you get
What my clients keep after I leave
Reproducible
Same inputs, same results, on another machine, a year later, for a reviewer. Pinned environments, versioned releases, a clear link between the paper and the code.
Reliable
Tests where they count, bugs found before a reviewer finds them, and a code structure that holds when the instrument or the protocol changes.
Yours
Your team understands it, can extend it and doesn't depend on me. Documentation, handover, and a codebase built on patterns that last.
Selected work
Labs I've worked with
An embedded system for an evolving lab instrument
Legacy code rebuilt into a modular, containerized system: researchers deploy their own experiments on the device and trigger them from a web app.
Ten students, one visual stimulus software
Two long-diverged branches reconciled, a latency bug fixed, and every student's experiment protocol kept working.
A new probe in the standard ecosystem
Instead of a one-off data format, an Open Ephys plugin in C++ and a real-time visualization app for high channel counts.
What can machine learning add to your analysis?
Several machine-learning approaches on young children's eye-tracking data, designed and compared with the lab's own analysis.
What clients say
“The flexibility and responsiveness allowed us to move quickly on targeted milestones, while benefiting from high-level architectural thinking and strong ownership of deliverables without the overhead of a traditional hire.”
“I had the pleasure of working with Marine on a new cutting-edge neural implant I develop for neuroscience research. I needed a software solution to acquire data through a National Instruments setup and she suggested the perfect approach: leveraging the accessibility of the Open Ephys platform, she coded a plugin and GUI tailored to our specific needs. She showed excellent skills in balancing complex hardware constraints and great user experience. I highly recommend working with her!”
How it works
Small, scoped, and on your schedule
Engagements from a few days to a few weeks, sized to fit a lab's operating budget. Remote, across France, Belgium, Switzerland, the rest of Europe and the US.
Free first look
You show me the code and what hurts. I tell you honestly whether I can help.
Scoped proposal
What I'll deliver, in how many days, and what it won't cover.
Work in your repo
Regular check-ins with the people who use the code, not just the PI.
Handover
Documentation and a walkthrough, so your team owns the result.
Running a doctoral school or a training programme? I also give workshops on research code.
Free your mind from struggle
Tell me about your code and what's getting in the way of your research.
marine@codingresearcher.com
Useful to include
- Your lab and field
- Language(s): Python, C++, MATLAB…
- How many people use the code
- Any deadline: paper, instrument, funding
- A link to the repository, if you can share it