Before you hire a custom software company: 10 questions to ask
A checklist for comparing vendors: what to ask, what a good answer sounds like and which red flags should make you pause.
Custom software is something you’ll live with for years. These questions work with any vendor, including us. Bring them to every meeting and get the important answers in writing.
| Question | A good answer | Red flag |
|---|---|---|
| Who keeps the code, and who owns the data? | It’s in writing, and your data is yours to export | “Don’t worry, we’ll sort that out later” |
| Where is it hosted, and who pays? | A clear monthly cost for hosting and maintenance | Costs you can’t trace |
| How is each stage delivered and accepted? | Dated stages with acceptance criteria | One big delivery at the end |
| What support comes after launch? | A defined warranty, response times and support pricing | “Just call us if something breaks” |
| How is the data protected? | Individual logins, two-step verification and tested backups | One password shared by everyone |
| What documentation do I get? | A user guide plus technical documentation | “The code explains itself” |
| What if the vendor disappears? | A team behind it, documentation and exportable data | Only one person knows how it works |
| Is there a written proposal? | Scope, price and date for each stage | A single total price in a text message |
| What real projects have they built? | Live systems and clients you can talk to | Only mockups or screenshots |
| How are changes billed? | Quoted and approved in writing first | Charges you discover on the invoice |
1. Who keeps the code, and who owns the data?
This is the most important question, and the rules depend on the country. In the US, the U.S. Copyright Office explains that a commissioned work only counts as “made for hire” if it falls into one of nine categories listed in the law and both sides sign a written agreement saying so. Otherwise, the author is ordinarily the person who created it.
In Mexico, the Federal Copyright Law protects software as a literary work and says that, unless agreed otherwise, whoever commissions and pays for a work holds the economic rights. But the contract has to be clear and precise, any doubt is read in the author’s favor, and any transfer of rights must be in writing or it’s void.
There are two common models. You buy the code: you pay more upfront and then host, maintain and improve it yourself or with someone you hire. Or the vendor keeps the code and provides the system as a service: they host it, maintain it and keep improving it, and you pay to use it. Neither is automatically better; it depends on whether you have your own technical team.
Either way, get in writing which model applies, that your data is yours and that you can request a full export at any time, including if you leave. Have your lawyer review it.
2. Where will the system be hosted, and who pays for it?
An online system needs servers, a domain, a database, an email-sending service and sometimes pay-per-use services. Ask which ones you need, whose name the accounts will be in and roughly what you’ll pay each month.
If you buy the code, the healthiest setup is having the main accounts in your company’s name. If the vendor provides the system as a service, they normally run the infrastructure; in that case ask for a clear monthly cost and get in writing how you get your data back.
3. How is each stage delivered and accepted?
Ask for delivery in stages, each with a date and acceptance criteria: what your team must be able to do for the stage to count as done. Tying payments to accepted stages protects both sides.
Seeing the system working every few weeks is the best way to catch problems early. If you only see it at the end, that’s when you’ll find the mistakes too.
4. What support do you get after launch?
Every system needs adjustments once real people start using it, and security updates over time. Ask what the warranty covers and for how long, how you report a bug, how fast they respond and what support costs once the warranty ends.
5. Who will have access, and how is the data protected?
If the system stores customer or employee data, privacy law applies. In Mexico, for example, the federal personal data law requires your company to maintain administrative, technical and physical security measures, and requires everyone who handles that data to keep it confidential, even after the relationship ends. Ask specifically:
- Will each person have their own login and see only what they need?
- Can you turn on two-step verification? The U.S. Cybersecurity and Infrastructure Security Agency (CISA) says users who enable it are significantly less likely to get hacked.
- Are there automatic backups, and has anyone tested restoring them?
- Is there a record of who changed what, and when?
- Who at the vendor can see live data, and how is that access removed when the work ends?
6. What documentation will you receive?
At minimum, ask for a simple guide for your team, a list of the services and accounts the system uses, how a new version gets released and how the data is organized. Without that, the next developer starts blind, and that costs time and money.
7. What happens if the vendor disappears?
It happens. At SpacePort MX, the original developer disappeared, the site kept crashing and nobody could maintain it or make changes. Part of our work was recovering the logins and putting them back in the client’s hands.
To avoid depending on one person, ask who else knows your system, ask for documentation and make sure you can take your data with you. If you bought the code, also ask for it to live in a repository your company can access.
8. Will you get a written proposal priced by stage?
A serious proposal spells out what each stage includes and doesn’t include, what it costs, when it’s delivered and how it’s paid. If all you get is a single total in a text message, ask for the breakdown before deciding. It also makes comparing vendors much easier.
9. What real projects have they built, and who can you talk to?
Ask to see working systems, not just screenshots or mockups. If a project is public, try it yourself. If it’s confidential, ask whether they can walk you through it on a call or connect you with the client. Look for problems similar to yours.
10. How are changes billed?
There will always be changes, because using a system reveals things nobody saw on paper. Ask how changes are quoted, who approves them and how they affect the delivery date. What matters is that nothing gets billed without your written approval.
If you’d like to put these questions to someone, start with us. In a free consultation, we’ll review how your business runs, answer whatever you need and, if it makes sense, send you a written proposal with scope, price and dates for each stage. See how we approach custom software development.
Related
Frequently asked questions
It depends on scope: how many processes it covers, how many people use it and what it connects to. Ask for the price broken down by stage. At Nightly, we send it in writing after the free consultation.
Not necessarily. If you buy the code, yes, in writing: in Mexico any transfer of copyright has to be in writing, and in the US commissioned work only counts as made for hire with a signed written agreement. If the vendor keeps the code and provides the system as a service, what matters is that your data is yours, that you can export it and that the contract says what happens if you leave.
Gather everything you have: logins for the hosting, domain, database, code repository and connected services. With that, another team can review the system and propose how to keep it running.
Sources
- Works Made for Hire (Circular 30)U.S. Copyright Office
- Federal Copyright Law (Ley Federal del Derecho de Autor), in SpanishMexico’s Chamber of Deputies
- Federal Law on the Protection of Personal Data Held by Private Parties, in SpanishMexico’s Chamber of Deputies
- More than a PasswordCISA
Last updated:


