Test how they think
A strong development company does not start with technology. It asks about outcomes, users, the current process, and the cost of the problem. A price and deadline promised without those questions usually move uncertainty into later change requests.
References help, but pay more attention to whether the team explains decisions, names risks, and can reject a feature that adds no value.
The 12 questions
Have the answers reflected in the proposal or contract. This is not a terminology exam; you are looking for an understandable operating model.
- What outcome defines success?
- What is inside and outside the base scope?
- Who is accountable for the project?
- How often will we see working software?
- How are changes and their cost approved?
- What inputs and decisions do you expect from us?
- How do you test and who accepts delivery?
- Who owns the source code and when do rights transfer?
- How are security, backups, and access handled?
- What happens during the first 30 days after launch?
- Which licences and monthly costs will arise?
- How can we end the engagement and take over the project?
Compare like with like
A €15,000 proposal and a €30,000 proposal may not describe the same product. One may include UX, testing, migration, deployment, and stabilization; the other only coding from supplied screens.
Build a shared matrix of deliverables, assumptions, and exclusions before comparing price, schedule, and risk.
Warning signs
Watch for unlimited promises, unclear code ownership, no change process, pricing without assumptions, and dependency on one individual. A partner unable to show working progress is equally risky.
A healthy engagement has decision points, open communication, and an exit path with usable handover—not a hostage project.
Validate the relationship before a large commitment
When uncertainty is high, begin with paid discovery or a small technical stage with a concrete output. You can observe communication, decision-making, and documentation without commissioning the entire product.
The stage must leave a usable result: a process map, prioritized scope, risk test, or prototype. A workshop with no decisions is not evidence of delivery capability.
- identify the accountable people
- agree a demo cadence
- define the trial-stage output
- verify handover and access practices