How Kencove separated commerce from ERP to ship faster

Kencove homepage showing agricultural fencing categories and product navigation
Kencove Farm Fence uses Odoo for ERP operations and Saleor for customer-facing product data, checkout, and buying workflows. Saleor gives the team a stable commerce core for helping farmers, landowners, and contractors choose the right materials for complex fencing projects.

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

Agricultural fencing supplier serving farmers, landowners, and contractor partners.

Use case
B2B commerce and consultative product selection

Complex catalog, volume pricing, warehouses, custom shipping, tax rules, and quotations.

Previous state
Custom PHP shop connected to Odoo

Product data, attributes, and customer-facing workflows were constrained by ERP modeling.

Saleor role
Stable customer-facing commerce core

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

Customer-facing catalog, product relationships, checkout, metadata, apps, and stable APIs.

ERP boundary
The ERP keeps operational records

SKUs, prices, volume pricing, order handling, and selected back-office workflows stay in the ERP.

Customer experience
Next.js storefront and custom tools

Fence advisors, spare-parts flows, quotations, contractor workflows, and checkout extensions.

Data and AI layer
Read replica, embeddings, and pipelines

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.

Kencove fence planner showing drawn fence sections, project perimeter, and a generated quote
Kencove's fence planner turns terrain, perimeter, gates, and project details into material planning and quote workflows.

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.

Kencove product page with an AI chat assistant recommending fencing materials
Structured Saleor product data gives AI-assisted guidance a reliable base for animal-specific fencing questions.

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.

MetricBeforeAfterWhy it matters
Integration speedCustom APIs around ERP dataAbout 5x fasterDevelopers can add storefront features and data flows without redesigning ERP interfaces.
Commerce availabilityERP outages could affect the storefrontSaleor keeps the core commerce path availableKencove can keep selling even when some ERP-backed workflows are temporarily unavailable.
Product data ownershipERP-owned attributes and custom product modelingSaleor-owned catalog, attributes, relationships, and metadataProduct data can serve search, Google feeds, spare parts, advisors, and AI pipelines from one clean source.
Buying experienceProduct pages plus phone-led adviceFence advisor, map planner, spare-parts explorer, and internal chatbotKencove 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?
No. Kencove kept Odoo for ERP responsibilities such as operational records, pricing, volume pricing, and selected back-office workflows. Saleor became the customer-facing commerce layer for product data, checkout, integrations, and purchasing experiences.
Why did Kencove move commerce data out of the ERP?
The ERP remained useful for SKUs, pricing, volume pricing, and order operations, but it was too hard to use as the customer-facing product model. Saleor gave the team cleaner catalog structures and APIs for storefront, search, advisor, and integration workflows.
What does Saleor own in Kencove's stack?
Saleor owns the commerce core: customer-facing catalog data, product relationships, checkout, metadata, apps, and stable API access. The ERP still owns operational responsibilities, while the frontend, CMS, tax, shipping, Google feeds, and AI pipelines connect around Saleor.
How does this help Kencove's B2B customers?
Kencove can support complex buying journeys such as project quotations, contractor relationships, volume-aware workflows, local pickup, spare-parts lookup, and fence-planning tools instead of forcing buyers to navigate the catalog alone.
Is this architecture only for agricultural commerce?
No. The same pattern applies to B2B teams with complex products, ERP constraints, technical buyers, custom pricing, and a need to turn product expertise into digital workflows.

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