Frequently asked questions

Yes. We move product and customer data, and where needed order history, images, blog posts and news as well. Redirects from the old URLs to the new pages are set up as part of the migration.

How much can be moved depends on what your current system can export and whether Shopify can hold it. Rather than moving everything as-is, we first sort out what to move and in what order, against the structure of the new site.

Yes. We take on post-launch changes, feature additions and ongoing technical advice.

There are two shapes: reserving a set amount of time each month, or engaging us individually as the need arises. Which suits depends on how often you update and how much you handle in-house.
See how the contracts differ

Updates to Shopify itself are handled by Shopify. Public apps, as a rule, are kept up to date with Shopify's changes by their vendors.

Where work tends to arise is when the theme carries custom implementations, or when a custom app uses Shopify's APIs. On ongoing engagements, we check the impact on our side and consult with you on any fixes needed.

We design so you can handle day-to-day operations yourself. Registering and editing products, swapping images and text, changing banners, editing sections on the top page and elsewhere, updating the blog and news, and filling in the fields we've prepared can all be done from the admin. Copy and settings that change often are made editable from the theme editor wherever possible.

On the other hand, changes to theme code, changes to how data is structured, external integrations, and deep app customization have wide-reaching effects. For those, it's safer to consult us.

Yes. Where an app's settings can't reach, we implement it in the theme or build a dedicated app.

That said, we don't jump straight to building. We first check whether standard features are enough, and whether a public app can meet the requirement. The more custom-built pieces there are, the more effort operations and future changes take.
See the order we decide in

Yes. Conversations before a deal is won are not unusual.

We verify that the requirements hold up on Shopify, and return a technical architecture with a rough estimate. Some engagements are solely to check pitch decks, or estimates about to go out, for technical overreach.
For agencies

Yes. We attend wherever a technical explanation is needed. We separate what can be done from what still needs confirming, and help carry the requirements through into a specification.

Which capacity we join in is yours to specify for each project. We can appear under our own name, or as part of your team.
For agencies

Yes. We implement the design you supply as a Shopify theme.

Before starting, we check whether it contains anything that is structurally awkward to build as-is, and whether the layout holds up as product names, images and the number of sections grow or shrink in day-to-day use. If anything gives us pause, we propose adjustments before proceeding.

Yes. We can sign one before you share project materials or client information. It is sometimes signed together with the master agreement.

We have our own template, but if you have a required form of your own, we use yours.

As a guide: two to three months for a store build, or as little as two weeks for a small build where requirements and materials are ready. A small custom app takes about two weeks; an external integration about a month, if the necessary documentation is in order.

That said, what sways the timeline isn't the development itself — it's preparing materials, reviewing designs, aligning internally, and waiting on replies from outside vendors. Once those are predictable, so is the overall schedule.
From first conversation to launch

Product information and images, your logo, the copy to publish, company information, legally required notices, shipping and payment terms, terms of service and privacy policy, your domain, admin access to your current site or cart, and specifications for any external systems. If we're handling design, we create it.

If you're new to e-commerce and don't yet have policies, we can provide generic templates — but checking that they fit your business, and the final call, rest with you.

We decide per project. Where misalignment is likely, we ask you to review at each stage — wireframes, design, implementation. On smaller projects, adding review rounds is itself a burden, so we agree the direction up front and have you look at only the key points.

For day-to-day contact we fit in with whatever you already use — Slack, Chatwork, Microsoft Teams, LINE, email. Meetings are mainly on Google Meet. On projects that go through a production company, we work to your regular meetings and your process.

Our estimates include headroom for a reasonable amount of change and adjustment. Minor changes, and adjustments within the anticipated range, are covered by the original estimate.

If the total effort looks likely to exceed expectations, we don't spring extra charges on you. We first explain what won't fit in the current scope, then discuss whether to do it now, defer it, or contain it another way. An additional estimate is drawn up only after what to proceed with is decided.

Yes. We take on work regardless of region. Meetings are online by default, and we adapt to whatever communication channels you normally use.

If in-person meetings are needed, let's discuss based on the content and frequency.

We don't keep a flat price list.

Even for the same “build a store,” the work varies widely with the number of screens, the number of products, the data to migrate, external integrations, and how much of the design you leave to us. We hear your requirements and estimate individually.

We break the work into line items and build it up. Beyond implementing each screen, we count everything needed to reach launch, one by one: product registration, shipping and payment setup, admin configuration, app configuration, data migration.

Because it's itemized, the scope can be rearranged to fit your budget. Rather than shaving the number, we sort the work into what must happen now, what happens if there's room, and what moves to the next phase.

There is no charge for the first conversation, framing your requirements, our read on whether it's feasible, the estimate, or presenting several options.

Work such as setting up an environment to see how something behaves, connecting to an API to find out what data is available, analysing existing code, or building a prototype begins once the engagement is confirmed. On larger projects where the direction is already settled, we sometimes do part of this before the order to make the estimate more accurate.

Our standard is end-of-month closing with payment at the end of the following month.

On larger projects, we can split payment between kickoff and delivery, or by project milestones, to match your schedule. When working through a production company, we align with your closing date and payment cycle.

