When a company wants custom software, it is easy to compare technologies, day rates and reference lists. Those details matter, but they do not answer the main question: can the development company turn a real business problem into a product that people understand and that can be operated reliably?
After more than ten years in software projects, we see the same risks repeatedly. Requirements are treated as complete too early. A prototype looks polished but ignores data migration and operations. A project starts with a long feature list even though nobody has described the most important workflow.
These ten questions help evaluate a software partner by how they work, not only by how they present themselves.
1. Which problem should become measurably smaller?
"We need an app" is not yet a project goal. A useful goal describes a change:
- employees no longer copy data between three systems,
- customers can complete a process without support,
- a monthly close requires fewer manual checks,
- errors are detected earlier and linked to a specific transaction.
A good development company asks about this change before discussing frameworks. It creates a boundary for the first release and keeps scope connected to value.
2. Who makes product decisions?
Projects stall when many people provide feedback but nobody can set a binding priority. Before work starts, clarify who owns the product, who answers domain questions, who accepts results and which users will be involved early.
These roles do not need to be full time. They do need to be available and able to decide.
3. Which real workflow will be built first?
A useful start does not implement every setting, role and exception at once. It builds one small but complete workflow. A user signs in, creates a transaction, processes it and sees the result.
This vertical slice reveals whether user experience, data model, permissions and integrations work together. A collection of isolated screens cannot provide the same evidence.
4. What evidence exists beyond a technology list?
"React, Java, cloud and AI" says little about the ability to ship and operate a product. Better questions are:
- Which products are live today?
- Which integrations have been operated over time?
- How were failures, migrations and updates handled?
- Which decisions were deliberately not automated?
Our products and projects describe role, challenge, implementation and operations. In InvoiceSync, professional review is part of the automation. With BodySeasons and horizOn, product development and live operations remain connected.
5. What happens after the first release?
A release is not the end. It creates logs, support questions, security updates, usage data and new requirements. Ask who monitors the application, how failures become visible, how backups are restored and how changes can be rolled back.
When these questions appear only after launch, operations become unnecessarily expensive. Our software development service treats deployment, monitoring and improvement as part of the product.
6. How will existing systems be integrated?
Many custom software projects are integration projects. The new application has to work with accounting, CRM, identity providers, existing data or legacy systems.
A robust plan clarifies data ownership, retries and responsibility. What happens when a target system is unavailable? Can a transaction be repeated safely? Which system owns the authoritative record? These questions matter more than one programming language.
7. How transparent are cost and priorities?
A serious proposal cannot remove every uncertainty, but it can make uncertainty visible. Look for a bounded first scope, explicit assumptions, regular usable increments and a clear process for new requests.
Transparency is not the longest possible project plan. It is the ability to explain what is done, what comes next and which decision changes the budget.
8. Who owns code, data and access?
Clarify where source code lives, who controls administrative accounts, how data can be exported, which services create recurring cost and what a handover includes.
A project should remain understandable when another person works on it. Documentation, reproducible deployments and clear ownership reduce dependency.
9. How are security and privacy handled in practice?
"GDPR compliant" as a single bullet point is not enough. The real questions are which data is processed, who can access it and how long it is needed.
For sensitive products, data minimization, permissions, auditability and understandable user information belong in the product model. Our field report on sensitive tracking data in BodySeasons explains why these decisions cannot wait for the privacy policy.
10. What should be visible after the first 30 days?
A good start produces more than workshops and documents. After one month there should be a verifiable core: a tested workflow, a prioritized backlog, an agreed data model or a technical risk assessment.
The exact result depends on the project. Both sides should know in advance how progress will be recognized.
A good software partner makes decisions visible
The best collaboration does not come from confirming every idea immediately. It comes from placing business goals, technical consequences and operational effort next to each other in plain language.
If you are planning custom software, a SaaS product or an integration, we can use an initial conversation to sort the main workflow, existing systems and the largest risks. Tell us about the current problem. You do not need a finished feature specification.
