Choosing a software development company is one of the most consequential technology decisions a manufacturer can make. Get it right, and you gain a system that your operators trust, your managers rely on, and your business can grow with for years. Get it wrong, and you can lose months of time, a significant budget, and the goodwill of a shop floor team that will be much harder to convince the second time.
The difficult part is that almost every company sounds good in a sales meeting. Every proposal promises quality, on-time delivery, and “deep industry expertise.” Every demo looks polished. Every team says they are a partner, not just a vendor. The differences only become visible months later, when the project hits real-world complexity: an old machine that speaks an unusual protocol, a quality process that does not fit the template, an operator who finds the screen too slow to use with gloves on.
This guide is designed to help you see those differences before you sign. It walks through how to prepare, what to look for, and the 10 questions every manufacturer should ask a prospective software development company, including what a good answer sounds like and which red flags to watch for.
Whether you run a single plant or a multi-site operation, and whether you are building a custom MES, connecting your ERP to the shop floor, or digitizing quality and maintenance, these questions will help you choose with confidence.
Table of Contents
Why This Decision Matters More in Manufacturing
Software choices matter in every industry, but manufacturing raises the stakes for several reasons.
Software touches physical operations. In many industries, a software bug is an inconvenience. On a production line, a wrong instruction, a missing alert, or a delayed data update can lead to scrap, rework, a stopped line, a missed shipment, or even a safety issue.
Your environment is complex. Most plants combine machines of different ages and brands, legacy applications, spreadsheets, paper records, and an ERP that has been configured over many years. A software partner has to work within this reality rather than around it.
Your users are not office workers. Operators work under time pressure, often standing, often wearing gloves, often using shared terminals or tablets. Software that is clunky will simply not be used.
Adoption determines value. The best technology in the world delivers nothing if the floor does not use it. Choosing a partner who understands people and process is as important as choosing one who writes good code.
Switching later is costly. Once a system is embedded in your daily operations, replacing it, or even replacing the team that built it, is disruptive. It is far better to choose well at the start.
Before You Talk to Any Company: Do Your Homework
The quality of your selection process depends heavily on how well you define your own needs. Before you contact a single company, spend time on these preparation steps.
1. Define the problem, not just the solution
Many projects begin with a feature wish list: “We need an MES with dashboards and mobile apps.” A stronger starting point is a clear statement of the business problem:
- “Our unplanned downtime is not measured, so we cannot reduce it.”
- “We cannot trace a defect back to a specific batch or machine quickly.”
- “Our supervisors spend hours every day compiling reports.”
- “Our ERP does not reflect what is actually happening on the floor.”
When you describe problems, good companies respond with ideas. When you describe features, they simply quote.
2. Involve the right people early
Include representatives from operations, maintenance, quality, IT, planning, and, importantly, shop floor users. Their input will surface requirements that management might miss and will build buy-in for the project.
3. Document your current landscape
Create a simple overview of your environment:
- Your ERP and other major systems
- Machine types, brands, and control systems
- How data is currently captured and shared
- Network and IT constraints
- Compliance and customer audit requirements
This does not need to be perfect. Even a rough picture helps vendors give realistic proposals.
4. Set success criteria
Decide in advance how you will know the project worked. Examples include reducing unplanned downtime by a target percentage, cutting reporting time, improving first pass yield, or achieving faster traceability responses. Having clear targets keeps conversations focused on outcomes.
5. Clarify your budget range and timeline
You do not have to reveal your full budget, but you should know your boundaries. Be realistic about what is achievable and consider a phased approach if funds or time are limited.
With this groundwork done, you are ready to evaluate companies. Here are the ten questions that matter most.
Question 1: “What experience do you have in manufacturing, and can you show us relevant work?”
Why it matters
Manufacturing has its own language, processes, and constraints: work orders, routings, BOMs, batch genealogy, OEE, changeovers, shift patterns, inspection plans, and more. A team without this background will spend much of your project budget learning concepts you could have skipped explaining.
What a good answer sounds like
- Specific examples of manufacturing projects, including the industries, problems, and outcomes
- Familiarity with the vocabulary of your sector without prompting
- Case studies or references you can actually speak to
- Honest clarity about where their experience is strong and where it is limited
- Engineers who have been on a shop floor, not just in a meeting room
Follow-up questions to ask
- Have you worked with companies of our size and type?
- What was the most difficult manufacturing project you delivered, and why?
- Can we speak to a past manufacturing client?
Red flags
- Generic portfolios with no manufacturing examples
- Vague claims such as “we work with all industries” without depth
- Inability to explain basic concepts like OEE, MES, or traceability
- Reluctance to provide references
Question 2: “How do you approach discovery, and will you spend time on our shop floor?”
Why it matters
Discovery is where successful projects are won or lost. Requirements documents written in a conference room often miss the realities of the floor: unofficial workarounds, informal approvals, exceptions that happen every shift, and information that lives only in people’s heads.
What a good answer sounds like
- A structured discovery process that includes plant visits and conversations with operators, supervisors, maintenance, and quality
- A willingness to observe real workflows, not just collect documents
- Process mapping, prioritization workshops, and clear deliverables from the discovery phase
- Candid input about what should and should not be built, even if it reduces scope
- A discovery output you can keep, such as a roadmap or specification, whether or not you continue with them
Follow-up questions to ask
- Who from your team will visit our plant, and for how long?
- How do you capture requirements from operators and supervisors?
- What do we receive at the end of discovery?
Red flags
- A questionnaire and a single call replace real discovery
- A fixed price quoted before anyone understands your process
- Reluctance to visit the plant
- Proposals that look identical to those sent to other industries
Question 3: “Can you integrate with our ERP, machines, and existing systems?”
Why it matters
Most manufacturers already have an ERP and a mix of other tools. New software that cannot exchange data with them simply creates another silo and more manual work. On the machine side, connectivity can be especially challenging when equipment is old, proprietary, or from multiple vendors.
What a good answer sounds like
- Clear explanation of their integration approach, such as APIs, middleware, database-level integration, or file exchange
- Experience with common ERP platforms and the ability to work with yours
- Familiarity with industrial protocols, PLCs, gateways, and sensor retrofits
- A realistic discussion of legacy equipment and what can and cannot be done
- A plan for testing integrations early rather than at the end
Follow-up questions to ask
- How have you integrated with systems similar to ours?
- How would you connect our older machines?
- What happens to the integration if our ERP is upgraded?
- How do you handle data accuracy and synchronization?
Red flags
- “We can integrate with anything” with no specifics
- Integration treated as an afterthought or a later phase
- No experience with industrial equipment or protocols
- Plans that require replacing your ERP without a clear business reason
Question 4: “How do you design software for operators and shop floor conditions?”
Why it matters
Operators are the ones who generate most of your data. If the interface is slow, confusing, or demanding, they will take shortcuts, enter inaccurate data, or go back to paper. This single factor often determines whether a project delivers value or quietly fails.
What a good answer sounds like
- Involving operators in design reviews and testing, not just managers
- Interfaces built for touch screens, large buttons, minimal typing, and quick actions
- Support for local languages and simple, clear terminology
- Consideration of lighting, noise, gloves, shared devices, and unreliable connectivity
- Offline capability or graceful handling of network interruptions
- Pilot testing on the actual floor before full rollout
Follow-up questions to ask
- Can you show us examples of shop floor interfaces you have built?
- How many clicks does it take to log a downtime event?
- How do you gather and apply operator feedback?
- How do you handle training?
Red flags
- Interfaces that look like office dashboards, with small text and dense menus
- No process for user testing with real operators
- Assumption that training alone will solve usability problems
- Inability to discuss specific floor conditions
Question 5: “Who owns the source code, the data, and the intellectual property?”
Why it matters
This question is easy to overlook and painful to resolve later. If you pay for custom software but do not own it, or cannot access your own data, you may be locked into a relationship you cannot leave without major cost.
What a good answer sounds like
- Clear contractual terms about ownership of custom code and deliverables
- Transparency about any third-party libraries, licensed components, or reusable frameworks the company brings to the project, and how they are licensed
- Your data stays yours, with clear rules about access, export, and deletion
- Documentation and handover practices so another team could maintain the system if needed
- Reasonable arrangements for source code access, whether through direct ownership, escrow, or other agreements
Follow-up questions to ask
- Will we receive the full source code and documentation?
- Which parts of the solution are proprietary to you, and what rights do we have to them?
- How can we export our data, and in what format?
- What happens if we decide to move to another provider?
Red flags
- Evasive answers about ownership
- Contracts that retain all code rights without clear license terms for you
- Data stored in formats that cannot be exported
- Heavy dependence on undocumented, proprietary tools
Question 6: “How do you manage scope, changes, and timelines?”
Why it matters
No manufacturing software project goes exactly as planned. Requirements are refined, new needs emerge once users see early versions, and unexpected technical issues appear. What matters is how a company handles these changes, and whether the process is transparent.
What a good answer sounds like
- An iterative approach, such as short development cycles with regular demos, so you see progress and can adjust early
- A clear change management process explaining how new requests are assessed, estimated, and approved
- Realistic timelines that account for integration, testing, and floor pilots
- A named project manager and regular status updates
- Open discussion of risks, dependencies, and assumptions
Follow-up questions to ask
- How often will we see working software?
- What happens when we change our mind about a feature?
- How do you handle delays, and how do you communicate them?
- Who is our day-to-day point of contact?
Red flags
- A rigid plan with no allowance for learning or change
- Overly optimistic timelines to win the deal
- Long periods with no visible progress
- Vague scope definitions that lead to disputes later
Question 7: “How do you handle security, reliability, and data protection?”
Why it matters
Manufacturing systems often contain sensitive information: product designs, customer orders, pricing, process parameters, and quality records. They also sit close to operational technology, where cybersecurity incidents can disrupt production. Reliability matters as well, because software downtime can become production downtime.
What a good answer sounds like
- Secure development practices, role-based access control, and audit trails
- Encryption for data in transit and at rest where appropriate
- Careful network design that respects the boundary between IT and shop floor systems
- Backup, recovery, and monitoring strategies
- Realistic discussion of uptime expectations and what happens if connectivity or servers fail
- Awareness of your customers’ and industry’s compliance requirements
Follow-up questions to ask
- How do you manage user roles and permissions?
- What is your backup and disaster recovery approach?
- Can the system keep working if the network goes down?
- How do you test for security issues before release?
Red flags
- Security described only in general terms, or as “something we handle at the end”
- No clear plan for backup and recovery
- Shared logins or weak access control
- No consideration for how software behaves during outages
Question 8: “What does post-launch support look like?”
Why it matters
Go-live is not the finish line. Real-world use always reveals issues, improvement ideas, and new requirements. If a company disappears after delivery, or support is slow and impersonal, small problems can grow into major disruptions.
What a good answer sounds like
- Clearly defined support options, including response times and escalation paths
- On-site or close support during the first weeks of rollout
- A team that understands your system, not a rotating helpdesk
- Regular review sessions to discuss performance, feedback, and enhancements
- A plan for upgrades, maintenance, and continuous improvement
- Clear pricing for ongoing support, so there are no surprises
Follow-up questions to ask
- Who will support us after launch, and will it be the same team that built the system?
- What are your response times for critical issues?
- How do you handle urgent problems during production hours or night shifts?
- How are enhancements requested and prioritized?
Red flags
- Support treated as an afterthought
- No defined response commitments
- Knowledge concentrated in one person
- Unclear costs for fixes versus enhancements
Question 9: “How will we measure success?”
Why it matters
A company that talks only about deliverables, such as screens, modules, and features, may be optimizing for completing a project rather than improving your business. A true partner is interested in whether the software changes your results.
What a good answer sounds like
- Discussion of KPIs such as unplanned downtime, OEE, scrap rate, first pass yield, changeover time, reporting time, on-time delivery, and cost per unit
- Willingness to establish a baseline before the project starts
- Plans to track results after go-live and share them transparently
- Honest conversation about what the software can influence and what depends on process changes or organizational behavior
- Success criteria written into project plans and reviews
Follow-up questions to ask
- What results have your clients achieved, and how were they measured?
- How would you establish our baseline?
- What are the biggest factors that determine whether a project like this delivers value?
- Which metrics would you recommend for us?
Red flags
- Promises of dramatic results with no explanation or evidence
- No interest in measuring outcomes
- Success defined only as “delivered on time”
- Guarantees that ignore your own role in adoption and process improvement
Question 10: “Can we start small, and how does your pricing work?”
Why it matters
Large, all-at-once projects carry large risks. A company confident in its ability to deliver value should be willing to begin with a focused first phase, prove results, and then expand. Transparent pricing is equally important: unclear commercial terms are one of the most common sources of conflict in software projects.
What a good answer sounds like
- A phased roadmap that starts with the highest-impact area, such as one line, one process, or one plant
- Clear explanation of pricing models, such as fixed price, time and materials, or a hybrid, and when each makes sense
- Transparent estimates with stated assumptions
- Flexibility to adjust scope between phases based on what you learn
- Open discussion of total cost of ownership, including hosting, support, licenses, and future enhancements
Follow-up questions to ask
- What would a realistic first phase look like for us?
- What is included in the price, and what is not?
- How do you handle changes that affect cost?
- What ongoing costs should we expect after launch?
Red flags
- Pressure to commit to a large, long project immediately
- The lowest price by a wide margin, with little explanation
- Hidden costs revealed only after signing
- Resistance to phasing or pilots
A Simple Scorecard to Compare Companies
Once you have spoken with several companies, a structured comparison helps you decide objectively. Score each company from 1 to 5 on each criterion, then discuss the results with your team.
| Criterion | What to Look For | Company A | Company B | Company C |
|---|---|---|---|---|
| Manufacturing experience | Relevant projects, references, domain knowledge | |||
| Discovery approach | Plant visits, operator input, clear outputs | |||
| Integration capability | ERP, machines, legacy systems | |||
| Shop floor usability | Operator-first design, testing, offline support | |||
| Ownership and data | Clear code and data rights | |||
| Delivery process | Iterative, transparent, realistic timelines | |||
| Security and reliability | Access control, backups, resilience | |||
| Post-launch support | Response times, continuity, improvement | |||
| Outcome focus | KPIs, baselines, measurable goals | |||
| Commercial fit | Phased approach, transparent pricing |
You may wish to weight certain categories more heavily depending on your priorities. For example, a plant with many legacy machines may weight integration capability more strongly, while a regulated manufacturer may place extra weight on traceability and security.
Additional Ways to Evaluate a Company
Questions are essential, but they are not the only tool. These practices can add confidence to your decision.
Speak to references, and ask the right things
Ask for contacts at manufacturing clients and have a real conversation. Useful questions include:
- Did the project stay on track in terms of time and budget?
- How did the team handle problems and changes?
- How did operators respond to the software?
- What happened after go-live?
- Would you work with them again?
Run a paid discovery workshop or pilot
Rather than committing to a full project immediately, consider starting with a short, paid engagement: a discovery workshop, a prototype, or a small pilot on a single line. It lets you see how the team works, communicates, and solves problems before making a larger commitment.
Meet the actual team
Sales teams and delivery teams are not always the same people. Ask to meet the project manager, lead engineer, and designer who would work on your project. Their experience and communication style matter more than the brochure.
Review sample deliverables
Ask to see examples of documentation, project plans, wireframes, or status reports. These reveal how organized and transparent the company is.
Pay attention to how they treat your questions
During the selection process, notice whether the team listens, asks thoughtful questions, and gives honest answers, including “that may not be the best approach” or “we have not done that before, but here is how we would handle it.” Honesty at this stage is a strong predictor of honesty during the project.
Common Mistakes Manufacturers Make When Choosing a Software Company
Choosing on price alone. A low quote can become expensive through change requests, rework, poor adoption, and replacement costs. Compare total value, not just the initial number.
Being dazzled by demos. Demos are designed to impress. Ask how the solution would handle your specific scenarios, exceptions, and data.
Skipping the shop floor voice. If operators and supervisors are not consulted, the system may satisfy management on paper but fail in practice.
Underestimating integration. Connecting to machines and ERP is often the hardest part of a project. Make sure it is planned and budgeted properly.
Ignoring change management. Training, communication, and leadership support are crucial. A good partner will help you plan these, not leave them to chance.
Treating the project as a one-time event. Manufacturing evolves, and so should your software. Choose a company that can support long-term improvement.
Letting one person decide. A selection involving operations, IT, quality, finance, and floor users leads to better decisions and stronger ownership.
How Zenkins Answers These Questions
We encourage every manufacturer to ask these questions of every company they consider, including us. Here is how we approach them.
Manufacturing focus. We build software for manufacturing environments and design every solution with shop floor realities in mind.
Discovery first. We start by understanding your processes, people, and goals, including time on the floor, before proposing a solution.
Integration as a core capability. We connect software with ERP systems, machines, sensors, and existing tools so that data flows across your operation.
Operator-friendly design. We build simple, fast interfaces for real working conditions and involve users throughout design and testing.
Transparency and ownership. We believe you should have clarity on code, data, and documentation, and we agree these terms upfront.
Iterative delivery. You see working software regularly, with room to learn and adjust as the project progresses.
Support beyond go-live. We stay engaged after launch to support your team and help your solution evolve.
Outcome-driven mindset. We aim to tie our work to measurable results, such as less downtime, lower waste, faster reporting, and stronger traceability.
Phased approach. We are comfortable starting small, proving value, and expanding as your confidence grows.
Our goal is not to win a contract. It is to build a long-term relationship in which your plant runs better because of the software we create together.
Frequently Asked Questions
What should I look for in a software development company for manufacturing?
Look for proven manufacturing experience, a thorough discovery process, strong integration skills with ERP systems and machines, operator-friendly design, clear ownership terms, transparent project management, solid security practices, dependable post-launch support, and a focus on measurable business outcomes.
How do I know if a software company really understands manufacturing?
Ask them to explain concepts like OEE, work orders, batch traceability, and changeovers in the context of your plant. Request relevant case studies and references, and see whether they propose visiting your shop floor. A company that understands manufacturing will ask detailed questions about your process rather than jumping straight to features.
Should I choose a custom solution or an off-the-shelf product?
It depends on how unique your processes are, how complex your integrations are, and how much flexibility you need. Many manufacturers use a hybrid approach: proven products where they fit well, and custom components or integrations where their operations are distinctive. A trustworthy partner will give honest advice rather than pushing one option.
How much should custom manufacturing software cost?
Cost varies widely based on scope, number of integrations, number of users and sites, and level of customization. Rather than looking for a single number, ask for a phased estimate with clear assumptions, and compare the cost against the expected savings from reduced downtime, lower waste, and saved reporting time.
Is it better to choose a local company or a remote one?
What matters most is the team’s manufacturing expertise, communication quality, and willingness to engage with your plant. Many successful projects combine remote development with on-site discovery, pilots, and rollout support. Ask any company how they will handle plant visits and on-site assistance.
How long does it take to build custom manufacturing software?
Timelines depend on scope and complexity. With a phased, iterative approach, many manufacturers see a usable first release within a few months, followed by additional phases. Be cautious of both extremely fast promises and extremely long timelines with no intermediate releases.
What contract terms should I pay attention to?
Focus on ownership of code and data, scope and change processes, payment milestones, acceptance criteria, support terms, confidentiality, security obligations, and exit provisions. It is wise to have legal counsel review the agreement.
What if we are not sure what we need yet?
That is common. A paid discovery workshop is a good starting point. It helps clarify priorities, define a roadmap, and test whether the company is the right fit, without committing to a large project upfront.
Final Thoughts: Choose the Team, Not Just the Proposal
When you strip away the brochures, demos, and pricing tables, choosing a software development company for manufacturing comes down to a simple question: will this team understand my plant, build something my people will actually use, and stay with me as my business evolves?
The ten questions in this guide are designed to reveal the answer. Ask them openly. Listen carefully to how the team responds. Pay attention not only to what they say, but to how they listen, how honestly they discuss risks, and how curious they are about your operation.
The right partner will welcome these questions. They will give specific answers, admit what they do not know, and propose a practical first step. The wrong partner will give polished, generic responses and push you toward a quick signature.
Take your time, involve your team, and choose a partner who is as committed to your shop floor results as you are.
Ready to talk about your project? Bring your toughest questions to Zenkins. We will walk you through our approach, share how we would tackle your specific challenges, and help you define a practical first phase.
👉 Contact Zenkins today to schedule a discovery conversation.
