For B2B and retail sales
Custom ecommerce platforms and product catalogs with ordering workflows, payments, shipping, customer portals, and integrations with your business systems
Categories, subcategories, product lines, and product pages are structured so customers can move from a broad product group to a specific model. Specifications, available configurations, images, pricing, and documents are presented together on each product page.
Filters use the criteria customers actually consider when selecting products, including application, size, material, capacity, manufacturer, price, and other specifications. Buyers can narrow the available options without reviewing the entire catalog one product at a time.
When the ecommerce platform is connected to an inventory or accounting system, prices, stock levels, and product availability are updated from the designated system of record. This reduces orders for unavailable items and eliminates the need for employees to update the catalog manually.
In a full ecommerce store, customers can add products to a cart, enter their information, select shipping, and choose a payment method. In a product catalog without online purchasing, they can submit selected items for pricing or request a formal quote from any device.
Along with the customer’s contact information, your team receives the selected products, quantities, prices, shipping and payment methods, customer notes, and acquisition source. Sales representatives do not have to contact the buyer again just to determine what they want to order.
B2B buyers can receive customer-specific pricing, minimum order quantities, case-pack requirements, payment terms, and access to account-specific documents. Through a customer portal, authorized buyers can repeat a previous order or create a new purchase using the terms assigned to their account.
Choosing the right commerce platform
The product catalog, checkout process, and B2B purchasing features are all parts of a single commerce platform. Its scope depends on the product range, pricing rules, sales terms, and order fulfillment workflow.
An ecommerce platform is appropriate when customers need to find products, review specifications, understand purchasing terms, and submit a complete order or request for quote without relying on a sales representative for every step.
The need for a custom platform is not determined by the number of products or the size of the company. A store with a limited product range may still require complex product configurations, shipping rules, and inventory management. A manufacturer with thousands of SKUs may only need a catalog where buyers assemble a product list and submit it for pricing.
A custom commerce platform makes sense when your company needs to:
A product catalog, shopping cart, online payment, and B2B customer portal are not separate websites. They are functions of a single commerce platform, selected according to how the company actually sells and fulfills orders.
Development begins with the product data structure. This includes categories and subcategories, manufacturers, product lines, models, configurations, units of measure, and the specifications customers use to compare products.
Each category may require its own set of attributes. Equipment may be compared by power, capacity, and voltage; building materials by dimensions, composition, and coverage; and apparel by size, color, and material. Applying one universal set of attributes to an entire catalog usually produces filters that are difficult or impossible to use.
A product page may include:
The catalog structure determines how search, filters, imports, price updates, related products, and product pages work. If product data is inconsistent from the beginning, adding a shopping cart or a polished design will not solve the underlying product-selection problem.
Not every product can be sold at a fixed public price. Some products only require the customer to select a quantity, shipping method, and payment option. Others require compatibility checks, configuration, technical review, freight calculation, or approval by a sales representative.
A single commerce platform can therefore support several purchasing workflows:
A checkout process without online payment is still part of the ecommerce platform. When customers select products and quantities and submit a complete order or RFQ, the website is supporting a structured purchasing workflow rather than collecting a generic sales inquiry.
In a retail purchasing flow, sales terms are generally the same for every customer. Visitors see public pricing, add products to a cart, and complete checkout without negotiating each order with a sales representative.
The retail side of an ecommerce platform may include:
The required features are defined before development begins. Customer accounts, loyalty programs, promo codes, and other capabilities are not added automatically unless they support the company’s actual sales model.
In B2B commerce, pricing and purchasing terms may depend on the customer account, contract, order volume, warehouse, region, or payment arrangement. After signing in, different buyers may therefore see different products, prices, documents, and available actions.
A B2B customer portal may include:
B2B features should not be developed simply to provide a customer login. They are justified when authentication changes pricing, product access, documents, ordering rules, or the actions available to a specific business account.
Before development begins, each type of source data and the system responsible for maintaining it must be identified. The same value should not be edited independently in multiple systems.
Responsibilities may be distributed across the platform as follows:
Not every project requires all of these integrations. If the catalog is small and prices rarely change, some data can be maintained through the website administration system. Integration becomes necessary when manual data entry begins causing delays, errors, duplicate work, or conflicting information.
Before interfaces are designed, the company must define its commerce rules, not just provide a list of pages. These rules determine the data structure, checkout process, customer portal, and required integrations.
The project must establish:
If these rules have not been defined within the company, the ecommerce platform cannot determine them on its own. Development automates an agreed sales and fulfillment process; it does not replace that process.
If a company sells only a few products and every order requires a custom quote from a sales representative, a business website with product pages and an inquiry form may be sufficient. A landing page may be more appropriate for promoting a single product or limited-time offer.
A full ecommerce platform may also be premature if the company has not established its product range, pricing, shipping terms, and order fulfillment process. Adding a cart and online payment can create the appearance of ecommerce without creating an operational process capable of fulfilling the order.
A custom ecommerce platform becomes necessary when the company is ready to manage products, pricing, inventory, and orders as one connected process. Customers receive a clear way to select and purchase products, while the seller receives a structured order containing the information required for processing and fulfillment.
How an ecommerce platform is built
Development begins by defining the products, pricing, customer types, checkout methods, payments, and shipping—not by designing the catalog. The project is divided into nine stages, each ending with a deliverable that can be reviewed and approved before work moves forward.
The first step is to determine who will purchase through the website: retail customers, B2B buyers, or both. Products are divided into those sold at a fixed price, those requiring a quote, and those available only to authenticated customers.
The project also defines checkout, payment, and shipping methods; the order approval workflow; user types; required integrations; and the features included in the initial release. Client-provided content, system access, and responsibilities are documented separately from the development work.
Stage deliverable: an approved commerce model, project scope, feature list, responsibilities, preliminary timeline, budget, and acceptance criteria.
Categories and subcategories, products and variants, SKUs, units of measure, specifications, pricing tiers, warehouses, inventory levels, images, and related documents are defined. Each product category receives its own set of attributes for product pages and filters.
This stage also establishes where each type of data will be maintained. Descriptions and images may be managed through the website, while SKUs, pricing, and inventory may come from an ERP, accounting, or inventory management system.
Stage deliverable: an approved catalog structure, product data model, list of attributes and filters, and identified systems of record.
The customer journey is designed from entry into the catalog through completion of the intended action. Search, filtering, comparison, product configuration, cart management, quote requests, shipping, payment, and order confirmation are addressed as separate parts of the workflow.
Different workflows are created for retail and B2B customers when authentication changes pricing, product availability, minimum order quantities, documents, or checkout options. Exception scenarios are also considered, including unavailable products, price changes, and temporary outages of connected services.
Stage deliverable: approved wireframes for the catalog, product pages, cart, checkout, customer portals, and other required interfaces.
Product descriptions, specifications, images, pricing, inventory data, certificates, manuals, and other materials are collected. Before catalog population begins, the project defines which data the client will provide, which data requires processing, and who is responsible for its accuracy.
If products are being transferred from an existing website, spreadsheets, or an internal system, fields, categories, attributes, and variants are mapped to the new data model. A representative sample is imported first so product pages, images, pricing, documents, and duplicate-prevention rules can be verified.
Stage deliverable: a prepared content package, documented migration rules, and a validated test import.
Approved wireframes are developed into designs for the catalog, filters, product pages, cart, checkout, customer portals, tables, and other required components. Interfaces are designed for desktop monitors, laptops, tablets, smartphones, and intermediate screen sizes.
Each layout is reviewed to ensure that users can select product variants, change quantities, review specifications, enter required information, choose shipping, and complete the intended workflow without hidden or inaccessible controls.
Stage deliverable: approved designs for the platform’s primary pages, interface states, and purchasing workflows.
The product catalog, product pages, search, filters, cart, order forms, customer portals, and other approved features are developed. The administration system is configured to manage categories, products, content, and the data intended to be maintained directly through the website.
Public pages receive structured URLs, page titles, descriptions, indexing rules, an XML sitemap, and other required technical settings. Completed parts of the platform are deployed incrementally to a staging environment for client review.
Stage deliverable: a working ecommerce platform with the approved functionality and administration system available in the staging environment.
Approved payment gateways, CRM and ERP platforms, accounting and inventory systems, shipping services, analytics tools, and other systems are connected. Each integration defines which data is exchanged, the direction of the exchange, and which platform serves as the system of record.
Successful and failed transactions, retry behavior, and integration logging are tested. Once the data flow has been validated, the approved products, variants, pricing, inventory, documents, and other prepared data are imported into the platform.
Stage deliverable: a populated ecommerce platform with working connections to the approved internal and external systems.
Categories, search, filters, product pages, variants, the cart, forms, customer portals, notifications, and supported devices are tested. Retail and B2B pricing, user permissions, and the actions available to each customer type are verified separately.
Testing covers both successful purchases and failure scenarios, including unavailable products, price changes, declined payments, duplicate order submissions, unavailable shipping services, and delayed responses from connected systems. The destination of each order and the information received by customers and internal teams are also verified.
The client performs user acceptance testing based on the previously approved scenarios. Defects and deviations from the agreed requirements are corrected before the platform is released to production.
Stage deliverable: a tested and client-approved ecommerce platform ready to process live customers and orders.
The ecommerce platform is deployed to the production server, the domain and secure connection are configured, and product, pricing, and inventory data receive a final update. After launch, a test order is completed to verify payment, shipping, notifications, analytics, and data transfer to connected systems.
Designated employees receive instructions and training for managing products, orders, documents, and the approved administrative functions. If backups, error logging, and monitoring are included in the project, they are also verified after deployment.
The client receives the source code, administrative and server access, credentials for connected services, deployment instructions, and technical documentation. Ongoing support, platform development, and additional features are handled under a separate scope.
Stage deliverable: a live ecommerce platform that has successfully processed a test order and has been fully transferred to the client’s control.
Pricing principles
Projects start at $3,000. Before development begins, the scope of the commerce platform, the cost of each stage, and the deliverables the client will receive are defined and approved.
Development is estimated at $55 per hour. Most ecommerce website and product catalog projects range from approximately $3,000 to $9,460. The final cost depends on the catalog structure, product data model, purchasing workflows, payment and shipping requirements, volume of product data, B2B capabilities, and required integrations.
An ecommerce website without customer portals, account-specific pricing, or complex data synchronization requires fewer development hours. B2B portals, multiple pricing tiers, warehouse-level inventory, large catalog migrations, and integrations with CRM, ERP, accounting, or inventory systems are estimated separately and included only after approval.
Payments are divided by project stage. Before each stage begins, the client knows its scope, estimated hours, cost, and expected deliverable. Additional features and services are not added to an invoice without prior approval.
Domain registration, hosting infrastructure, software licenses, payment processing fees, CRM and ERP subscriptions, telephony, SMS and email services, paid APIs, shipping providers, cloud storage, and third-party professional services are not included in the development fee and are billed separately when required.
| Project stage | Scope of work | Estimated hours |
|---|---|---|
| Commerce model and project scope | Define customer types, sales workflows, checkout, payment, and shipping methods. Document the initial release, client and developer responsibilities, data sources, and project acceptance criteria | 5–8 hrs. |
| Product data model and catalog structure | Design categories, products, variants, SKUs, units of measure, specifications, pricing tiers, inventory data, documents, filters, and relationships between products | 5–10 hrs. |
| Purchasing workflows and wireframes | Design search, filtering, product pages, the shopping cart, quote requests, checkout, and the required purchasing workflows for retail customers and B2B buyers | 6–10 hrs. |
| Content preparation and test import | Structure product descriptions, specifications, images, and documents. Map source fields, define migration rules, and validate a representative sample in the new catalog | 4–8 hrs. |
| Interface design and responsive adaptation | Design the catalog, product pages, cart, checkout, forms, tables, and other interfaces for desktop computers, tablets, smartphones, and intermediate screen sizes | 8–14 hrs. |
| Platform and administration development | Develop the catalog, product pages, search, filters, cart, order forms, data models, and administration tools required to manage products and website content | 13–26 hrs. |
| Payment and shipping integration | Connect a payment gateway and configure payment statuses, shipping methods, rate calculations, customer notifications, and handling for successful and failed transactions | Optional: 4–12 hrs. |
| CRM, ERP, and business system integrations | Connect CRM, ERP, accounting, inventory, and other business systems. Configure the exchange of products, pricing, inventory, and orders, including error handling and integration logging | Optional: 8–30 hrs. |
| B2B customer portals and account-specific terms | Implement authenticated business accounts, customer-specific pricing, minimum order quantities, case-pack rules, account documents, reordering, user roles, and other approved B2B purchasing features | Optional: 8–30 hrs. |
| Technical preparation of public pages | Configure page titles and descriptions, Open Graph data, product structured data, XML sitemap, robots.txt, indexing rules, URL structure, and other technical settings for public pages | 3–6 hrs. |
| Quality assurance and user acceptance testing | Test the catalog, search, filters, pricing, cart, orders, user permissions, notifications, and integrations. Verify successful and failed workflows and conduct client acceptance testing | 6–10 hrs. |
| Launch, training, and project handoff | Deploy the platform to production, perform a final data update, complete a test order, train designated employees, and transfer the source code, access credentials, and technical documentation | 5–8 hrs. |
| Estimated project scope | The final scope is determined after the commerce model, catalog structure, product data, purchasing workflows, B2B requirements, and required integrations have been approved | 55–172 hrs. |
| Estimated development cost | Projects start at $3,000. The final estimate is calculated at $55 per hour, with optional features and integrations included only when required by the approved scope | $3,000–$9,460 |
No fine print
What the project includes, where product and pricing data is maintained, what the client provides, and which expenses are billed separately
A product catalog presents the company’s products, specifications, and purchasing terms but does not necessarily allow customers to complete a purchase online. Visitors may submit an inquiry, request a quote, or contact a sales representative.
An ecommerce website also supports purchasing operations such as product and variant selection, price calculation, cart management, checkout, payment, shipping, notifications, and data exchange with internal business systems. The required functionality depends on the company’s sales model.
Yes. A customer can submit an order through the website and pay after a sales representative confirms availability and terms. Payment may be collected by invoice, ACH or wire transfer, or another approved method.
Products without a fixed price can use a request-for-quote workflow instead of immediate checkout. This approach is common for manufacturers, wholesalers, distributors, and other B2B companies when pricing depends on order volume, product configuration, or delivery terms.
This is determined before development begins. A smaller store may manage all product data through the website administration system. If the company uses an ERP, accounting, or inventory platform, that platform may remain the system of record for SKUs, pricing, and inventory while the website receives scheduled or real-time updates.
A system of record is defined for each type of data. This prevents website changes from being overwritten during the next synchronization and avoids conflicting values across multiple systems.
Yes, provided the source data can be exported or technically extracted. Before the full migration, categories, attributes, variants, images, pricing, documents, and relationships between products are reviewed.
A representative sample is imported first. After the structure has been validated and identified issues have been corrected, the approved catalog volume is migrated. Data preparation, cleanup, and migration are estimated separately because 1,000 complete product records and 1,000 inconsistent rows distributed across multiple spreadsheets require very different amounts of work.
The platform can exchange data with CRM, ERP, accounting and inventory systems, payment gateways, shipping providers, marketplaces, analytics platforms, and other business services.
Integration depends on the availability of an API, supported connector, export format, or another documented method of data exchange. Before development begins, the external system’s documentation, available data, direction of exchange, authentication requirements, and error-handling capabilities are reviewed. If a system does not provide a supported connection method, that limitation is identified before the integration is added to the estimate.
The client typically provides product data and sales rules, descriptions, specifications, images, pricing, documents, payment and shipping requirements, and the credentials and technical documentation required for approved integrations.
Before work begins, the project defines who will prepare each type of content, who is responsible for its accuracy, how much catalog population is included, and the format in which data will be delivered. Additional processing of content, images, or product spreadsheets is estimated separately when required.
The development fee covers only the approved stages and functionality, which may include discovery, architecture, interface design, development, administration setup, approved integrations, testing, deployment, and project handoff. Development is estimated at $55 per hour, and projects start at $3,000.
Before development begins, the client receives an estimate listing the tasks, expected hours, cost, and deliverable for each stage. Additional work is not added to an invoice without prior approval.
Domain registration, hosting infrastructure, software licenses, payment processing fees, CRM and ERP subscriptions, voice and messaging services, SMS and email services, paid APIs, shipping providers, cloud storage, and other third-party products are billed separately.
These payments are made to the respective providers rather than to the developer. Required services, pricing, billing frequency, and account ownership are identified before the services are connected.
The public website receives a technical SEO foundation that includes structured URLs, page titles and descriptions, indexing directives, an XML sitemap, robots.txt, canonical tags, Open Graph data, and applicable product structured data.
Product variants, filters, pagination, empty categories, duplicate pages, and discontinued products are addressed separately when defining indexing rules. Technical preparation does not guarantee search rankings. Results also depend on demand, competition, product selection, page content, website authority, and ongoing SEO work.
After the approved work has been completed and paid for, the client receives the project source code, administrative and server access, deployment instructions, and the technical documentation included in the project scope.
Accounts for the domain, hosting, payment gateway, CRM, and other third-party services should be registered under the client’s ownership and billing information. This allows the company to control its infrastructure independently of any future work with the developer.
Yes. New product categories, customer portals, account-specific pricing, loyalty programs, payment and shipping methods, marketplace integrations, and other capabilities can be added after launch.
Future expansion is considered when the platform architecture is designed, but each new capability is estimated as a separate scope of work. A change involving the product data model, pricing rules, user roles, checkout process, or connected systems may require updates to several related parts of the platform.
Get in touch
Describe your task, current situation, and expected outcome. I will review your request and contact you to discuss the project, timeline, and possible working arrangements.
All fields marked with are required.