Build or buy is the wrong question
Your team can probably build it. The better question is which part only your operation can build, and which part you would rather not maintain forever.
Every so often, partway through a conversation about operations software, someone across the table says some version of: “Honestly, we could build this ourselves.”
They are usually right. Most growing operations have someone who can build a solid internal tool, and many already have. So I don’t treat that sentence as an objection. I treat it as the start of the real conversation, because “can we build it” is almost never the question that decides how things go.
You already built one
Before anyone writes a line of code, most operations already run a home-grown labor system. It is a workbook.
Somewhere there is a file that holds the season: hours by work type, crews by week, the standards someone worked out over years, the numbers the owner looks at on Monday. Someone built it with real care, and it encodes a lot of hard-won knowledge about how this particular operation works.
That workbook is software, whether or not anyone called it that. Building it was a build decision, even though nobody made it on purpose. So the question is not whether your operation builds. It already does. The question is what you want your people to own for the next ten years.
Two layers, and only one of them is yours
Any operations system splits, roughly, into two layers.
The layer every operation needs. Who can see what and who can change what. History that stays put when someone edits a dropdown. Screens that work on a phone at the far end of the property. Records that sync when the signal comes back. A connection to the ERP that survives the next ERP upgrade. Backups. An audit trail. Something that keeps running when the person who set it up is on vacation.
That layer looks about the same at every operation. It is real work, it never finishes, and no customer ever chose a nursery because its permission model was well built.
The layer only you have. Your work types and how you define them. Your standards and what counts as a good day. The way crews actually move through your blocks. The report your owner reads first thing Monday and the three questions it has to answer. This is where your team’s knowledge lives, and nobody can sell it to you.
Where both choices go wrong
When an operation builds everything, the risk is not that the team can’t do it. The risk is where the hours go. The first layer is endless. Every phone update, every new hire who needs access, every change on the ERP side lands on the same few people, and the time left for the second layer, the part that is actually yours, keeps shrinking.
When an operation buys, it usually goes wrong the other way. A closed product flattens the second layer into the vendor’s idea of how a nursery works. Your data sits behind someone else’s export button. The people who knew the operation best end up filing tickets instead of making changes. If you have been through that, the bad taste is earned. I would not argue anyone out of it.
The third option: build on it
There is a middle path, and it is the one I would pick in your seat: buy the common layer, insist that it is open, and point your team at the layer only you have.
“Open” has to mean something specific, or it is just another adjective in a sales deck:
- Your data leaves whenever you want. A full export at any time, including on the way out, with no fee and no negotiation.
- Your team can read and write through an API. Not read-only. Not a partner program. Keys they can create themselves.
- It works with what you already run. Excel, Power BI, your ERP, and the assistant your office already pays for.
- The same rules apply to everyone. An integration or an assistant gets exactly the permissions of the person behind it, no more.
Get those four and the build-or-buy argument mostly goes away. Your team still builds. They just build the part that sets your operation apart.
When you should build all of it
Sometimes building the whole thing is the right call, and it is worth saying when.
- The software is how you compete. If the way you plan and run labor is your edge, own every line of it.
- You already run a software team. Not one talented person, but a team with a budget line, a roadmap, and on-call coverage that will still exist in five years.
- Nothing on the market fits, and you checked. If no product models how your operation works, build.
If those are true, build deliberately. Give it an owner, a budget line, and a roadmap, the same as any other piece of equipment that runs the business.
Where Canopy sits
I would be dodging if I didn’t say where we fit. Canopy is built to be that common layer for growing operations, open in the four ways above.
Here is what is real today: labor actuals recorded by work type against your own standards, crews modeled as capacity rather than rosters, and an API your team can create keys for and build on. Task planning and scheduling are in pilot. Connecting your own assistant, Microsoft Copilot included, is in early access. We hold no wage data and no individual worker records, by design.
We would rather your team build on us than around us.
This is the first post in a short series on building, buying, and building on. Next: the questions to ask any software vendor, including us. If your team has built something it is proud of, I would genuinely like to see it. Reply and tell me about it.
