Most businesses that end up with software they cannot use did not hire incompetent engineers. They hired a vendor without agreeing what "done" meant, who owned the result, or who would answer the phone in six months.
This is the list we would want you to use on us.
Ask who owns the code#
The answer should be: you do. Specifically, the work should live in your repository, deploy to your cloud account, and hold your data.
If a vendor hosts your source code in an account you cannot access, you are renting your own business logic. When the relationship ends, you start again.
Ask directly:
- Whose GitHub, GitLab, or Bitbucket organisation holds the repository?
- Whose AWS, Azure, or Google Cloud account is billed?
- What happens to both if we stop working together?
Ask for the documents, not the demo#
Demos are designed to look good. Documents show whether anyone thought about the system.
Before signing, ask to see the artefacts a vendor produces on a typical project:
- A requirement document
- An architecture diagram and database schema
- An environment setup and deployment guide
- An admin user guide
If those do not exist as standard output, they will not appear at handover either.
Ask what the monthly running cost will be#
A quote that covers only the build is half a quote. Servers, databases, backups, monitoring, domains, third-party APIs and mail delivery all cost money every month, forever.
A partner who cannot tell you the monthly running cost before building has not sized the infrastructure. That is where surprise bills come from.
Ask who is accountable, by name#
"The team will handle it" is not accountability. Ask for the name of the engineer who will know your system, and what happens when that person is unavailable.
Ask what they would refuse to build#
This is the most useful question on the list. A partner who has never talked a client out of a project is either very lucky or not paying attention.
Sometimes the right answer is that an off-the-shelf product fits your process, and custom software would be an expensive way to arrive at the same place. Sometimes the answer is that the problem is not software at all.
Ask how they handle the thing going wrong#
Not if. Every system fails eventually. What matters is:
- Is there monitoring, and does an alert reach a person?
- Have backups ever actually been restored, or do they just exist?
- Is there a written recovery procedure someone unfamiliar could follow?
If you cannot answer "what happens if the database is lost at midnight", you do not have infrastructure. You have a server.
A note on how we work#
We built Ryha Technologies to be the company we would have wanted to hire, which is why the answers above are also our defaults: your repository, your cloud, documentation and training at handover, a named engineer, a quote that includes running cost, and an honest note when we think you should not build the thing at all.
If you want to put these questions to us directly, book a working session.