May 29, 2026
How Kencove separated commerce from ERP to ship faster

Kencove Farm Fence supplies fencing, gates, energizers, and related equipment for farms, rural properties, and fencing contractors. The company combines online catalog sales with practical guidance for animal containment, perimeter fencing, replacement parts, and project materials.
Before Saleor, that product guidance had to fit through a custom PHP shop pulling data from Odoo. The ERP handled operational records, SKUs, pricing, and volume pricing, but ERP-shaped product data made customer-facing catalog work, attributes, search, alternatives, and product relationships difficult to evolve.
- Customer
- Kencove Farm Fence
- Use case
- B2B commerce and consultative product selection
- Previous state
- Custom PHP shop connected to Odoo
- Saleor role
- Stable customer-facing commerce core
Agricultural fencing supplier serving farmers, landowners, and contractor partners.
Complex catalog, volume pricing, warehouses, custom shipping, tax rules, and quotations.
Product data, attributes, and customer-facing workflows were constrained by ERP modeling.
Catalog, relationships, checkout, metadata, apps, and read-replica access for downstream tools.
The trigger
Kencove wanted a storefront that could do more than list products. Buyers often need to know whether a fence type fits their animals, how much material their perimeter needs, what alternatives exist when an item is deprecated, and which spare part matches a mechanical product they already own.
The old stack made that hard. Any new customer-facing feature depended on product data locked inside ERP structures and custom APIs. The team needed a cleaner commerce layer that product specialists could understand, customers could rely on, and developers could build on.
Why Kencove chose Saleor
The decision started with a need for better product organization and a more interactive shop. Saleor's open-source character mattered because the team valued transparency, standard technologies, and the ability to inspect or contribute to the surrounding app ecosystem.
In practice, the largest change was architectural. Kencove kept Odoo for the data the ERP still needed to own, while moving customer-facing catalog data, attributes, relationships, and commerce workflows into Saleor.
Odoo remained useful and customizable for back-office work, but Kencove did not want the commerce experience to depend on the same surface. Saleor became the stable runtime for the storefront and the structured endpoint around which new tools could be built.
You need to be sure that you have a core engine that just runs. Saleor gives you the headspace to solve these challenges.
Jannik Zinkl, Co-founder at TRWK
Defining the boundary between ERP and commerce
Saleor gave Kencove a structured product model and a GraphQL API that surrounding tools could rely on. Product specialists use the Dashboard to update catalog data, while SEO and content work can improve descriptions and categories without exposing ERP complexity to customers.
Developers model recommended items, alternatives, spare-part relationships, shipping groups, loyalty metadata, and storefront-specific workflows through Saleor data and apps. When a workflow belongs elsewhere, Saleor still acts as the commerce source that the frontend, CMS, ERP, tax, shipping, search, and AI agents can query.
Kencove uses hosted Saleor apps for CMS integration, Google Merchant Center product feeds, AvaTax, and Authorize.net. For Kencove-specific requirements, TRWK built additional Saleor apps for custom shipping logic and voucher-based loyalty.
Kencove designed the stack so Saleor and the frontend stay on the customer-facing critical path, while ERP-dependent features are isolated where possible.
- Commerce core
- Saleor Cloud
- ERP boundary
- The ERP keeps operational records
- Customer experience
- Next.js storefront and custom tools
- Data and AI layer
- Read replica, embeddings, and pipelines
Customer-facing catalog, product relationships, checkout, metadata, apps, and stable APIs.
SKUs, prices, volume pricing, order handling, and selected back-office workflows stay in the ERP.
Fence advisors, spare-parts flows, quotations, contractor workflows, and checkout extensions.
Product attributes and manuals feed internal search, catalog assistance, and future agentic workflows.
Building consultative commerce
Once product data became queryable, Kencove could turn domain knowledge into digital workflows. A beta fence advisor asks what a customer is building and recommends the materials required. A map-based planner in development lets customers draw fence lines on real terrain, choose the animals they need to contain, estimate the bill of materials, and connect with contractor partners when installation help is needed.

The same pattern applies after purchase. A spare-parts explorer connects product diagrams to replacement products, helping customers and internal teams find the right part without relying on exact product-name searches.

Making Saleor the reliable layer
Odoo stays valuable for ERP work, but it is not the surface Kencove wants customers to depend on while shopping. With Saleor Cloud in the middle, Kencove can design the storefront around a commerce layer that stays available even when upstream systems have problems.
Saleor is always available. Our ERP isn't. So we build our reliability around Saleor.
Jannik Zinkl, Co-founder at TRWK
That does not mean every back-office process is independent from the ERP. New loyalty enrollment or ERP-backed tax exemption processing may still depend on upstream systems. But the core storefront and checkout can continue operating because Saleor owns the customer-facing commerce data and APIs.
| Metric | Before | After | Why it matters |
|---|---|---|---|
| Integration speed | Custom APIs around ERP data | About 5x faster | Developers can add storefront features and data flows without redesigning ERP interfaces. |
| Commerce availability | ERP outages could affect the storefront | Saleor keeps the core commerce path available | Kencove can keep selling even when some ERP-backed workflows are temporarily unavailable. |
| Product data ownership | ERP-owned attributes and custom product modeling | Saleor-owned catalog, attributes, relationships, and metadata | Product data can serve search, Google feeds, spare parts, advisors, and AI pipelines from one clean source. |
| Buying experience | Product pages plus phone-led advice | Fence advisor, map planner, spare-parts explorer, and internal chatbot | Kencove can move more expertise online while still supporting farmers and contractor partners. |
What similar teams can learn
This pattern fits B2B commerce teams whose ERP is necessary but too rigid to own the customer experience. Saleor works best here as a commerce core with clear system boundaries: the ERP keeps operational truth, while Saleor owns the product model, checkout, APIs, app ecosystem, and customer-facing commerce workflows.
That combination lets Kencove keep the business rules that make its model specific, from B2B pricing and shipping to quotations and advisor experiences, while giving developers a stable commerce foundation for building new customer workflows.
Did Kencove replace Odoo with Saleor?
Why did Kencove move commerce data out of the ERP?
What does Saleor own in Kencove's stack?
How does this help Kencove's B2B customers?
Is this architecture only for agricultural commerce?
B2B commerce
Need more room to build around your ERP?
See how Saleor helps teams keep the ERP in place while moving faster on commerce.
Talk to us