At some point most small stores need work that an app or a theme setting cannot do: a custom section, a fix for a layout that breaks on mobile, a cleanup after years of installed and removed apps. Hiring a freelance developer for that work can save weeks of frustration, or it can create a new problem if the brief is vague, access is too wide and nobody tests before the change goes live.
This guide covers how to decide what you need, write a brief, choose someone, give them safe access, test their work and get a handover you can use later. It uses Shopify terms because that is where most small stores sit, but the same approach works on other platforms.
Key takeaways
- A clear brief saves money. Most disputes come from scope that was never written down.
- Use the platform’s collaborator or staff access, not your own login. Never share your password.
- Ask for a quote broken into parts, with a fixed price or a capped estimate for each.
- Test on your phone and computer before anything is published, using a short written test list.
- Get a handover: what changed, where it lives, how to undo it and how to edit it yourself.
Decide whether you need a developer
Before paying for custom work, check the cheaper routes. Our guide to choosing between an app, a theme setting or custom code walks through that decision in detail. In short:
| Option | Good for | Watch out for |
|---|---|---|
| Theme setting | Layout, colors, sections your theme already supports | Limits of the theme; settings can change with theme updates |
| App | Features that need ongoing processing, data or external services | Monthly cost, permissions, speed, leftover code after removal |
| Custom code | Small, specific changes that no setting covers; removing clutter | Someone has to maintain it when the theme or platform changes |
A developer is often the right choice for small, well-defined theme changes, for cleaning up after apps (see removing leftover app code), for speed work and for connecting systems that do not talk to each other out of the box. For a full redesign or a custom app, the same steps apply, but the brief and the testing need to be much more detailed.
Write a brief
A good brief does not need technical language. It needs to say what is wrong, what “done” looks like and what must not break.
| Section | What to include | Example (hypothetical) |
|---|---|---|
| Background | Your store, platform, theme name and version | “Clothing store, Shopify, theme updated last spring” |
| Problem | What happens now, with screenshots or a screen recording | “Size chart button overlaps the price on phones” |
| Goal | What should happen instead | “Button sits below the price on all screen sizes” |
| Scope | Pages, templates and devices affected | “Product pages only; phones and desktop” |
| Out of scope | What you are not asking for | “No changes to cart or checkout” |
| Constraints | Apps that must keep working, deadlines, busy periods | “Finished before our autumn sale; reviews app must still show” |
| Acceptance | How you will check it is done | “Tested on our own phones and two desktop browsers” |
Add links to the exact pages and products involved. If you have a related problem you might fix later, mention it as “not now” so the developer can avoid making it harder.
Find and choose someone
Where you find developers matters less than how you check them. Platform partner directories, freelance marketplaces and recommendations from other store owners all produce good and bad candidates.
What to look at:
- Relevant past work. Ask for examples of changes similar to yours, on the same platform. A beautiful portfolio of full redesigns tells you little about whether they can fix a product template carefully.
- How they respond to the brief. Good candidates ask questions: which theme version, which apps, whether there is a staging copy. A quote with no questions is a warning sign for anything beyond a tiny fix.
- How they plan to test. Ask directly: “How will you test this, and how do I approve it?”
- Availability after delivery. Ask how they handle a problem found a week later, and whether that is included.
- Communication. Agree one channel and a rough response time. Long silences during a project are a common source of stress.
For larger projects, a small paid trial task is a reasonable way to see how someone works before committing to the full job.
Agree scope, price and terms
Get the agreement in writing, even if it is a short email both sides confirm.
- Deliverables: the list of changes, matching your brief.
- Price model: fixed price per task, or an hourly rate with a cap that cannot be exceeded without your written approval.
- Payment schedule: for larger jobs, a deposit and payments tied to milestones you can check, rather than everything up front.
- Revisions: how many rounds of changes are included.
- Timeline: start date, delivery date and when you will review.
- Ownership: that you own the code written for your store once paid. Some developers reuse their own generic components; that is fine, as long as you have the right to use and change what is in your theme.
- Confidentiality: customer data and business information stay private.
- Support period: how long bugs caused by the work will be fixed without extra charge.
This guide is not legal advice. For large projects, a written contract reviewed by someone qualified is worth the time.
Give safe access
Use collaborator or staff accounts
Shopify lets partners and developers request collaborator access to a store, and the store owner approves the request and chooses which areas they can reach. You can also require a collaborator request code so that only people you give the code to can ask for access. Other platforms have similar staff or developer roles. In every case:
- Never share your own login or password. You lose the ability to see who did what, and you cannot remove access without changing your own credentials.
- Grant only the areas the work needs. A theme fix needs themes and probably products for testing. It rarely needs customers, orders, payments or financial settings.
- Check what an app developer asks for if the work involves a custom app; our guide to app permissions explains what common access scopes mean.
- Do not give access to payment, banking or domain accounts. If DNS changes are needed, make them yourself with written instructions, or watch while they are made.
Remove access afterwards
When the project is finished and the support period ends, remove the collaborator or staff account. Write the date in your store notes. Old developer accounts with wide access are one of the easiest things to forget and one of the easiest to fix.
Where the work happens
All changes should be made on a copy, never on the live theme.
- Duplicate the published theme and give the copy a clear name, such as “Dev: size chart fix” with the date.
- The developer works on the duplicate and sends you a preview link.
- If the theme is stored in a code repository, ask that changes are made on a separate branch and that you can see the history.
- Larger projects may use a separate development or test store, so that test orders and data never touch the real store.
Agree a “code freeze” before busy periods. Our guide to peak season preparation covers why changing themes and apps right before a sale is risky.
Test before you approve
Do not approve work from a screenshot. Open the preview yourself and run through a short test list:
| Check | How |
|---|---|
| The change works | Follow the acceptance points in the brief |
| Phones | Your own phone and, if possible, one other model |
| Desktop | At least two different browsers |
| Key pages | Home, a collection, two product pages, cart |
| Apps still work | Reviews, back-in-stock forms, upsells, whatever you rely on |
| Purchase path | Add to cart and reach checkout; a test order if your platform supports it |
| Speed | Compare the duplicate with the live theme; see our store speed checklist |
| Browser console | Ask the developer to confirm there are no new errors |
Write down anything that fails and send it back as one list, rather than in a stream of messages.
Publishing the change
- Publish at a quiet time, not just before a sale or a marketing email.
- Keep the previous theme unpublished for a few weeks so you can switch back if something appears later.
- Check the live store straight after publishing, using the same test list.
- Watch orders and support messages for a couple of days for anything unusual.
Get a proper handover
The handover is what lets you, or the next developer, understand the work later. Ask for:
- A plain summary of what changed and why.
- A list of files created or edited, with a note on each.
- Settings added to the theme editor, and what they do.
- How to undo it, or which theme copy to restore.
- Anything that depends on an app or an outside service.
- Known limits: “If you switch themes, this will need to be rebuilt.”
Keep the handover in the same place as your store notes and app list. When you next run an app audit, it tells you which code belongs to which change.
Common mistakes
- Starting with “make it look better” instead of a specific problem.
- Sharing the owner login.
- Letting changes go straight onto the live theme.
- Approving work without testing on a phone.
- Paying everything up front for a large project.
- Leaving collaborator access in place for months after the work ended.
- No written record of what changed.
FAQ
Should I pay hourly or fixed price?
Fixed price works well for small tasks with a clear brief. Hourly with a written cap suits work that is hard to predict, such as tracking down a bug. Either way, agree the maximum in advance.
What if the theme updates and the change breaks?
Custom code in a theme is not automatically carried into a new theme version. Ask the developer, before you hire them, how they would handle a future theme update, and keep the handover notes so the work can be redone.
Can the developer see my customer data?
Only if the access you grant allows it. Limit access to the areas the job needs, and if customer data is genuinely needed, agree in writing how it is handled.
Bottom line
Start with a written brief that describes the problem, the goal and what must not break. Choose someone who asks good questions and explains how they test, agree scope and price in writing, and give access through collaborator or staff accounts limited to what the job needs. Keep all work on a duplicate theme, test it yourself on real devices, publish at a quiet time and insist on a handover. Then remove the access.
