Check first, thenbuild: how we handlecustom requests

In short

Clients regularly want behavior that Shopify or the theme doesn't offer out of the box. Before we say yes, we check whether it can be done cleanly and with which tool: a setting, an app or a custom adjustment. Only when that's clear is there a price, and only after approval do we build. That's exactly how it went in one project: description of the desired behavior, check, offer, implementation. Afterwards, the adjustment worked as planned.

The case

“Can't you just change that quickly?” Often yes, sometimes no, and sometimes it depends on details that only show up once you look into the theme and the data. Agreeing without checking means promising a result you don't know yet. Quoting a price without checking is a shot in the dark.

Three routes, three consequences

We always look for the simplest route first. Custom adjustments only come in when the others don't fit. On pages where people buy directly, we stick to native Shopify features and proven apps.

How we do it

1. Describe the desired behavior precisely. What should happen, when, and in which cases not?
2. Check feasibility. In the theme, in the data, in combination with apps.
3. Set the route and price. With a clear description of what gets delivered.
4. Implement and test after approval. On all devices and affected pages.
5. Bill cleanly. The invoice names the specific service, so it's clear later what it was for.

Your takeaways

• Describe the behavior, not the technology. “When I do X, Y should happen” helps more than a proposed solution.
• Simplest route first. A setting or app is often faster and cheaper than custom code.
• A price without a check is an estimate. Better to get a quick feasibility confirmation.
• Custom code has to be tested and maintained. Factor that into the decision.

Got a wish your store can't fulfill out of the box? Tell us what should happen, and we'll tell you the cleanest route.