Contribute  ·  Fork, edit, redeploy  ·  The next case

Build one for your farm Fork, edit the JSON, redeploy. That is the whole loop.

This site is a static folder of HTML, CSS, and one JavaScript file. No framework, no build step, no backend, no SaaS. The equipment list is a JSON file. The tool renders outputs from it in the browser. The whole site is yours the moment you copy the folder.


Three ways to run it locally

1. Open the file in a browser

Download the folder, double-click index.html. The site opens in your default browser. The case study works. The maintenance tool works. You are done.

2. Edit the equipment list and reload

Open case-maintenance.html in a text editor (Notepad, TextEdit, vim, whatever you have). Find the DEMO_JSON near the top of the <script> block. Replace the three machines with yours. Save. Reload. The outputs re-render with your data. The Download JSON button on the page lets you save your edited list as a separate file for safekeeping.

3. Host it on a USB stick in a farm shed

Copy the folder onto a USB stick. Plug it into any computer with a browser. Open index.html. The site works offline. The Google Fonts load will fail (and degrade gracefully to system fonts), but everything else is local. This is the right to repair move: the tool works when the wifi does not.


What the folder looks like

vibe-coding-agroecology/
├── index.html              ← the framing page
├── case-maintenance.html   ← the case study and the tool
├── process.html            ← how M3 and the owner built this
├── contribute.html         ← this page
├── style.css               ← one stylesheet, zine aesthetic
├── README.md               ← license, structure, contributing
└── equipment-list.json     ← the canonical equipment data (optional, or inline)

What to change first

If you are forking this for your own farm, the order of edits is roughly:

  1. Replace the three machines in the DEMO_JSON with yours. Edit the values, keep the structure.
  2. Adjust the service interval templates in the INTERVALS object if your machines need different schedules. The categories are tractor, utility, and excavator — add yours if you have a different machine type.
  3. Edit the parts templates in the PARTS object to match the actual fluids, filters, and consumables you use.
  4. Edit the masthead in index.html, case-maintenance.html, process.html, and contribute.html to your own farm name, location, and edition number.
  5. Replace the styling in style.css if you want. The variables at the top (--color-terracotta, --color-ochre, etc.) are the only things you need to change for a different palette.

You do not need to understand the JavaScript to use the tool. The JSON structure is documented in the file itself. Start with the demo and modify.


What's next

Cases that could be built with M3 next, using the same structure (zine aesthetic, plain HTML, file-based, no SaaS):

The framing is the same for all of them: concept → structured intake → executable artifact, with the agroecological and right to repair vocabulary intact in the output.


Tell us what you built

The honest feedback path is the GitHub Issues page for this project. Open an issue titled with your farm name and the tool you built. Include: your equipment list (or whatever data structure you used), what you changed from the demo, and what the tool enabled for you that the off-the-shelf ag software did not.

There is no analytics on this site, no newsletter signup, no SaaS feedback form. Sovereignty by design means the feedback loop is on the farmer's terms, not the platform's.