Most agriculture companies that ask about a custom ERP should not build one. Most of the ones that should build find out late, after a few years of spreadsheets filling the gaps around a platform that almost fits. This is how to tell which one you are, written by a development company that builds agriculture software and would rather you bought the right thing than built the wrong one.
Build or buy: the short answer
Buy when your operation looks like the operation the platform was designed for: common crops, standard workflows, and data that already lives in your machinery. Build when the software is part of what you sell, when your rules do not exist in any catalog, or when the real job is connecting systems that were never meant to talk to each other.
Most mature agriculture businesses end up doing both. They buy a platform for the common work and build the layer that makes them different.
Five agriculture platforms you can buy today
Before commissioning anything, look at what already exists. These five cover most of what an agriculture business asks for, and each one is a serious product.
- John Deere Operations Center brings field, machine and operator data into one place, and connects to third-party software through Deere's connected partner program. It is the data layer of the machinery.
- Climate FieldView, from Bayer, collects and connects crop data, supports remote scouting, builds prescriptions and analyzes yield. It works with most equipment brands and connects with more than 60 partners.
- Traction Ag is farm accounting built for row crop operations: income, expenses, payroll, inventory and profitability by acre, field or bushel. Its enterprise line adds grain contracts, crop planning and work orders, and it integrates with both of the above.
- Agworld, part of Semios Group, handles crop planning, compliance records, budgeting and agronomic and financial analysis by crop and field, shared between growers, agronomists, retailers and contractors.
- FarmERP, from Shivrai Technologies, is a cloud agriculture ERP sold in suites, from farm and plantation management to contract farming, post-harvest, exports, IoT and satellite imagery.
Product descriptions reflect each vendor's own website as of September 2026.
When buying is enough
Buying is the right answer more often than development companies like to admit. It is enough when these four things are true:
- You run a farm, not a platform. You grow and you sell, and the software's job is to keep the books, plan the season and store the records.
- Your crops and workflows are common. Row crops, standard rotations, standard inputs: this is exactly the operation the catalog platforms were designed around, and years of other farms' edge cases are already built in.
- Your data already lives in the machine. If your equipment writes to Operations Center or FieldView, much of the integration work is done for you.
- You have no engineering team and do not want one. A platform comes with support, updates and a roadmap somebody else pays for.
In that situation a custom ERP is a way of spending more to get less. Buy, configure it well, and put the engineering budget somewhere it makes a difference.
Four signs an off-the-shelf farm ERP will not fit
The catalog stops where your business starts being different. These are the four places it happens, in the order we usually see them.
1. Your machinery and sensors do not speak the platform's language
Mixed fleets, older equipment, drones, weigh scales, milk meters, irrigation controllers, custom sensors. A platform integrates what its partners integrated. Everything else lands in a spreadsheet, and somebody retypes it every week.
2. Your crop rules are your advantage
If your agronomy is a protocol of your own (when to spray, how to grade, which lot goes where), a platform will store the result but it cannot run the logic. Putting those rules into software is what makes your whole team apply them the same way, every time, in every field.
3. Traceability has to cross companies, not just fields
Buying from hundreds of producers, lab-testing lots, blending, storing and exporting: following a lot from a farm to a container is a supply chain problem, and most farm software ends at the farm gate.
4. You already have systems that have to keep working
An accounting package, a grading lab, a customer portal, a buyer's platform. When the job is making five systems agree, the missing piece is not a sixth platform. It is an integration layer and a set of APIs.
One of these signs is a reason to look harder at configuration. Two or more usually mean you are shopping for a product that does not exist yet.
What a custom agriculture ERP actually includes
A custom agriculture ERP is rarely a rewrite of accounting. Nobody should build a general ledger in 2026. What gets built is the part of the business that no catalog models:
- Procurement from producers, with contracts, quality and pricing rules specific to the crop.
- Lot tracking and lab results that follow the product through storage, processing and blending.
- Export and import workflows, with their documents and logistics.
- Operational dashboards that read from the platforms you already use.
- Integration with the accounting system you are keeping.
Caravela Coffee is the clearest example in our own work. CodigoDelSur built Atlas, Caravela's internal ERP for coffee buying, export, import and lab testing, on Ruby on Rails and React. No off-the-shelf product combines buying green coffee from producers, testing it in a lab and exporting it in one system, because very few companies run that exact chain. Caravela does, so the software had to be built.
The same shape applies to grain. A wheat or row crop operation that also buys, stores, grades and markets grain from other growers has the Caravela problem with a different crop: a supply chain wrapped around a farm. The farm part can be bought. The chain usually cannot.
Field apps and digital scouting: the most common custom build
The agriculture software that gets built most often is not an ERP at all. It is a field app: the thing an agronomist, a scout or a sales rep opens while standing in a field.
- Skippy Scout is a drone-enabled crop scouting app that automates flights to capture images at scouting points across farms and fields, built on the DJI SDK for iOS.
- AgroScout: CodigoDelSur built the mobile applications for iOS and Android, including drone flight routes and maps. The crop detection models are AgroScout's own.
- Bluefin is an integrated pest management app that connects the work of scouts, agronomists and producers, in a relationship of more than twelve years that is still running.
- DroneDeploy: a flight and image capture app built on the DJI SDK, for a platform used across agriculture, construction and inspection.
Why these get built rather than bought: a scouting app is where your method meets the field. Which points to sample, what to photograph, what counts as a threshold, what the grower sees afterwards. General scouting features exist inside FieldView and Agworld, and for many operations they are enough. Companies build their own when scouting is the product they sell, or when what the scout captures has to feed a recommendation, a prescription or a conversation with the grower.
That last case is more common than it sounds. Input companies and agtech startups use scouting apps as sales tools: the rep walks the field with the grower, captures the problem on the spot, and shows the recommendation before leaving the farm. That is a product decision, not a platform feature, and it is usually built.
The middle path: build on top of the platform you already bought
Build versus buy is often a false choice. Operations Center connects to outside software through Deere's connected partner program, and FieldView connects with more than 60 partners. Both are designed to be built on.
That changes the question. Instead of replacing the platform, you keep it for what it does well, machine data, field records and agronomy, and build only the layer that is yours: a dashboard that joins machine data with your own sales and inventory, a customer portal fed by field records, an app that pushes your recommendations into the tools your growers already use.
Milc is an example of this kind of work at scale. CodigoDelSur was the software partner for the Milc dairy platform for nine years, building its backend, web applications, native iOS and Android apps and the platform's AI assistant, including integrations with external dairy systems, while Milc handled its own hardware and firmware. In a separate project, CodigoDelSur also built a computer vision system that recognizes cows from camera images, a capability designed around one operation's own barns and herds. The engagement closed with a full handover to Milc's in-house team.
API development in agriculture usually means one of three jobs: pulling data from equipment and farm platforms into your own system, exposing your data to growers' and partners' tools, or connecting a new product to the accounting and ERP systems a customer already runs. All three are ordinary engineering. The domain knowledge is knowing which data can be trusted, which data arrives late, and which data no farmer will ever enter by hand.
How to decide: five questions before you sign either contract
- Is the software part of what you sell? If yes, build. A product you sell to growers cannot be somebody else's platform.
- Could you write down rules that no vendor has? If yes, those rules are what you build. Everything around them you can buy.
- How many systems have to agree? One or two: buy and configure. Four or more: you need an integration layer, and that gets built.
- Who owns the roadmap? With a platform, the vendor decides what ships next. If the feature you need is not on their list, it may never arrive.
- What does it cost to be wrong for three years? Compare the subscription plus the manual work around the gaps against building and maintaining your own. Count the people retyping data: they are usually the largest cost nobody budgets for.
If you answered yes to the first question, or to two of the others, building is the better bet, and the sooner you start, the less you pay to migrate later. If you answered no to all five, buy one of the platforms above and do not let anyone talk you out of it, including us.
If you build, who builds it
CodigoDelSur is a software development company founded in 2007 in Uruguay, with around 140 people and more than 250 clients. Our agriculture work covers the whole range in this article: ERP for agricultural supply chains, field and scouting apps, drone flight software and IoT platforms, for clients including Milc, Caravela Coffee, AgroScout, DroneDeploy, Skippy Scout and Bluefin. We work as staff augmentation, dedicated teams or full product development, on hours that overlap the US working day.
If you are comparing development partners for agriculture software, we published a side-by-side of five of them, ourselves included: agtech development partners compared. For how we approach agriculture projects, see our agriculture software development page.
Frequently asked questions
Should an agtech company build or buy its farm management software?
Buy if you run a farm with a standard operation. Build if the software is part of the product you sell or your rules exist in no catalog. Many companies do both: they buy a platform like John Deere Operations Center or Climate FieldView and build the layer that makes them different.
When is an off-the-shelf agriculture ERP enough?
When your crops and workflows are common, your equipment already writes to a platform, and you have no engineering team to maintain custom software. In that situation configuration beats development on cost, speed and risk.
What does a custom ERP for row crop or grain operations include?
Usually not accounting, which is better bought. It covers what catalogs do not model: buying from other growers, contract and grading rules, lot tracking and lab results, storage and marketing, and integration with the accounting system you keep.
Can custom software connect to John Deere Operations Center or Climate FieldView?
Yes. Operations Center connects to third-party software through John Deere's connected partner program, and FieldView connects with more than 60 partners. Building on top of them is often cheaper and faster than replacing them.
What goes into a digital scouting app for agronomists and sales teams?
Field capture that works offline, GPS-tagged photos and observations, sampling points, and a report or recommendation the grower sees before the visit ends. Drone scouting adds automated flights that capture images at each scouting point, as Skippy Scout does.
What does API development for agriculture applications cover?
Three jobs: pulling data from equipment and farm platforms into your own system, exposing your data to growers' and partners' tools, and connecting new products to the ERP and accounting systems customers already run.
Can we buy a platform now and build later?
Yes, and it is often the smart order. Buy for the common work, learn exactly where the platform stops, then build only that gap. Keep your data exportable from the first day, so that building later is an integration and not a migration.
Who builds custom agriculture ERPs?
Development companies with named agriculture work you can check. CodigoDelSur built Atlas, the internal ERP Caravela Coffee uses for buying, export, import and lab testing, and has built agriculture software for Milc, AgroScout, Skippy Scout, DroneDeploy and Bluefin.
