Ship the storefront your designer actually drew

We do both, but they are priced separately and the honest answer is that bringing finished designs is cheaper. If you have a designer or a brand team with Figma files, we build against them and the quote above applies. If you need design, add roughly three to four weeks and a separate design fee. What we will not do is quote a development number and then improvise the design as we go, because that is how projects miss dates.

A freelance Shopify developer is a good fit for contained work: a template, a section, a bug in a theme you already own. A development company is worth the premium when the work spans systems, because a storefront wired to an ERP needs someone who can hold the integration, the theme, and the data model at once, and needs to still be reachable in six months when the ERP changes. The failure mode we get called in to fix is a store built by three different freelancers in sequence, where nobody owns the whole thing. If your project is genuinely contained, hire the freelancer and keep the money.

Almost certainly not, and we spend more time moving brands off headless than onto it. Native Shopify with Online Store 2.0 now handles the performance and flexibility that justified headless five years ago, while keeping the admin, apps, and checkout your team already knows. Headless makes sense for genuinely unusual front-end requirements or when Shopify is one of several backends. For a normal storefront it adds cost, hiring difficulty, and a maintenance burden you feel two years in.

Frequently, but it starts with a paid audit rather than a quote. We need to see the code before committing to a number, because inheriting an unknown codebase is where fixed-price work goes wrong for everyone. The audit tells you what is salvageable, what should be rewritten, and what it costs either way. Sometimes the answer is that rebuilding is cheaper than repairing, and we would rather say that up front.

A theme edit changes your theme files directly, so it is yours forever but it also means your theme carries that logic and it can conflict on updates. A theme app extension lives in an app and injects into the theme through defined blocks, so it survives theme changes and can be removed cleanly. We use extensions for anything that behaves like a feature and theme code for anything that is genuinely presentational.

It is a build constraint rather than a cleanup phase. That means an image pipeline with correct sizing and lazy loading, no render-blocking third-party scripts added without a discussion, JavaScript kept off the critical path, and Core Web Vitals checked against field data before launch rather than a Lighthouse run on a fast laptop. Performance regressions almost always come from apps added after launch, so the handover covers how to evaluate one.

The 30 days after go-live cover anything that does not work as specified, at no charge. New requirements after that are either billed hourly or folded into a managed services retainer, and we will tell you which is cheaper for your volume. Because the section library is built for editing, most post-launch content and layout changes are things your own team can do without paying us at all, which is the point of building it that way.