10 questions to ask any software or AI partner before realigning your operating processes
Select a software development partner: A guide for managing directors of operating SMEs with a turnover of EUR 10 to 50 million
Table of Contents
Selecting a software development partner: This is one of the most consequential decisions business managers of an operating SME will make. The system you hire will control your quoting, scheduling, inventory and customer commitments. When it goes wrong, it doesn't go wrong quietly. It goes wrong at peak operation, with real customers waiting.
And yet, for most companies, the partner selection process is under-designed for the jobs. Proposals are evaluated on price, portfolio screens and how convincing the sales team is. The questions asked are generic: What is your process? What technology stack do you use? Can you meet our timeline?
These are not the wrong questions. They are just not enough. The right questions for an operational realignment are different, not just more profound. They're designed to make visible what a non-technical business leader can't infer from a proposal alone: whether the partner thinks in terms of operational outcomes or feature delivery, whether they've built systems that will stand up over time, and whether they're telling you things you don't want to hear before they get expensive.
The ten questions below are designed for exactly this context: an SME business leader who is about to commit to a partner for a system that will run their business for three or more years, possibly with AI.
Why the stakes are higher for operational software than for product software
Most partner selection guides are aimed at startup founders developing a product. Operational software for an SME works differently. Your quoting system, scheduling platform or inventory management tool runs your business in real time. A system failure at peak operation is not a learning experience. It's an operational disruption with real commercial consequences.
This means that the questions you ask a potential partner need to go beyond competence and process. You need to test judgment, operational experience, accountability for results and honesty about what typically goes wrong.
Before the questions: Clarify two things in advance
Before a formal assessment begins, clarify two things with yourself and each partner.
First: The measure of success of this project is an operational improvement, not a delivered system. The system is the means. The improved operation is the goal. If you can't articulate what operational outcome you are buying before the first conversation with a potential partner, you can't evaluate their answers to any of the following questions.
Secondly: The minimum standard of a first meeting is not a demo or a pitch. It's a discussion about your business. Any partner worth working with should ask about your processes, your current framework and where time and margin are being lost before saying anything about how they would build the solution. If the first meeting is mainly about them, that's information.
The 10 questions
1. what do you do before you write the first line of code? | |
What to look out for: | A structured analysis phase: process mapping, stakeholder interviews, acceptance tests. The output should be a process design or an operational basis, not a specification sheet created by the client. |
Warning signal: | They go straight to schedules and technology stack after a single conversation. A fixed price quoted after a brief description means that the partner optimizes the offer, not your problem. |
2. how do you define success and how do we recognize it? | |
What to look out for: | A concrete operational key figure: offer throughput time, scheduling efficiency, error rate, margin per order. Success should be defined before construction, not evaluated after delivery. |
Warning signal: | Success is defined as delivering the agreed features on time and within budget. This is a delivery metric, not an operational one. It means that the partner is not responsible for whether the system actually improves your business. |
3. can you show us a system that you have built that is still running reliably three or more years later? | |
What to look out for: | Specific customers, operational constraints and what made the system maintainable over time. You should be able to describe the architectural decisions that gave it longevity and what the maintenance relationship looked like after go-live. |
Warning signal: | A portfolio of current projects with no mention of what happened afterwards. Getting a system up and running is not the same as keeping it running after three years. Partners without proven long-lasting systems may not be building for longevity. |
4. what happens if the developer who built our system leaves your team? | |
What to look out for: | Documented transfer standards, structured knowledge transfer, redundancy in the team. The answer should show that system knowledge does not lie in the head of a single person. |
Warning signal: | "That rarely happens here" or "We have a good team culture." Both answers evade the question. Every team experiences turnover. A partner without a structured answer builds a key person risk into your infrastructure. |
5. when have you advised a customer not to build something they wanted? | |
What to look out for: | A specific example where they have disagreed with a feature, scope or approach because it would not have improved the bottom line. This tests whether they are acting as an executor or a true partner with their own judgment. |
Warning signal: | No concrete example, or every example ends with the customer "later agreed." Partners who always say yes build what the customer wants, not what the customer needs. For operational software, that's an expensive difference. |
6. what role does AI play in your approach and what needs to be in place in our business for it to actually work? | |
What to look out for: | A clear explanation of the prerequisites for AI: structured data, consistent processes, system-side access. You should be able to explain what differentiates operational AI from AI functions that are put on top of a SaaS tool and why the process layer needs to be in place before AI integration. |
Warning signal: | "We use AI in everything we build." That's a marketing statement, not an answer. AI without structured operational data delivers unreliable results. A partner who cannot describe the requirements for AI has probably never used it successfully in an operational context. |
7. how do you ensure that the system can be maintained by someone who did not build it? | |
What to look out for: | A defined documentation standard, recommendations for the change process and a maintenance cost estimate at handover. The test: After delivery, a new developer or operations manager should be able to maintain and develop the system without the original team. |
Warning signal: | "We document on an ongoing basis" or "We are happy to provide support." The former is not standard. The latter means that the need for support secures your follow-up order, not a system feature. They want documentation that makes the system independent, not permanently dependent. |
8. what does the maintenance relationship look like after go-live and what does it cost? | |
What to look out for: | A clear answer: either a defined support maintainer with scope and costs, or a transfer standard that enables you to maintain the system independently. A reasonable guide value is 15 to 20 percent of the original construction costs per year. |
Warning signal: | Unclear assurances of "availability" without defined scope or costs. As a result, you only discover the maintenance dependency after the go-live, when your negotiating position is at its weakest. |
9. who specifically will be working on our project and can we get to know them before signing? | |
What to look out for: | Named individuals, their level of experience, and confirmation that the people presenting the proposal are also involved in its implementation. Senior partners often win contracts and hand them over to junior teams. |
Warning signal: | "We assign the right team according to project requirements." That's not an answer. You are buying the judgment, experience and domain knowledge of specific people. A company that can't tell you who is working on your project is telling you something important about how they work. |
10. what is the biggest mistake your customers make when commissioning such a project? | |
What to look out for: | A concrete, honest answer that reflects real experience. Good partners have seen error patterns: Specifications written before the process was understood, budget set before the problem was delineated, AI tracked before the data structure was ready. |
Warning signal: | A standard diplomatic answer about "communication" or "clear requirements." These are real problems, but also safe answers. A partner with real operational experience can be more precise. If you can't say what typically goes wrong, you may not have experienced enough projects that went right. |
How to use the questions effectively
Do not treat them as an interview checklist to be ticked off one after the other. Use them as probes in the conversation. The most revealing answers often come when a question is asked informally rather than formally.
Three principles for effective use.
Pay attention to specificity. Generic answers to specific questions are a red flag. A partner who says they have a "structured discovery process" is saying less than someone who describes exactly what is covered, how long it takes and what the outcome looks like.
Ask for examples, not guidelines. "What is your handover standard?" is a weaker question than "Can you describe the handover documentation of a project you delivered two years ago and whether the customer was able to maintain it independently afterwards?" The second variant is much more difficult to answer if the experience is not available.
Pay attention to what the partner mentions without prompting. Partners with real operational experience will mention risks, trade-offs and common error patterns without being asked. A partner who only answers what is asked is likely to tell you what you want to hear.
How appleute answers these questions
appleute is an operational optimization partner for B2B service providers in the DACH region whose operational processes have outgrown their current infrastructure. Each engagement is based on the answers to the questions above.
Before a line of code is written, we conduct a Strategic Audit: a fixed-price, two- to three-week deep dive into the process where friction and costs are most concentrated. The output is a process design and roadmap to cost neutrality, with a defined success metric, a maintenance cost estimate and a documented transfer standard from the beginning. If at the end of the audit we determine that the business case is not viable, we say so before a construction commitment is made.
Question 5 (when did you advise a customer not to buy): We keep a list. Scope that adds complexity without operational value. AI that is pursued before the data structure is ready. A new build that is commissioned even though the existing system could be stabilized. These conversations happen before the build, not after.
Regarding question 9 (who will work on the project): Each engagement combines a named senior business architect with a named lead developer. The people in the initial interview are the people doing the work.
What to do now
If you are currently evaluating partners for an operational realignment, take the ten questions above into the next conversation. Pay attention to which partners answer with specificity and which answer with reassurance. Which ones mention risks without being asked, and which ones only describe what will go well.
The partner worth working with will give you answers that will strengthen, not weaken, your confidence in the complexity of the project. Real operational experience does not hide difficulties. It explains what makes it manageable.
If you would like an external assessment of your current operational situation before deciding on a partner, we offer a short discovery meeting. We capture the process where friction and costs are concentrated and give you a clear assessment of what a well-defined project should look like. No obligation. A concrete assessment of your situation.
If you want this perspective: We are ready.
Arrange a free, no-obligation consultation with our team.
EN 
DE 
FR 
ES