Within each month's contracted hours, we take consultations and small improvements in priority order. The typical contents: a weekly check-in, technical consultation, feasibility calls, error investigation, light screen fixes, small feature additions, requirements sorting, and prioritizing upcoming initiatives.

Larger fixes and new development are estimated and handled separately.

Unused hours don't roll over to the next month. It isn't a contract to purchase work hours — it's a standing allotment we hold open for you each month.
See the two ways to work with us

There's no minimum term. To end the contract, let us know by the end of the month before your final month.

Contracted hours can be increased or decreased from the following month. You can also pause and resume when the need returns — though while paused we don't hold your allotment, so timing and available hours on resumption depend on our situation at the time.

We can't take on what Shopify's specifications can't support, what violates the terms of Shopify or the services involved, projects requiring a guarantee of sales or outcomes, schedules too short to assure quality, or problematic payment or contract terms.

We never decline simply because the budget is limited. If priorities can be set and the scope adjusted, that's a place to start.
See how we judge

Unless a requirement can only be met on Plus, we propose the standard plans.

We don't pick a higher plan from the start just because it might be needed someday. Rather than deciding mechanically by revenue, we look at whether the features you need can be realized on a standard plan, whether it fits your current operations, and whether the cost is matched by the benefit.

Yes. We start by establishing when it began and what changed just before, then isolate the cause: a public app, the theme, added code, a custom app, or a settings change.

If the cause is in a public app, we organize the necessary information and contact the vendor. If it's in the theme or in something we implemented, we investigate and fix it. We also take on investigations when the trouble followed an app you installed yourselves.

Yes. We design and implement the exchange of data with systems outside Shopify — your core internal systems, inventory and order management, in-store POS, external payment services and so on.

What we settle before starting is which data is authoritative, when it syncs, and what happens when it doesn't go through. Without agreeing that first, when the numbers disagree there is no way to tell which side to fix.

Theme code is, as a rule, entirely your asset. We hand over custom app source code as well. If it's managed in Git, we can transfer the repository itself.

When a contract ends, we delete the access we hold. We'll also join handover meetings with your next vendor. Handover documentation is prepared on request.
See why we do it this way

It's decided per project. If you already have a cloud environment, we build and run it there.

When we handle ongoing maintenance, we can provision and manage it ourselves; costs are billed at actuals plus necessary expenses. If management later moves to your side, the transfer is estimated separately.

Note that even a server-management-only arrangement effectively works as a maintenance contract, since it includes monitoring and incident response.

On every project, we keep six rules. We don't store production data locally without need. We don't feed personal data or credentials into generative AI. We use two-factor authentication on every service. We work from the designated network environment. We limit access rights to what the work requires. We delete our access when the contract ends.

If you have your own information-management policies or environment requirements, those take precedence. We also respond to vendor assessments and security checklists.

We do. Its main uses are sorting requirements, technical research, preparing documents, generating and completing code, review, surfacing test perspectives, and investigating the causes of defects.

We don't input your personal data, API keys, passwords or credentials, information barred from external sharing, or data extracted from production. If you have internal rules on AI use, we review and follow them.

There's no such distinction as “dangerous because AI wrote it, safe because a human did.” Either way, defects and security issues can slip in, so verification and testing are required.

Nothing generated goes live as-is. A person confirms it matches the requirements and design, follows Shopify's specifications, doesn't affect the existing theme or apps, contains no unnecessary permissions or risky processing, and holds up in real operation — then we fix, test, and only then ship.

We take responsibility for what we deliver, whether or not AI was involved.

It depends on the project.

When the spec is settled and the work is more hands than judgment, the efficiency can show up in the price. But on projects that start with understanding your business, sorting requirements, and comparing several approaches, it barely changes.

That's because the heart of the cost isn't the time spent writing code — it's the time spent deciding what to build, which approach fits, and how to run it safely.

Some steps get faster. Implementation against a settled spec, boilerplate code, research, and surfacing test perspectives all move quicker than before.

But the overall timeline doesn't shrink in proportion. Understanding the business, sorting requirements, design, your reviews and decisions, coordination with outside vendors, testing, data migration, and launch preparation can't be finished by AI alone.

The time gained goes not only into tightening deadlines, but into design exploration, comparing alternatives, and testing.

If we're in a position to respond, we do our best to. The typical cases: the store won't display, purchases fail, order processing is misbehaving.

We first establish the extent of the impact, then start with whatever is blocking purchases or operations. We sometimes work nights and weekends, but we don't promise 24-hour coverage or a recovery deadline.

On the monthly plan, this is covered within your contracted hours. Without a contract, we quote the investigation and recovery as a one-off engagement. If a few minutes of checking can answer it, there may be no charge at all.

Yes. No spec documents or repository, the previous engineer unreachable, no way to promise in advance that it can be fixed — even so, we never decline because information is missing.

Without touching the live theme, we read the existing code in a duplicated environment. We separate the spec that's actually in use, the implementations that no longer are, and the places where the cause lies — then propose a realistic way forward.
See how takeovers proceed

For one-off engagements, if the investigation shows we can't solve it, as a rule there's no charge. That covers causes on Shopify's side — specifications or outages — defects in third-party apps, and cases where the cause couldn't be identified.

On projects already under way, investigation time is included in the estimate. If the original approach turns out not to work, we report why, then discuss an alternative architecture or an adjusted scope.