When a Malaysian SME is looking for custom software, one of the first questions is often, “Have you done this industry before?” A pet food factory owner may ask whether the vendor has handled pet food manufacturing. A membership association may want to see a previous membership system the vendor has done before. A logistics company may ask for a similar delivery project. Software Vendor Experience feels like a safer starting point because a familiar reference makes the vendor easier to trust before any detailed discussion. However, that reference tell you nothing, but only what the vendor has done before.
The difficulty is that custom software is not a ready-made product bought off the shelf. The new system is built around your own people, workflow, approvals, exceptions and reporting needs. Two companies in the same industry can operate very differently. The real concern is therefore not whether the vendor has done something similar, but it is whether the vendor can understand and deliver what your business actually needs.
Does Software Vendor Experience Guarantee Success?
No. Industry experience may shorten the learning curve, but it cannot guarantee a good fit for the new system.
- Previous projects offer useful references, but may create assumptions
- Every custom project still needs fresh discovery and validation
- Delivery discipline matters from requirements through go-live
- Success depends on how well the vendor understands the business
Every SME Develops Its Own Operating Logic
Two companies can operate in the same industry yet follow very different ways of working. One factory may require three levels of production approval, while another allows the production manager to decide directly. One distributor may confirm orders through WhatsApp, while another uses a formal sales order process. These differences develop naturally as the business grows and its customers, staff and management structure change.
There is also no single way to report the business. Management reporting needs differ based on what the owner wants to monitor, how departments share information, and who makes the final decisions. Staff responsibilities, handover points and approval rules can also differ significantly. These differences are normal as businesses grow, so a similar industry does not automatically mean a similar system requirement.
Similar Experience Helps but Can Create Wrong Assumptions
Previous projects give a vendor useful reference points, especially when the industry has familiar processes, terms and reporting patterns. The problem starts when that experience becomes a shortcut. A vendor may assume a process works the same way because it worked for another customer. Yet a small difference in approval, handover or exception handling can change the system requirement significantly. The vendor may also recommend what worked for the previous customer without first checking whether it fits the new one.
Industry familiarity is therefore useful, but it is only one form of experience. A similar project can help a vendor ask better questions, but it should never replace the need to ask the questions itself. The new customer still needs to be understood on its own terms.
Custom Projects Need Fresh Understanding Each Time
Every custom project starts with a different operating environment. Before proposing a solution, the vendor needs to understand the actual business rules behind daily work. Users should explain what they do, why they do it, and where the process changes from the normal case. Management expectations also need to be separated from assumptions made by staff who handle the work every day. Existing reports can provide useful evidence, but they should not simply be reproduced until the vendor understands what management actually needs from them. This is also why businesses should first stabilise and understand their workflows before choosing to build custom software.
Previous project knowledge should support questioning, not replace it. The new requirements still need both sides to check and agree on them before development begins. The goal is not to repeat what worked elsewhere, but to understand what works here.
Custom Software Requirement Gathering Starts Here
Good Custom Software Requirement Gathering starts with the right people in the room. The vendor needs input from those who make decisions, manage the workflow and perform the daily work. From there, the team can map the process from beginning to end, including normal cases and exceptions. The vendor should also clarify approvals, responsibilities and data ownership. These activities form part of requirements engineering and often explain why a simple-looking process needs more thought.
The discussion should then focus on what the system must achieve, rather than only what users ask to add. The initial scope should reflect business priorities. The team should resolve unclear rules before development starts, while the business can still change direction without creating unnecessary rework.
Good Delivery Depends on More Than Coding
Requirement understanding cannot stop once the initial discussion is completed. It must continue into solution design, where business users can check whether the proposed workflow reflects how work is actually done. This gives the team a chance to find misunderstandings before the system reaches the factory floor, sales team or operations department.
SIT checks whether connected functions behave as expected, while UAT checks whether the business can use them properly. Go-live preparation helps reduce avoidable disruption, but delivery does not end there. Post-launch support confirms that the system continues to work as expected. Successful custom software delivery depends on coordination across the full project lifecycle. Clear requirements also matter because unclear requirements can affect the direction of an entire project.
The Right Questions Matter More Than References
When comparing vendors, project references are useful, but Software Vendor Experience should not become the main basis for the decision. Ask how the vendor learns an unfamiliar business, who handles Custom Software Requirement Gathering, and how the vendor deals with changes or exceptions. Ask how business users take part in testing and what happens when the delivered workflow does not behave as expected.
Support after go-live deserves the same attention. These questions reveal the vendor’s working method, not just its marketing claims. A vendor with many similar projects may still take the wrong approach for a new customer. Another vendor with fewer matching references may still show stronger discipline in learning the business, validating requirements and supporting the system after go-live.
A Familiar Industry Does Not Remove Delivery Risk
Industry knowledge can shorten some early discussions, but it does not remove the risk of misunderstanding one company’s actual operation. An incorrect assumption about approvals, reporting or workflow can affect the system design, testing and daily operations after go-live. A vendor may know the industry well and still misunderstand how your company operates.
From management’s perspective, the bigger issue is choosing the right evaluation criteria. A less familiar vendor can still deliver successfully when it follows disciplined requirement discovery, validation, testing and support practices. Rejecting a suitable vendor only because of one missing industry reference can itself become a business risk. The better decision is to evaluate the entire delivery approach rather than rely on one credential. This is similar to why software development team size alone does not guarantee SME project success.
Judge the Vendor by How They Learn
A strong custom vendor should be willing to learn your business properly, ask good questions, and challenge unclear requirements without simply accepting them. Clarity before commitment reduces unnecessary risk, while a phased approach allows both sides to validate the direction before committing further. Experience should make a vendor better at learning, not less willing to learn.
Choose the Vendor That Understands Your Business
Software Vendor Experience should remain part of your vendor evaluation, but it should not become the deciding factor by itself. Look at how the vendor understands requirements, validates the workflow, handles testing and supports the system after go-live. Ask how the vendor approaches a completely new project and look for experience that can transfer across different businesses. Most importantly, start with your actual business workflow before deciding whether custom software is the right approach. A good vendor should also tell you when custom software is not the right approach.
Still unsure whether your workflow is suitable for a custom system? You do not need to prepare a full specification first. You can reach me through WhatsApp or Email to explain the situation informally. We can first discuss the workflow, clarify the real problem and see whether there is a sensible next step, without any obligation to proceed.
—
Ning
Founder, Zoomo Tech
