A lot of brands buy development support the way they buy insurance. They know they need cover, they are not sure what kind, and they pick whichever policy looks reasonable in the moment. That is how you end up with a retainer nobody can define, ticket support that moves too slowly, or a one-off project that fixes the symptom and leaves the thing causing it.
Start with the shape of the work
If your roadmap is known and finite, fixed-scope project work is usually the cleanest option. If the backlog is strategic and changes every week, sprint-based support wins. And if the store is mission critical, has several stakeholders, and regularly needs launches, fixes, CRO and coordination, a proper retainer often beats renegotiating scope every month.
When each model works best
- ✓Fixed-scope project: a redesign, a migration, one major feature set, a specific app build
- ✓Sprint support: quarterly CRO work, merchandising pushes, roadmap experiments, launch cycles
- ✓Retainer: ongoing Shopify teams carrying recurring technical debt, trading pressure and constant operational change
- ✓Emergency support only: rarely the cheapest route, though sometimes the only realistic one while growth is unstable
The common mistake is buying the model that looks cheaper instead of the one that matches the cadence of the work. A low retainer with undefined scope gets frustrating fast, usually for both sides. A string of tiny projects gets expensive in a quieter way, through context lost and rebuilt every time. Hourly rate is the easy number to compare. Decision overhead is the one that tends to decide the bill.
Questions worth asking before you buy support
- ✓Do we need shipping capacity, or technical judgement about what to ship?
- ✓Is our backlog stable enough to scope, or does it move every week?
- ✓Who signs off internally before work starts?
- ✓Which work repeats often enough that buying the context once will pay for itself later?
"The best support model is the one that fits the volatility of your store, not the one that sounds the safest in a proposal."
— Robin Singh, Thought Bulb
A practical rule of thumb
If the work changes every two weeks, do not force it into a fixed project. If the work is tightly defined, do not pay retainer overhead to rediscover the same scope every month. And if your team cannot prioritize cleanly yet, more dev hours will mostly buy you faster disagreement. Sort the operating model first. Support usually works about as well as the decisions feeding it.
