Before you sign
The questions to ask a software vendor before you sign
Use them — whether or not you ever hire us
These are the questions the Gomusoft team uses when we read a proposal for a client. The whole list is open, because if you ask them of anyone and get good answers, you don't need us.
This page isn't here to say which firms are good and which aren't — we don't comment on individual companies, and there are plenty doing careful work. What it does is put you and them on the same set of questions, before the money leaves your account.
How to use this
- Send them ahead; don't spring them in the room. Answering these properly takes preparation. Giving a vendor a few days isn't a trap — it's a chance to answer well, and a firm that works carefully will thank you for it, because it removes misunderstandings early.
- Ask for the answers in writing and attach them to the contract. An answer given in a meeting leaves with the meeting; an answer in writing becomes part of the deal.
- Don't judge on one answer; look at the pattern across all of them. Good answers share three traits: they're specific, they're checkable, and the vendor is willing to put them in the contract.
- A plain "We don't have that" beats a set of answers where nothing is missing. We have items we have to answer that way ourselves, and they're written out on their own page here. What Gomusoft does not have
- If they ask where the list came from, just tell them. It isn't rude. Questions about ownership, handover and restores are routine in large-company procurement; a smaller business is entitled to ask exactly the same things.
If you only get to ask ten, ask these
There are 21 questions on this page. If you only get one meeting, these are the ten whose answers change the decision most.
- What isn't included in this price?
- When is this done, and how is "done" measured?
- Who actually does the work, and how many clients are they carrying now?
- Whose name are the cloud account, the domain and the admin access in?
- Can we export our own data ourselves — today?
- If it goes down outside office hours, who do we call, and what's the longest we'd wait?
- When did you last actually restore from a backup?
- Who can reach our customer data right now, and may we see the list?
- If we end the contract, what do we get back, in what format, and in how many days?
- If we move to someone else, how long before they can take the work over?
Group 1 — Scope and price
Budgets rarely overrun because of the number on the quote. They overrun because of what nobody wrote down.
What's included in this price — and more importantly, what isn't?
Why it matters
Almost every quote itemises what's in it and says nothing about what's out. The usual omissions are migrating your existing data, connecting to your accounting system or whatever you already run, training your staff, and the annual fee after handover. Together those four are usually bigger than the price gap between the two bidders you're comparing.
A good answer sounds like
They answer both columns as a list, and are willing to put the "not included" column into the contract too. A good answer often contains a line like "We haven't priced that yet, because we haven't seen your existing data."
If the answer isn't complete, ask next
"Everything's included" with no list usually doesn't mean concealment — it usually means it hasn't been worked out yet. Ask: "Could you write out what 'everything' covers?" If they can, you're fine. If they can't, you've just saved yourself money.
When is this finished, and how do we measure that it's finished?
Why it matters
"Finished" for the vendor means the features in the document exist. "Finished" for you means the actual work now runs through the system. Those aren't the same day — and if you don't settle it up front, the acceptance test will be theirs, not yours.
A good answer sounds like
They propose criteria measured on your real work — "ten counter staff issue invoices through the system for a full week without going back to Excel" — and are willing to tie that to the final payment milestone.
If the answer isn't complete, ask next
"Complete per the specification" isn't wrong, it's just one-sided. Ask: "If every feature exists but the staff still aren't working through the system, is it finished?" The answer tells you most of what you need to know about the project ahead.
If we want to change something mid-way, what's the process, and how is it charged?
Why it matters
Change requests are where budgets swell and where relationships break — not because charging for extra work is wrong (it isn't), but because neither side ever agreed in advance what counts as "extra".
A good answer sounds like
There's a written process, an estimate in days or hours before work starts, your approval required every time, and they can give examples of what already sits inside scope versus what is genuinely new.
If the answer isn't complete, ask next
"Small things are on us" is usually meant kindly, but it means there's no line drawn. When something not-small arrives, you'll both be arguing without a rule. Ask: "Roughly where does a thing stop being small?"
Over the next three years, what will we pay for this system if we never ask for anything new?
Why it matters
The number you're comparing is year one. The real cost is licences, hosting, annual maintenance and renewals across several years. The cheaper bid today can be the dearer one by year two — and you'll find out when moving is no longer easy.
A good answer sounds like
A per-year breakdown, stating which items scale with users, data volume or branches, and what the annual price-adjustment terms are.
If the answer isn't complete, ask next
One number for today plus "We'll talk next year" isn't wrong, it's incomplete. Ask: "What do we pay in year two if nothing changes?" — and ask for that figure to appear on the quote.
Group 2 — Who actually does the work
The person who pitches and the person who writes your system are usually not the same. That isn't wrong — but you should know it before you sign, not in the third meeting.
Who actually does this work — their role and experience — and how many clients are they working for at the same time right now?
Why it matters
The two halves answer different things. The first tells you the level of craft you're buying; the second tells you the speed. A strong engineer carrying six clients gives you less than a good-enough one carrying two — and their schedule is your deadline.
A good answer sounds like
They can name who, in what role, with what comparable experience, how many engagements that person holds today — and they'll let you spend half an hour with them before you sign. The best answer we've heard was: "This person. Two engagements right now. Yours genuinely starts early next month."
If the answer isn't complete, ask next
"Our team handles it", with nothing more specific, isn't an answer yet. Ask for half an hour with whoever will do the work. If that's very hard to arrange, that's information too. And if the honest answer is that the person hasn't been hired yet — that's allowed; just get the start date in writing.
If the person doing this leaves mid-project, what happens to our work — and roughly how many weeks does it cost us?
Why it matters
People leave every company, so this doesn't measure whether it'll happen — it measures whether the firm runs on documentation or on one person's memory. If they can answer in weeks, they've been through it and planned for it.
A good answer sounds like
There's documentation a new person can pick up, a second person who has genuinely read this codebase, and they give you a number for the delay rather than telling you there wouldn't be one.
If the answer isn't complete, ask next
"No problem, we have backup" can be a fine answer if detail follows. Ask: "When did that backup person last open this project's code?" If the answer is never, your backup is a newcomer who still has to read everything.
Is any part of this work subcontracted to another person or company?
Why it matters
Subcontracting is normal and often the best option, but it has two consequences you need to know about: your data may sit with someone you never signed anything with, and when something breaks you're two steps from the person who can fix it instead of one.
A good answer sounds like
They say plainly which parts are subcontracted, to whom, whether the subcontractor sits under the same confidentiality terms, and that nobody reaches your real data without telling you first.
If the answer isn't complete, ask next
If the answer is "no, all in-house", good — ask for that in the contract, with a clause requiring notice before any subcontracting. It's an easy clause, and a firm that really does the work in-house won't hesitate to sign it.
Group 3 — The code, the data and the keys
This is the most important group on the page — not because anyone is out to take anything from you, but because these are the easiest questions to ask before signing and the hardest to raise afterwards.
Whose name are the cloud account, the domain and the administrator access in — and whose card is paying for them?
Why it matters
Whoever holds the account holds the switch. This isn't about trust; it's about whether you can still get into your own system if you can't reach them one day, for any reason. What we see most often isn't anyone holding anything hostage — it's convenience quietly turning into dependency: they opened the account at the start because it was faster, and nobody moved it back.
A good answer sounds like
They propose, unprompted, that the accounts are opened in your company's name from day one and that they join as an invited user. The best version: "The account is yours, the billing is yours, and you can revoke our access yourself at any time without going through us."
If the answer isn't complete, ask next
"We look after all of it, you don't need to touch anything" is genuinely convenient and usually well meant — but it means that the day you want to change something, you have to ask. Say: "Could the accounts be in our company's name with you invited in?" If yes, do it on day one; it's far easier than moving it later.
Is the source code written for us ours — and where does the contract say so?
Why it matters
Two very different words: own and licensed to use. If it's the latter, you can run the system but you can't change who maintains it — which can be a perfectly sensible deal if you're buying a packaged product that's cheaper for exactly that reason. You just need to know which one you're buying, and not find out when you want to move.
A good answer sounds like
They point to the clause on the spot, and separate what was written specifically for you from open-source libraries and shared components used across clients, with the licence terms for each.
If the answer isn't complete, ask next
"The code is our core platform, shared across clients" is a straight answer and common for packaged products — not a bad sign in itself. Ask two follow-ups: "Is the part built specifically for us ours?" and "If we stop using your platform, how does our data come out?" The second matters more than the first, every time.
Can we export our own data ourselves — today, not at the end of the contract?
Why it matters
It's the only question here you can test in ten minutes, and it's what separates owning your data from being told you own it. A promise about returning data that has never been exercised is a promise nobody has tested.
A good answer sounds like
There's an export in the product, or access to the database, in a standard format other tools can open — CSV, a normal database dump — and they suggest you try it once during the engagement.
If the answer isn't complete, ask next
If an export requires a request, a fee, or produces a file only their system can read, that isn't an export. Ask to do it once during testing. Doing it once while everyone is on good terms is far better than doing it for the first time on the way out.
Is our data used for anything else — aggregate statistics, product development, training an AI model?
Why it matters
Two reasons. First, your customer data carries legal duties, and those duties are yours. Second, purely commercially: your sales data describes how your business works, and you should know whether it's feeding someone's aggregate view of your market.
A good answer sounds like
They answer item by item, and will put the restriction in the contract. If the system calls an external AI service, they can say exactly what leaves, where it goes, and whether an option exists that sends nothing.
If the answer isn't complete, ask next
"To improve our service" can cover a great deal. Ask: "Does that include our customer records — and can we write an exclusion into the contract?"
Group 4 — The day it breaks
Every system has a bad day. These questions don't ask whether it will happen — they ask where in the queue you'll be when it does.
If it goes down at eight on a Saturday night, who do we contact, through what channel, and what is the longest we might wait for a reply?
Why it matters
The cost of downtime is yours, not theirs. "24/7 support" in marketing material covers everything from a staffed operations centre to one person who usually reads LINE. Both are legitimate; they shouldn't carry the same price or the same expectation.
A good answer sounds like
A channel with a real name and number, response times as numbers, split by severity — and they state their own limits before you ask: "Out of hours we take total-outage cases only, one-hour acknowledgement; everything else waits for the next working morning." A bounded answer like that is worth more than "always available".
If the answer isn't complete, ask next
"24/7" with no number and no channel isn't yet an agreement. Ask politely: "Can we put that in the contract?" If they can, it's real. If they can't, that's still fine — you've just aligned expectations today instead of on a Saturday night.
If it isn't fixed within the time we agreed, what happens next?
Why it matters
A service level with no consequence is a good intention, not an agreement. And it's not mainly about penalties — what you actually want is an escalation ladder: knowing when your problem reaches someone who can make decisions, instead of circling with the one person who is already overloaded.
A good answer sounds like
A ladder that names the next person up, a time box for each step, and some written consequence — a credit on that period's fee, or on-site attendance at no extra charge.
If the answer isn't complete, ask next
"It's never happened" may be entirely true, and still isn't the answer. Ask: "If ours is the first time, what have we agreed?" This is a much easier conversation now than during an outage.
How often is data backed up, where is it kept, and when did you last actually restore from it?
Why it matters
The last clause is the one that matters. A backup nobody has ever restored is a backup nobody has verified — and the usual failure isn't a missing file, it's a file that restores incompletely, or takes longer to restore than the business can wait. "When did you last?" tells you far more than "do you?".
A good answer sounds like
Frequency, location, how far back you can go, roughly how long a restore takes, and the date of the last restore test. The best version: they offer to run one restore as part of handover, with you watching.
If the answer isn't complete, ask next
"Daily backups" plus no date for the last restore test is very common, and usually means nobody ever asked rather than that anyone was careless. You can ask — make one successful restore a condition of acceptance.
Group 5 — Security and personal data
These pay twice. Once, because you find out how your customer data actually sits. And again on the day a major customer, a board member or a partner asks you the same questions — and you can answer yourself instead of forwarding them on.
Where is our data stored — which provider, and in which country?
Why it matters
If you can't answer this, you can't answer an enterprise customer or a foreign partner either — and some partner contracts already carry a data-location clause that nobody notices until an audit.
A good answer sounds like
The provider's name, the region, and which parts of the system send data abroad — email delivery, messaging, an AI service; those are the ones usually forgotten.
If the answer isn't complete, ask next
"On a secure cloud" doesn't answer it. Ask: "Which provider, which region?" Anyone genuinely operating the system answers in ten seconds, because they look at that screen daily.
Who can reach our customer data right now — may we see the list?
Why it matters
It measures two things at once: whether they know, and whether the system was set up so that knowing is possible. If the whole team shares one admin login, the answer can never exist — because the day something goes wrong, nobody can tell who did what.
A good answer sounds like
There's a list you can see: individual accounts, no shared logins, multi-factor authentication on, and a record of who was granted what, when, by whom, and when it was removed.
If the answer isn't complete, ask next
Shared admin logins are common in small teams and usually a product of haste at setup. Ask: "Can we move to individual accounts, and how long would that take?" It's usually a few hours' work, and a fair thing to require before go-live.
Where does PDPA touch this system — and in this arrangement, who is the data controller and who is the processor?
Why it matters
The thing many owners don't realise: most of the legal duty sits with you, as the controller of the personal data. Hiring a contractor doesn't move it. So this question isn't whether they'll carry the obligation for you — it's how well they help you carry yours.
A good answer sounds like
They say you are the controller and they process on your instructions, they'll sign a data-processing agreement on your template, and they can point to where personal data actually sits — including the places usually forgotten: system logs, attachments and backups.
If the answer isn't complete, ask next
"Our system is PDPA compliant" is a common line, but PDPA isn't something a system passes once — it's an ongoing duty of the organisation holding the data. Without making it a confrontation, ask: "Which part do you mean? Can we walk through where personal data is held?" What follows is usually far more useful than the opening line.
This page deliberately states no statutory notification deadline; counsel to confirm the wording before any figure is added. Draft
If there's a data breach, what's your process — and how quickly do you tell us?
Why it matters
The duty to notify is yours as controller, but the technical facts are theirs. If it takes them three days to tell you, three days of your own window are gone. So this is a question about clocks more than about blame.
A good answer sounds like
A written procedure: who gets told, within how many hours, notification even while facts are incomplete with a clear split between what is known and what isn't — and the technical detail you need for your own obligations.
If the answer isn't complete, ask next
If the answer is that they've never thought about it — that isn't unusual for a small team and isn't a reason to walk away. It's a reason to write the clause now. One sentence about notification hours is worth a great deal on the day it's needed.
Group 6 — The day it ends
Every commercial relationship ends eventually — sometimes badly, usually just because your business grew into needing something else. These questions are asked while nobody is upset, which is why now is the easiest time to ask them.
If we end this contract, what do we get back, in what format, and within how many days?
Why it matters
The answer is the real price of getting the decision wrong. If ending the contract means rebuilding from scratch, you aren't choosing a supplier — you're making a decision you can't reverse.
A good answer sounds like
They can give you the handover inventory on the spot: all the code with its history, the data in a standard importable format, architecture and deployment documentation, a credential register with owners, and the open-items list — with a timeframe, and happy for all of it to be a contract clause.
If the answer isn't complete, ask next
"Don't worry, we'll sort it out then" is usually said sincerely — but "then" is the moment you have the least leverage of the entire relationship. Ask: "Could we write it in now, so we don't have to discuss it then?"
If we move to someone else, how long before they can take over — and what documentation do they get?
Why it matters
The previous question asks whether you get your things back. This one asks whether what you get back is usable. Code with no documentation, no deployment procedure and no record of why it was designed that way takes a new engineer weeks before they dare change anything.
A good answer sounds like
Architecture documentation, deploy and rollback procedures, a credential register with owners, the reasoning behind significant technical decisions, and an open-items list. They give an estimate in weeks and will attend handover sessions with whoever takes over.
If the answer isn't complete, ask next
"Our code is readable, you won't need documentation" is usually said with justified pride, and is sometimes true. But documentation isn't there to explain what the code does — it's there to explain why it was done that way, which the code can't tell you. Ask for documentation as part of each milestone. Asking at the start is far easier than asking at the end.
If your company closes, or stops developing this product, what am we left with?
Why it matters
Most people hesitate to ask, because it feels like wishing misfortune on someone. It's the same question a bank asks you when you apply for credit, and it's standard in large-company procurement. You're about to place part of your operations inside another legal entity; asking how solid it is, is normal.
A good answer sounds like
A plain answer about what is already in your hands, plus options — code held by a neutral third party, or a named successor written into the contract. Anyone who has worked with larger organisations knows this question and usually has an answer ready.
If the answer isn't complete, ask next
If they take it badly, don't retreat — explain briefly that you ask because your business will depend on this system, not because you doubt them. The way we put it: "This isn't about doubting you. Our business will run on this, so we need to know we can keep going whatever happens on either side."
What to do once you have the answers
- Take the five to ten answers that matter most and attach them to the contract. You don't have to rewrite them in legal language — attaching the email they sent already carries weight.
- Read the pattern, not the score. A vendor who says "We don't have that, but we can arrange it, in this time, at this cost" is more reliable than one for whom nothing is missing.
- If the answers are good, go ahead. This list isn't here to stop you hiring anyone — it's here so that when you do, you know what you agreed to.
- If you read the answers and still can't tell which are good enough — that's where someone like us is most useful, and it's also the cheapest moment to ask, because nothing has been signed yet.
Want someone sitting on your side when they pitch?
The first conversation — getting to know each other and understanding what's stuck — is free. We don't charge for getting acquainted. Add us on LINE or talk to the team at the booth, and tell us in a line where you are: still choosing, holding a proposal, or already signed and sensing something isn't right.
The step that carries a fee is when we go and look at the real thing — read the full proposal and the contract, look at what you already run, talk to the people who have to use it — and give you a document: what we found, the risks in order, and what to do next. That document is yours and works with any contractor. Nothing obliges you to continue with us, and we quote the price before anything starts.
And if we read the proposal and think what you're about to sign is fine as it is, we'll tell you that.