Questions to ask before hiring for an integration

You've just realised your e-commerce platform needs to talk to your accounting software, but you're not sure how to vet someone who claims they can make it work. The conversation between you and a developer will either give you confidence or leave you confused—and the questions you ask now shape whether the job lands smoothly or becomes a costly mess.

Questions that reveal how they've actually done this before

Start with something direct: "Walk me through a similar integration you've built in the last year." This isn't small talk. A developer who has done this work will describe a specific system pair, the challenges they hit, and how they solved them. They'll mention API documentation they read, rate-limiting headaches they worked around, or authentication schemas they chose. Vague answers—"Oh, we've done lots of integrations"—suggest they haven't done *your* kind of integration.

Follow up with: "What happened when the integration broke after you finished it?" A good answer shows they've learned from real failure. They might say something like, "The third-party API changed their response format without warning, so I'd built in monitoring and alerting so the client spotted it within an hour." An evasive or blank answer—"It doesn't really break if you code it right"—is a warning sign. Integration work is fragile by nature, and a developer who doesn't acknowledge that hasn't shipped enough of it.

Ask: "Which APIs have you actually worked with?" If you need Shopify and Sage integration, they should be able to say yes to both or at least show they've integrated with similar systems and platforms. If they start naming random APIs or give a generic answer, they're either padding their CV or haven't done the specific work you need.

Questions that expose whether they'll maintain the integration

"What do you do after you hand over the code?" separates developers who walk away from those who build for durability. A solid answer includes monitoring, error logging, or a handoff document. They might say, "I set up basic logs so you can see when requests fail, and I document the settings you'll need if the third-party service changes." A weak answer—"That's your problem now"—means you'll be scrambling when something goes wrong.

Press on testing: "How will you test this before I use it?" You're looking for specifics: unit tests for individual functions, integration tests that actually call the other system (or use mock data if the live system isn't available), and a staging environment where you can try it before it touches real data. If they say they'll just "test it manually," you're hiring someone who hasn't thought through failure modes.

Ask: "What happens if the other system updates their API?" This matters because third-party changes break integrations constantly. A good answer shows they've thought about versioning, deprecation timelines, or monitoring for breaking changes. They might say, "I'll check their roadmap and set up alerts so we know early if something's changing." If they haven't considered it at all, you'll own the headache when it happens.

Finally, ask: "Will I be able to understand what's happening if something goes wrong?" A developer who cares about maintainability will give you a clear explanation of documentation, logging, and who you'd contact if there's trouble. Someone who wants to stay your permanent vendor might dodge this; someone confident in their work will lay it out.

These questions won't make you a technical expert, but they'll tell you whether you're hiring someone who treats integration as a one-time transaction or as a piece of infrastructure that needs to live and adapt. When you're ready to move forward, platforms like Strove let you compare developers' track records and read reviews from past clients who've already seen how these projects actually land.