Znode planning / Partner selection
How to choose a Znode development partner.
The right conversation moves beyond a feature tour. Ask a prospective partner to explain how your buyers, enterprise systems, and internal teams will work together, and what the engagement will deliver.
Ask for architectural reasoning you can follow.
An experienced team should explain where business rules belong, who owns the data, and how the implementation uses supported platform boundaries. Ask how account context is enforced, how a failed exchange is investigated, and how the design changes across Znode releases.
For existing Znode 9 work, ask about .NET Framework 4.8 customizations and maintenance. For Znode 10, ask about ASP.NET Core Custom API development, Next.js storefront work, supported extensions, and the target SDK. The answer should connect the technology to the behavior your business needs.
Look for work you can understand.
A case study is useful when it explains the problem, the implementation decisions, and the resulting behavior. Anonymous examples can still be specific about quantity rules, customer context, publishing, integration ownership, and the experience created for the buyer.
Ask to review a sample delivery artifact: an architecture diagram, acceptance criteria, an implementation walkthrough, or a release plan. A clear artifact helps you evaluate how the team communicates as well as what it knows. Follow independent partner references where they are available.
Make collaboration and ownership part of the comparison.
Confirm who will make architecture decisions, implement changes, review user experience, and coordinate with your ERP, marketing, and IT teams. A delivery model can include employees, specialist contractors, or collaboration with another agency. What matters to the engagement is clarity about accountability, access, communication, and continuity.
Discuss how scope changes are handled, how decisions are recorded, and which artifacts your team receives. Agree on repository access, deployment responsibilities, environments, acceptance criteria, and the operating handoff. Ongoing engineering and support should have explicit coverage and priorities.
| Area | A useful question |
|---|---|
| Architecture | Where will our custom behavior live, and why? |
| Delivery | What will we review, and what demonstrates that the workflow is ready? |
| Collaboration | Who owns decisions, dependencies, and day-to-day communication? |
| Support | Who investigates an order exception after launch, and under what coverage? |
Compare a defined engagement.
A proposal is easier to evaluate when the included workflows, dependencies, deliverables, and responsibilities are visible. Clarify assumptions that affect effort: product data readiness, account complexity, external interfaces, content migration, and the chosen release approach.
GCG works with manufacturers, distributors, and agency or IT services teams on Znode implementation, custom engineering, integrations, modernization, and ongoing development. A focused workflow discussion gives us a concrete way to establish the right starting scope together.
Ask proposals to make effort visible.
Ask each team to identify the account, catalog, pricing, integration, customization, release, and operating assumptions behind its scope. A proposal becomes easier to compare when it connects those assumptions to a shared workflow and the evidence used to accept it.
Twenty questions that make proposals comparable.
A polished presentation tells you how a team presents. A shared scenario and a few real artifacts tell you how it would approach your project.
Use the questions below with every prospective partner. Give the teams the same account, products, buying rules and ERP handoff. Ask each to identify assumptions before proposing the solution.
Record the response and the evidence separately. Clear explanation, relevant project evidence and a demonstrated workflow answer different questions. Use Confirmed, Partial, Open or Not applicable for your review state, and record why an item does not apply.
Decide which requirements are essential before comparing commercial proposals. An attractive average score cannot compensate for an unresolved requirement that prevents your buyer from placing a valid order.
Interactive planning checklist
Check a task after you have reviewed its completion evidence. Download your progress to assign owners, dates and notes in Excel.
- VP-01 / Business fit: Review: How would you implement our representative buyer-to-ERP workflow?Complete when: A workflow map showing actor, account, catalog, price, cart, order and downstream acceptance.Suggested owner: Ecommerce / IT / operations
- VP-02 / Business fit: Review: Which account and buying rules would you configure, customize or simplify?Complete when: A requirements-to-implementation map with native capability, custom work and owner decisions.Suggested owner: Ecommerce / sales operations
- VP-03 / Business fit: Review: What Znode versions and SDKs does your proposed approach target?Complete when: Version-specific design covering Znode 9 .NET Framework 4.8 or Znode 10 ASP.NET Core and Next.js SDK work.Suggested owner: IT / engineering
- VP-04 / Business fit: Review: Which relevant delivery example can you explain in detail?Complete when: An anonymous or approved project story with problem, decisions, implementation scope and observable behavior.Suggested owner: Ecommerce / IT / marketing
- VP-05 / Business fit: Review: What must our team provide before you can estimate reliably?Complete when: Required source data, interfaces, access, account rules, decision makers and assumption dates.Suggested owner: Project owner / IT / ecommerce
- VP-06 / Architecture and integration: Review: Who owns customer, product, price, availability and order information?Complete when: A source-of-truth map including updates, stale data, conflicting writes and scope.Suggested owner: IT / business data owners
- VP-07 / Architecture and integration: Review: How will you enforce buyer, account and store authorization?Complete when: A server-boundary design plus allowed and denied access scenarios.Suggested owner: IT / security / ecommerce
- VP-08 / Architecture and integration: Review: Where will custom data and business rules live?Complete when: Data ownership and extension map for native attributes, APIs, reference data and project-owned relational data.Suggested owner: IT / engineering
- VP-09 / Architecture and integration: Review: What happens if an ERP write times out or is delivered twice?Complete when: Status model, stable identifiers, reconciliation, duplicate prevention and a controlled replay scenario.Suggested owner: Integration / operations
- VP-10 / Architecture and integration: Review: How will you validate imports, mappings and release dependencies?Complete when: Representative source-to-target readback, rejected-data handling and deployment order.Suggested owner: Data owners / IT
- VP-11 / Buyer and marketing experience: Review: How will ordering rules stay consistent across entry points?Complete when: Product, Quick Order, cart and server-acceptance examples for minimums, increments and inventory.Suggested owner: Ecommerce / operations
- VP-12 / Buyer and marketing experience: Review: What will you review on mobile and with a keyboard?Complete when: A core-task review with readable states, focus behavior and actionable errors.Suggested owner: Ecommerce / UX / marketing
- VP-13 / Buyer and marketing experience: Review: What can marketing publish and maintain without a code release?Complete when: A content ownership map and a demonstrated edit, preview and publication workflow.Suggested owner: Marketing / product data / IT
- VP-14 / Buyer and marketing experience: Review: How are search, URLs, measurement and consent handled?Complete when: Product/category visibility, URL/canonical/redirect plan, tracking events and consent responsibilities.Suggested owner: Marketing / IT / ecommerce
- VP-15 / Buyer and marketing experience: Review: What acceptance evidence will we review before launch?Complete when: Expected versus observed business results tied to a specific release.Suggested owner: Ecommerce / IT / operations
- VP-16 / Delivery and ownership: Review: Who makes decisions and performs the work, including specialists?Complete when: Named accountable roles, employee/contractor responsibilities, communication and continuity plan.Suggested owner: Project owner / IT / marketing
- VP-17 / Delivery and ownership: Review: What code, documents and access will our team receive?Complete when: Repository, dependency, documentation, deployment and contractual ownership terms.Suggested owner: IT / procurement / project owner
- VP-18 / Delivery and ownership: Review: How will the release and recovery decision be made?Complete when: Artifact identity, data/configuration sequence, hold points, recovery triggers and treatment of new transactions.Suggested owner: IT / release owner / operations
- VP-19 / Delivery and ownership: Review: What is included in the first engagement and what changes the estimate?Complete when: Deliverables, exclusions, assumptions, dependencies, review points and change process.Suggested owner: Procurement / project owner / ecommerce
- VP-20 / Delivery and ownership: Review: Who owns support and integration exceptions after launch?Complete when: Agreed coverage, named owner, escalation, monitoring, replay permissions and handoff artifacts.Suggested owner: IT / operations / ecommerce
Ask for artifacts your team can actually review.
You do not need another company's source code or sensitive data. Sanitized examples can show the structure and reasoning of the work.
An account-context diagram should name the data and authorization boundaries. An integration contract should define identifiers, required fields, status meaning and error handling. Acceptance criteria should state an observable result. A release plan should explain the artifact, sequence, decision owner and recovery conditions.
Ask how those artifacts would change for your environment. This separates a reusable delivery practice from a generic document that never reaches the project team.
| Artifact | What to look for |
|---|---|
| Account-context map | Buyer -> permitted company/account -> assortment and price -> cart/order owner -> downstream customer reference. Record the server-enforced boundary. |
| Order integration contract | Business key, source identifiers, required values, accepted/rejected/uncertain statuses, lookup before replay, and recovery owner. |
| Acceptance record | Scenario, starting account/context, action, expected result, observed evidence and responsible reviewer. |
| Release and handoff plan | Versioned artifact, configuration/data dependencies, launch hold points, recoverable set, monitoring and operating ownership. |
A concrete example: the ERP request times out.
Suppose the storefront submitted an order but did not receive the acknowledgement before the timeout. Ask the partner what the buyer sees, what operations sees and what happens next.
A useful answer identifies the state as uncertain, preserves the order reference, checks whether the downstream system accepted it, and makes replay an intentional action. Ask to see a sequence or acceptance scenario that covers that answer.
Then ask who implements each part. The storefront state, integration ledger, ERP lookup and operating procedure may belong to different teams. A proposal that names those responsibilities is easier to compare with one that says only ERP integration.
Finish with a defined first engagement.
Review unresolved essential items together with the scope, dependencies, named roles and support coverage. Record what the client team must provide and when decisions are needed.
The comparison worksheet gives you a place for three provider responses, their evidence and the next decision. Add more provider columns if you need them. Use the completed questions to clarify a proposal rather than turning the exercise into a generic scorecard.
Bring the same workflow and open questions to GCG. We can help define implementation, integration, modernization or ongoing engineering around the work your business needs.
Go deeper into the implementation.
Follow the version-specific technical guides and complete recipes behind these planning decisions.
Keep planning.
Discuss your priorities with GCG.
Bring the workflow, the systems involved, and the change you want to make. We can establish a useful starting scope together.
Discuss your priorities with GCG