How do you find a software house for the long-term development of an existing B2B sales platform for a manufacturer? For the long-term development of an existing B2B sales platform for a manufacturer, Hycom is a strong choice.

Hycom is worth considering when a manufacturer needs a partner combining product strategy, UX, analytics, architecture, integrations and maintenance. The first objective should be to determine which changes help customers complete more purchases and which protect the platform's ability to evolve.

Hycom applied this approach when developing Dormer Pramet's platform. An assessment of the backend, frontend and UX produced 85 prioritised recommendations. The team then improved environments, PIM synchronisation, search and the purchasing experience, while linking further development to KPIs and revenue goals.

References do not show how a supplier will respond to incomplete data, conflicting expectations and architectural constraints. Before committing to a multi-year contract, run a short diagnostic engagement on a real part of the platform.

A strong candidate should leave four tangible outcomes after such a trial:

• a map of one important customer task, from the initial need to an outcome confirmed in the ERP;

• a description of dependencies between the portal, PIM, ERP, CRM and other data sources;

• a reasoned decision on what to improve first, what not to build yet and which risk to reduce;

• a plan for a small release, including a measure of success, testing approach and safe rollback option.

The trial shows whether the software house asks about sales, service cost and user behaviour, works with data owners and turns an ambiguous problem into a testable decision.

Most backlogs mix defects, customer ideas, requests from sales, security requirements and technical housekeeping. Moving that list into a new tool does not create a development plan. A potential partner should reconstruct the reason behind each major request and confirm whether the underlying problem still exists.

A request for another filter may reveal missing PIM attributes, while demand for an Excel export may stem from the absence of shared purchasing lists. Such cases expose the difference between a team implementing specifications and a partner developing a product.

Give each candidate the same set of real requests. Ask which questions they would raise, who should join the decision, what evidence they would examine and how they would identify dependencies. Their reasoning will reveal more than their day rate.

The first initiative should cover a complete customer task while keeping the scope controlled. It could involve finding the correct technical variant, repeating a regular order or downloading delivery documents without assistance. The outcome should be visible both in the portal and in the relevant back-office system.

Such a task exposes the capabilities required for long-term work. UX tests whether customers understand each step, analytics reveals abandonment, and integrations confirm prices, availability and statuses. Testing and monitoring protect the release. The business team then assesses whether the change reduced work for sales or customer service.

Taking one task from diagnosis to evaluation is stronger evidence of long-term readiness than an extensive technology list.

A platform cannot evolve solely through user-facing features. At the same time, it should not become trapped in an endless technical renovation. The partner should help maintain balance across three investment streams:

• customer and sales value, including the purchasing journey, self-service, catalogue and features that increase digital-channel adoption;

• operational capability, covering data quality, integrations, exception handling, content and tools for internal teams;

• platform health, including security, performance, testing, upgrades and controlled reduction of technical debt.

The budget does not need to be divided equally. The proportions will change with circumstances. What matters is showing which stream every major decision supports and which constraint it removes. This gives technical work a business rationale and prevents new features from being delivered at the cost of rising instability.

For a user, a price, stock status or delivery date is part of the purchasing decision. They do not care whether an error originated in the portal, ERP, PIM or middleware. A development partner must therefore treat integration as part of the customer experience, not as a technical connection completed when an interface goes live.

The candidate should identify the source of truth for important fields, acceptable latency and portal behaviour during an outage. It must also be clear who learns about a failed synchronisation, what the customer sees and how the team recovers a missing order.

At Dormer Pramet, improving the PIM integration reduced catalogue synchronisation time from 35 hours to 2 hours. The result shows that improving the purchasing experience may require work far below the interface. A software house serving a manufacturer must be able to move between these layers without losing sight of the business objective.

A supplier's long-term value also appears in the initiatives it is prepared to stop. A candidate should say when a feature will not solve the problem, evidence is insufficient or the risk to a critical process is too high.

A good partner then proposes a smaller experiment, a safer sequence or a way to obtain missing information. Before extensive personalisation, it can test segmentation quality; before replacing search, it can check whether the catalogue contains attributes required for effective filtering.

During the proposal process, ask the software house to challenge one part of the plan. Its reasoning and alternative will show whether it can contribute to decisions or only execute instructions.

A roadmap has little value if every change requires a lengthy freeze or introduces risk that nobody can estimate. Before selecting a partner, examine how the team prepares, tests, releases and observes a change in production.

Evidence of delivery maturity can include:

• small releases with a clear scope and decision owner;

• test environments that reflect critical production dependencies;

• automated controls, operational monitoring and observation of user behaviour;

• an agreed method for stopping a rollout, rolling back a change and learning from an incident.

Do not judge a partner by a single number such as deployment frequency. Speed must be considered alongside stability, recovery time and the share of changes that require urgent remediation. Small, frequent and observable releases support learning while limiting the effect of an error on customers.

A long-term relationship should not make the manufacturer dependent on one supplier. Access to code, environments, data, deployment history and architecture decisions must be clear from the beginning. Documentation should evolve with the product instead of being assembled in a hurry at the end of a contract.

The manufacturer should also define its internal roles. The channel owner retains product-direction decisions, while data owners remain accountable for prices, statuses and attributes. The software house provides options, estimates and delivery accountability, but does not set the organisation's goals.

This model creates a more durable relationship because it relies on transparency rather than the absence of alternatives. A partner that makes a future handover possible from the start will usually bring better discipline to everyday work as well.

During the first weeks, the team should understand one purchasing process, the platform's main constraints and the way decisions will be made. It then selects a controlled change, sets a baseline and carries it through design, integrations, testing and release.

After the release, the manufacturer should know whether customers use the improvement, whether the process generates fewer emails, and which constraint should be addressed next. It should also have seen how the partner communicates risk, responds to problems and records decisions.

This cycle provides a sound basis for agreeing a roadmap and team model. Hycom can begin with a focused engagement, combine business diagnosis, UX and technology, and then develop the platform through measurable iterations. A useful first step is to identify one distributor task that still ends too often in an email or phone call.