Technical Questions to Ask When Implementing New Software
For the engineer or IT lead who has to make a newly bought system work. Twenty questions on architecture and tenancy, identity and permissions, the API and its limits, data migration, encryption, backups, release control, and who answers at two in the morning.
20 questions, each with the reason to ask it · includes a conversation guide
The questions
Open any question to see why it works.
- 1
Walk me through the architecture: what runs where?
Ask early, while you are still allowed to be naive. The answer tells you who the vendor puts in front of technical buyers. If the only person who can draw the diagram is a founder or a single solutions engineer, expect that same bottleneck during your rollout.
- 2
Is this single-tenant or shared, and what exactly is isolated between customers?
Shared infrastructure is normal, but the isolation boundary decides what a noisy neighbor can do to your performance and what a restore looks like. A vague answer often means row-level separation in a shared database, which you want to know before your security review finds it.
- 3
Which regions is our data stored in, and which regions is it processed in?
These are different answers more often than people expect. Storage may sit in your region while support access, log aggregation, or a subprocessor sits elsewhere. Ask for the subprocessor list in writing rather than the verbal summary.
- 4
How does authentication work, and do you support SSO and automated provisioning?
Single sign-on always gets asked about; automated deprovisioning does not, and that is the one that leaves live accounts behind after someone leaves. Confirm whether SCIM or an equivalent is supported, and whether it is gated behind a higher tier.
- 5
What is the permission model: roles, groups, or per-record rules?
Fixed roles are easy to administer and hard to fit a real organization into. Per-record rules fit anything and become unmaintainable. Ask them to model one awkward case from your org during the evaluation rather than after signature.
- 6
Is there a full API, and can it do everything the interface can?
Most products cover reads and easy writes, while configuration, permissions, and bulk operations stay interface-only. Those gaps decide whether you can automate onboarding or will be clicking through it by hand forever.
- 7
What are the rate limits, and are they per user, per token, or per tenant?
A per-tenant limit means your migration script and your production integration compete for the same budget. Ask what happens on breach: a 429 you can back off from is workable, an hour-long block is not.
- 8
How do you version the API, and how much notice do we get before a breaking change?
You are asking whether there is a deprecation policy in writing or only a changelog. Then ask when they last broke something and how customers found out. That answer predicts your unplanned work better than the policy does.
- 9
Do you support webhooks, and what happens to events while our endpoint is down?
Retry behavior is where integrations quietly lose data. Find out how long they retry, whether you can backfill missed events afterwards, and whether delivery is at-least-once, since that decides whether your handler has to be idempotent.
- 10
Is there a sandbox, and does it match production?
Sandboxes commonly lag on version, lack the integrations, or reset weekly. If it is not comparable, your testing is theater. Ask too whether sandbox seats cost extra, because that quietly caps how many people can practice safely.
- 11
How does our existing data get in, and who does that work?
There are three answers: a file import you run, an API load you build, or a migration service they run. The second is the one most often undersold in the sales cycle. Ask how many records per hour their import handles, and what happens to rows that fail validation.
- 12
What data model are we inheriting, and where will our fields not fit?
Every product has a shape it expects your business to have. The mismatch shows up as custom fields, and custom fields usually carry limits on count, type, searchability, and whether they appear in the API. Ask for those limits as numbers.
- 13
How do search and reporting behave at our record volume?
Performance demos run on tidy sample data. Give them your real counts and ask what changes at that size, then at ten times it. Reporting is usually the first thing to degrade and often the first thing your users complain about.
- 14
What audit logging do we get, and can we export it to our own tooling?
Ask specifically whether admin actions, permission changes, and data exports are logged, how long logs are retained, and whether retention is tied to your tier. Logs that cannot leave the product are of limited use during an incident.
- 15
How is data encrypted at rest and in transit, and who holds the keys?
Encryption at rest is close to universal and says little on its own. The useful follow-ups are who can decrypt, whether customer-managed keys exist, and what access their own support staff has to your production data and under whose approval.
- 16
How are backups taken, and have you ever restored one customer from them?
Platform-wide backups do not help when one team deletes a set of records. Ask about point-in-time restore for a single tenant, how long it takes, whether it is self-service, and whether they have actually done it for someone recently.
- 17
How do you ship changes, and can we stage or delay an update?
Continuous release to all customers means the interface can change during your training week. Ask whether there is a preview environment, a release calendar, and any ability to defer, and whether deferral exists on your plan.
- 18
What has to be opened on our network: agents, IP allowlists, outbound domains?
This is the item most likely to add weeks, because it belongs to a different team than the one buying. Get the list in writing early, including any static addresses you must allow and any software that has to be installed on endpoints.
- 19
What are the hard limits: file sizes, record counts, concurrent users, retention?
Every system has ceilings, and they usually live in support documentation rather than the contract. Ask which are configurable and which are architectural. Architectural ones will not move for you no matter what the account team says.
- 20
What is the escalation path during a production incident, and who answers at two in the morning?
Ask for mechanics: the number or channel, the severity definitions, who decides severity, and the response time at the top level. Ask also where the status page lives and how you would hear about an outage if nobody on your side was watching.
Working through the technical evaluation
Practical guidance for the conversation itself.
The order that saves time
The order that saves time
- 1Start with the answers that can disqualify: data residency, identity integration, network requirements, and any hard limit below your volume. There is no point evaluating a workflow you cannot legally or physically deploy.
- 2Get the security documentation and subprocessor list before the deep technical call, so the call is spent on what the documents do not cover.
- 3Ask for API documentation you can read without booking a sales call. Documentation quality is a fair proxy for how the integration will feel.
- 4Load a small amount of your own messy data into the sandbox rather than using their sample set. Most surprises live in the data, not in the product.
- 5Keep pricing in a separate conversation. Technical answers get shorter when a commercial negotiation is happening in the same meeting.
Who you are actually talking to
Who you are actually talking to
- Ask for a solutions engineer rather than an account executive, and ask them directly whether they have implemented this at your size before.
- Treat any answer of the form that it is on the roadmap as a no. Ask what exists today, and get anything you are depending on written into the contract.
- Request a reference customer who is technically similar to you and has been live for over a year. Freshly signed references have not hit the second-year problems yet.
- Write down every answer with the name of the person who gave it. Sales staff turn over, and someone told us it supported that carries no weight later.
- If the same question gets two different answers from two people, that is a real finding. Ask it a third time in writing.
Planning the exit while you are still buying
Planning the exit while you are still buying
Test the export before you depend on it
Ask for a full export during the trial and actually open it. The common failures are attachments that arrive as links you cannot resolve, history and audit records that are excluded, and custom fields that come out as internal identifiers with no mapping.
Know the shutdown clock
Find out how long your data stays available after cancellation, and whether the account goes read-only or dark on day one. Thirty days sounds generous until it lands in the middle of a migration.
Keep the integration seam thin
Where you can, put your own layer between the vendor's API and your systems. It costs a little at build time and it is the difference between swapping a supplier and rewriting everything that touched them.