Skip to main content
TL
Illustration of the agronomic trials platform

Agronomic trials platform

Taking agronomic trials out of paper notebooks and Excel, through to the dashboard.

Role

Full-stack developer

Period

Client

Agri-food group

Technical stack
  • React
  • TypeScript
  • NestJS
  • MongoDB
  • Azure AD
  • Docker
  • Jest
trials per year
350
layout generation
< 1 s
valid generated layouts
100 %
01

The context

  • Technicians record their readings by hand in the plots, then re-key them into Excel at the end of the season.
  • Result analysis lives in Excel charts, redone from one season to the next.
  • The target users range from technicians to farmers, working in the field as much as at a desk, which calls for a tool usable on a tablet as soon as a network is available.
02

My mission

  • Building most of the backend, in NestJS and MongoDB.
  • Initial trial layout generation algorithm, under distribution constraints.
  • React frontend, from roughly 15% of the scope at release to a third today.
  • Taking over the enhancements after the first release: estimation, specification clarification and client exchanges.
  • Technical documentation deliverable expected by the client: API routes and screenshots locating each call in the interface.
  • Incremental reduction of technical debt on the modules being touched.
03

Timeline

  1. 2026
    • Gradually handing the application over to a colleague, while remaining the reference on technical, process and domain matters.
  2. 2023
    • Developing new features, and acting as the client's technical contact on estimation and specification clarification.
  3. 2022
    • First release, and move to a permanent contract after demonstrating technical autonomy on the core of the product.
  4. 2021
    • Joining as a work-study student and building the trial layout generation algorithm.
04

Decisions and trade-offs

  1. 01

    Generating trial layouts from a fixed starting point rather than at random

    Problem

    Generation fills a matrix of plots under distribution constraints. The first version starts from a random column, to vary the layouts.

    Solution

    A benchmark reveals that a random start drops below 50% valid layouts on the small, most common sizes. A fixed starting point makes generation reliable on the trial sizes and types in use.

    Why this choice

    On those sizes, getting a valid layout comes before its variety. The cost is less diversity in the layouts.

  2. 02

    Aligning the existing code in small passes rather than one rewrite

    Problem

    The core module stays in technical layers, untested, while the team adopts a Clean Architecture-inspired split elsewhere.

    Solution

    On each pass, one sub-module is restructured toward that split and covered by tests, as a matter of continuous improvement.

    Why this choice

    Rewriting a block takes a long stretch of time and leaves changes uncovered. Short passes give complete examples to the colleague who took over the application. The cost is that the two styles coexist without converging.

05

What this project gave me

  • Building skills autonomously under demanding code review, on a first work-study project.
  • Validating a design assumption with a benchmark, the measurement having revealed that a random start dropped the rate of valid layouts below 50% on small matrices.
  • Taking on estimation, specification clarification and client exchanges on the enhancements after the first release.
  • Shifting to the backend after a few weeks, to unblock velocity where review round-trips were slowing it on the frontend.
06

In hindsight

  • Spend more time on planning and overall quality before shipping. The habit of rushing to production left debt and multiplied round-trips on small bugs, in the application or in the React Query data flow.
  • Invest earlier in operations research for layout generation. The later version, in constraint programming, shows the gain a stronger algorithmic base would have brought from the start.
See other projects