--- title: "Frequently asked questions | shoplab" description: "From project timelines to our approach and ongoing support - answers to the questions that matter most before starting a Shopify partnership." url: https://shoplab.cc/en/faq --- [Back](https://shoplab.cc/en) Frequently asked questions # Everything you need to know From project timelines to our approach and ongoing support, we've answered the questions that matter most before starting a partnership. ## Service information ### Do you only work with Shopify? Yes. We have worked exclusively with Shopify and Shopify Plus since 2020, and turning down other platforms is what got us here. The trade is deliberate: a team that sees the same platform every day knows which problems have a native solution, which need an app, and which need custom code - so less of your budget goes into rediscovering that. It also means we follow Shopify's own conventions instead of porting patterns over from Magento or WooCommerce, which is what keeps a store upgradeable after we hand it over. ### What services do you offer? Strategy & consulting, custom Shopify theme development, custom app development, store migrations, UX/UI design, integrations & middleware, ongoing store management, and AI e-commerce readiness. Most projects combine three or four of those: a migration usually arrives with an ERP integration and a redesign attached, and a redesign usually surfaces a performance problem. Everything runs through one team, so a design decision and its development consequence get settled together rather than negotiated between two agencies. ### Can you redesign my existing Shopify store? Absolutely, and it is one of the most common ways clients start with us. We audit the current store first - conversion path, page performance, and the templates that carry the most revenue - then redesign against what the audit found rather than against a moodboard. Your products, customers, orders and URL structure stay where they are, so rankings and store data are not at risk. Redesigns can also ship in stages: the pages that sell first, the rest afterwards, so you see the effect before the whole budget is committed. ### Do you build custom Shopify themes? Yes, from scratch rather than by reskinning a marketplace template. A custom theme means the sections your merchandising team actually needs, editable in the theme editor without a developer, and no inherited code for features you will never use. That last part is the performance argument: off-the-shelf themes carry the union of every use case they were sold for, and you pay for it in Core Web Vitals on every page load. We build against your catalogue and your content model, then hand over documentation so your team can run it. ### Can you migrate my store from another platform? Yes - WooCommerce, Magento, Shopware and other platforms, in a staged, low-risk process. Products, variants, customers and order history come across, and every indexed URL gets a mapped 301 so the rankings you already earned survive the move. What decides the timeline is rarely catalogue size: it is data structures with no direct Shopify equivalent (bundles, configurable products, customer-specific pricing) and the systems your store talks to. We inventory both before a cutover date is set, which is why our migrations do not end with a redirect list written the night before launch. ### How long does a Shopify project take? It depends on scope: focused improvements often take 4-6 weeks, while full custom builds or migrations typically run 8-16 weeks. A store moving onto a configured theme is usually live in 4-8 weeks; a fully custom storefront runs closer to 10-16\. You get a timeline with defined milestones before we start, and those milestones are staged releases rather than one launch date at the end - so a delay in one area does not push everything behind it. What moves a timeline most is late scope additions and integrations nobody inventoried at the start. ### Will my Shopify store be optimized for mobile? Always. We design mobile-first because that is where most e-commerce traffic sits, and where most of the conversion loss happens. Every store is tested on real devices rather than a resized browser window, and measured against Core Web Vitals - largest contentful paint, interaction latency, layout shift - before it goes live. Image handling, font loading and third-party scripts get the most attention, because apps are usually what turn a fast theme into a slow store. Performance is a launch requirement here, not a follow-up ticket. ### Do you provide ongoing support after launch? Yes. Store management plans cover Shopify and app updates, iterative improvements, testing and technical support, on a monthly scope you can adjust as priorities change. Most stores need the first weeks after launch more than they expect: real traffic finds edge cases staging never produced, and the analytics only start telling the truth once volume arrives. After that, ongoing work tends to be conversion iterations on the templates that carry revenue, seasonal campaign support, and keeping the theme current as Shopify ships platform changes. ### Can you improve my store without rebuilding everything? Definitely, and we will say so when a rebuild is not the right call. We often work in focused iterations - a conversion audit, performance optimization, or redesigning the handful of templates that carry most of the revenue - shipped as staged releases with measurable outcomes instead of a big-bang relaunch. For a store that already converts this is usually the better economics: you keep what works, spend where the data points, and avoid the risk window a full replatform opens. A rebuild earns its cost when the underlying theme or data model is the actual constraint. ### How do we get started? Book a free strategy call - about thirty minutes, and you keep whatever comes out of it. We ask what you run today: platform, catalogue structure, connected systems, and what should be better after the project. From there you get a written proposal covering scope, timeline and pricing, with named work blocks rather than one number. If the call shows that what you need is smaller than an agency project, we will tell you that too. It is a cheaper conversation for both of us than finding out in month two. ## Our approach ### What does your process look like? Every project runs through strategy, design, build, launch and ongoing support, with a discovery phase before any design work starts. Each stage ends in something you can review rather than a status update: a scope document, clickable designs, a staging store. Releases are staged, QA is structured rather than a final week of clicking, and the milestones are agreed before kickoff. The shape stays the same whether a project runs two weeks or six months - what changes is how much sits inside each stage, not how many stages there are. ### How do you approach new projects? We start by understanding your brand, your customers, and what the business actually needs to happen. Rather than applying one template to every engagement, we look at where the revenue comes from today and where it leaks - which is often not where the brief assumed. That produces a scope with priorities attached, so when something has to give, it is clear what gives. It also means we sometimes propose less than was asked for: the fastest route to a result is usually a narrower first release, not a longer one. ### Do you follow a fixed workflow? The core process stays consistent, but its depth adapts to scope. A two-week engagement and a six-month build move through the same stages - discovery, design, build, QA, launch - because skipping one is how a project loses its audit trail, not how it gets faster. What scales is the paperwork: a small project needs a short scope document and one review cycle, a replatform needs a data inventory, a redirect map and staged cutover testing. The workflow exists to make decisions traceable, not to bill for ceremony. ### How do you keep clients involved throughout the project? Collaboration runs through the whole project rather than arriving at handover. You get regular updates, review points at the end of each stage, and direct access to the people doing the work instead of a relay through an account manager. Feedback is gathered where it is cheapest to act on - during design, not after development - and every change request is quoted separately before it is built, so the budget effect of a decision is visible while you are making it. Nothing significant should be a surprise at launch. ### How do you ensure the quality of your work? Quality is built into the process rather than inspected at the end. Designs go through review before development starts, code follows Shopify's platform conventions so it survives future updates, and every release passes structured QA across devices and browsers - not a final afternoon of clicking through the homepage. We test the paths that carry money first: search, product, cart, checkout. Performance and accessibility are checked before launch too, because both are far cheaper to build in than to retrofit once a store is live. ### What happens after the project is launched? Launch is where the useful data starts, not where the project ends. We monitor the store through the first weeks, when real traffic finds the edge cases staging never produced, and fix what surfaces. After that you can continue with a store management plan covering updates, iterative improvements, testing and technical support, or take it in-house. We hand over documentation either way: the theme is built to be run by your team, not to keep you dependent on ours. ![Mark Chang and Martin Winkler, the shoplab founders, in shoplab hoodies](https://shoplab.cc/images/cta/founders.jpg) Martin Winkler Co-Founder & CEO Mark Chang Founder & CTO ## Ready to build your Shopify growth strategy?