How to Hire a Developer for a Shopify Integration (and What to Ask Before You Sign)
I have been freelancing since late 2011, first on oDesk and then on Upwork, and I have also been on the hiring side of plenty of conversations where a store owner is trying to work out who to trust with a connection between Shopify and something else. I wrote about my own experience on the platform in Is UpWork Worth It in 2025. This article is the other side of that story: what I would want to know if I were the one paying.
Integration work is different from building a storefront. When a theme looks wrong, you see it immediately. When an integration is wrong, orders can fail for weeks before anyone notices. So the way you hire matters more than the hourly rate.
Start with a brief a stranger can understand
Most bad projects start with a vague request such as “connect Shopify to our warehouse.” A developer reading that has to guess, and different developers guess differently, so you get quotes that cannot be compared.
Write a short brief that answers these questions:
- What systems are involved? Name them, with the plan or version if you know it.
- Which way does the data move? Orders from Shopify to the warehouse, tracking back, stock levels in both directions?
- What data exactly? Custom fields, discounts, gift messages, bundles, multiple locations.
- How much volume? Orders per day today, and on your busiest day.
- What goes wrong now? Describe two or three real examples with order numbers. Concrete failures are worth ten paragraphs of theory.
- What does success look like? For example, “no order sits unprocessed for more than ten minutes” or “packing slips show each engraving beside the right item.”
- Who will own it afterward? You, an agency, or an in house developer?
That page alone will improve the quality of every reply you get.
Questions that reveal real experience
Anyone can say they know the Shopify API. These questions tell you who has actually been through the hard parts:
“What happens if the same webhook arrives twice?” A good answer mentions recording event IDs, safe repeats, and not creating duplicates. A blank look is a warning. I explain what I mean in Shopify Webhooks Missing Orders.
“What happens if your system is down for an hour?” You want to hear about retries, a catch up job, and alerts. You do not want to hear that it will not happen.
“How will I know when something fails?” The honest answer includes alerts to a person, not just logs nobody reads.
“How do you handle API rate limits?” Look for queues and backoff. I cover why in Shopify API Rate Limits During Black Friday.
“What will you need from us?” A thoughtful developer asks for access, sample data and a person to answer questions. Someone who needs nothing has probably not thought it through.
“Tell me about an integration you built that went wrong.” Everyone with experience has one. How they describe it, including what they changed afterward, says a lot.
Ask to see examples of similar work, even if the details are hidden. A written case study or a short walkthrough of a past project, with the client’s name removed, is usually enough.
Red flags
Be careful when you see any of these:
- A firm price offered after one short message, with no questions about your setup.
- A promise that the integration will “never fail”. Software fails. The question is how it fails and who finds out.
- No mention of testing, staging, or how changes get released.
- Reluctance to give you access to the code and the accounts it runs in.
- A heavy reliance on a pile of third party apps for something that needs custom logic, without explaining the trade.
- Pressure to skip documentation to save money.
Also be wary in the opposite direction. A developer who insists on building a large custom system for a problem a settings change or a modest app could solve is not looking after your interests. A good developer will sometimes tell you that you do not need to hire them.
Choosing how to pay
There are three common arrangements, and each fits different situations.
Fixed price works when the scope is clear and small enough to describe in writing. It protects you from surprises on cost, but it can create tension when requirements change midway. Agree how changes are handled before you start.
Hourly or by the day works when the problem is murky and the first task is investigation. You stay flexible, but set a cap or a check in point so the bill cannot run away.
A small paid first step is my favorite for anything uncertain. Pay for a short discovery or a prototype, such as a few hours reading your setup and writing a plan, before committing to the full build. You learn how the developer works, and they learn whether the job is what it seemed.
For anything that has to keep running, add a modest ongoing arrangement. APIs change, and someone needs to be responsible when they do. I describe an example of this in the AWS case study, where a light monthly retainer made the cost savings sustainable.
Protect yourself on ownership
Before work starts, agree on a few basics in writing:
- The code lives in a repository you own or control, not only on the developer’s computer.
- Hosting accounts are in your name, with the developer added as a user. If they disappear, you still have the keys.
- Credentials and API keys are stored properly and documented, and you know how to rotate them.
- Documentation is part of the deliverable: what the system does, where it runs, how to deploy it, and what to do when it breaks.
- Someone other than the developer can reach the system, even if only to turn it off.
These cost nothing to ask for at the start and are painful to demand at the end.
Watch how they communicate
Early behavior predicts the whole project. Do they ask clear questions? Do they explain trade offs in words you understand? Do they tell you about problems early, even when the news is awkward? I work asynchronously by default, with regular detailed written updates, because it leaves a trail you can refer back to. Whatever style you prefer, make sure it is agreed before the first invoice.
Plan for testing and launch
Insist on a test phase. A responsible build runs against a development store or a copy of your data first, then goes live in a controlled way, perhaps for a slice of orders or during a quiet period. Ask what will be checked after launch and who will watch the first few days.
Avoid launching a new integration right before your busiest season. If your calendar has a big sale coming, either finish the work well ahead of it or wait until afterward.
A last piece of advice
The cheapest developer is rarely the cheapest outcome. An integration that quietly loses two percent of orders will cost far more than the difference between two quotes. Spend your effort on clarity at the start, a developer who asks good questions, and a system you can see into.
If you have a project in mind and want a sanity check on your brief or a quote you received, email kevin@kevinhq.com. I am happy to tell you what I would ask, even if you end up hiring someone else.