I built greenhouse software for one customer (on purpose)

The contrarian premise

Greenhouse software exists. It's all multi-tenant. It's all designed for a hypothetical grower instead of a specific one. And almost none of it is actually used by the people walking the bays.

The records that run a commercial greenhouse — spray logs, scout reports, crop counts, REI postings, weekly schedules — mostly live on clipboards, whiteboards, and three-ring binders. Twenty-five years of crop history is wisdom a senior grower carries in their head, not something the operation can query.

I knew one grower with this exact problem. I decided to build something that fit them, instead of pitching them on something generic.

The constraint that shapes everything

One customer. Deep integration. That single rule kills most of the complexity that normally eats startup energy:

• ▸No signup, no billing, no tenants. The data model has a single Company row. Every cycle saved on infrastructure is a cycle spent on the actual job.
• ▸The bay grid IS their greenhouse. Phase 4 A–B is 32 bays in two columns of sixteen rows, because that's what the building actually looks like. Not an abstract “zone”.
• ▸The schedule editor mirrors their paper grid. Rows of workers, columns of weekdays, click-to-cycle through work areas. The PDF export matches the printed handout the LeadBee hangs in the break room.
• ▸Ball Seed week numbering, not ISO. The horticulture industry uses a Sunday-start calendar where Week 1 contains January 1. The schedule speaks the language they already speak.
• ▸Spanish-first for FieldBees. The crew working the bays are native Spanish speakers. The worker UI defaults to Spanish; the manager UI defaults to English. Same app, role-routed.

What shipped

Phone-first PWA at app.scionbee.com. Next.js 16, Prisma, SQLite. PIN login on a tablet kept in the office, drilled down to the bay on a phone in the field. Five phases shipped in May, all live for the pilot:

• ▸Bay map with six status states. Empty / Populated / Watered (< 4h) / Dry (no water for 72h) / Scout flagged / REI locked. Each bay paints its own color so a manager scanning the grid from across the room sees what needs attention.
• ▸Five-second logging. Spray, scout, water, place crops — each action is two or three taps from anywhere in the app, recorded in the bay where it happened by the person who saw it. No transcription. No “I'll write it up later.”
• ▸REI postings as a byproduct. Every spray emits a re-entry-interval window with a public bulletin post and a countdown to clearance. EPA WPS compliance emerges from the workflow instead of being a separate module.
• ▸Plants v1. FieldBees place crops into bays as shipments arrive. A CropVariety registry auto-grows on every new typed name — no preloaded master list to maintain. Per-variety tips (“12-week crop, avoid morning water”) appear on the bay page when crops of that variety are present.
• ▸Seasonal art per month. The LeadBee's habit was to hand-decorate the paper schedule with a seasonal image — tulips in April, pumpkins in October. The app hosts a real GIF per month; same image decorates the editor banner, the plant dashboard thumbnail, and the printed PDF.
• ▸PINs by area, not by person. Workers move between plants in a week. Lead PINs and worker PINs are shared codes per area, rotated when a grower leaves. No identity layer, no roster maintenance.

The compounding angle

The tablet is the surface. The dataset underneath is the asset.

One year of bay-level records — every spray, scout, count, loss, transplant, throwout, captured with location and time and crop and worker — produces a structured dataset that doesn't exist anywhere else in the industry. After a year, you can train pattern recognition on it: yield prediction by variety and season, loss anomaly detection (“Bay 14 is showing 2008 collapse patterns”), labor demand forecasting, order-slip risk scoring.

That's a different conversation than “sell software to growers.” The data the operation generates by running normally is the part that compounds.

Why one customer is more interesting than a thousand

A SaaS pitch is a thousand shallow integrations. Every customer sees a configurable shell. Every feature has to please the median of a survey. Every screen has a settings page because somebody asked.

Scionbee's settings page has one toggle: language. The schedule editor knows what a Ball Seed week is because there's exactly one customer and they use Ball Seed. The map is shaped like Plant 3 because Plant 3 is the only plant. The PDF margins match the LeadBee's printer because someone walked over and asked which printer.

That depth is the product. Trying to sell it to a hundred more growers would mean tearing out exactly the choices that make it good.

The stack

Source lives at github.com/AlexlaGuardia/scionbee. The roadmap calls it: “Internal tool for one grower. Not a SaaS.”

If you're a grower with a binder

I'm not selling Scionbee. But if you run a commercial greenhouse, your records are mostly on paper, and you'd like to compare notes with someone building this stuff — you know where to find me.