An apiary management app, described in your own words

Why the notebook eventually gives out

A paper hive record is perfectly good for five colonies. It starts costing you the moment you want answers that cut across it: which colonies have not been inspected in six weeks, which ones swarmed two years running, how many kilos a given site produced, which honey batch came from which supers.

Those questions do not call for more notes — they call for the notes to be linked to each other. That is exactly what a database does and a notebook never will: an inspection belongs to a colony, a colony sits at a site, a harvest produces a batch.

What you describe, and what the engine makes of it

You write your need in plain language — "I keep bees, about a hundred hives across four sites, I record inspections, harvests and swarming". The engine derives a business schema from it: the entities, their fields, what links to what.

Before a single line of code is written, that plan is shown to you and you edit it: rename an entity, add a field, drop a section, fix the values of a status list. This is the point where the application becomes yours rather than a rough reading of your sentence.

Colonies and inspections

Each colony carries its own identity — number, queen, year, site, health status — and every inspection attaches to it. A colony's record therefore shows its inspection history, instead of a stray row in a spreadsheet.

Lists filter and sort: by site, by status, by date of last inspection. A deletion erases nothing permanently — it goes to a trash view the record can be restored from, which matters on the day you remove the wrong hive a little too quickly.

• One record per colony, with its inspection history
• Dated inspections: brood, stores, treatments, observations
• Filtering and sorting by site, status or date
• Trash and restore for deleted records

Harvests, batches and sites

A harvest attaches to the colonies that produced it, and the honey batch that comes out of it keeps that link. Traceability is not a separate module: it follows from the structure, because records are related from the schema onwards.

Sites are described like any other entity. If you mention their coordinates in your description, the plan can carry a map view; otherwise sites stay a list, which is enough for most apiaries.

• Harvests linked to the colonies involved
• Honey batches: flow, weight, packaging
• Sites and migratory moves
• JSON and CSV export of every dataset, whenever you decide

What the application is not

It is an internal management tool, not regulatory software. It does not keep your livestock register in the administrative sense, files nothing with any official service, issues no tax-compliant invoice and does not replace the official health monitoring of your colonies.

What it does do, it does with code that belongs to you: a standard Next.js and Prisma project, exportable as a ZIP or pushed to your own GitHub repository. Whatever is missing can therefore be added by a developer, without asking a vendor for permission.