Building stores for clients

Agencies, freelancers and developers build Eekaam stores for merchants in one of two ways:

• Build it in a dev store, then transfer it. You set the store up in your own sandbox, show it to the client, and hand it over when it is ready. The client becomes the owner and pays for the plan. Use this for a new store.
• Work on the client's own store as a collaborator. The client already has a store and lets you into it. Use this to redesign a store, fix a theme or add products.

Both start in the developer dashboard at dev.eekaam.com. Sign in with your normal Eekaam account. The first visit turns on developer access for it.

Path 1: build in a dev store and transfer it

Create a dev store

1. In the developer dashboard, open Stores → Create a development store.
2. Enter a Store name. The store's address becomes the name followed by -dev, for example glow-dev.myeekaam.com.
3. Under What are you building? choose Building a store for a client.

The store opens with the default theme installed and some sample products, so the theme has something to show. Reset puts the sample data back if you need a fresh start.

Dev stores cost nothing and have every feature and limit of the Enterprise plan, so you can build the full catalogue and try any app. You can have 5 at a time, and a transferred store stops counting toward the limit.

You can also create dev stores and switch between them from the terminal with the Eekaam CLI:

Build the store

Open the store from the dashboard to work in its admin, the same admin your client will use. Everything a merchant does is available: products and collections, the theme editor, pages and menus, shipping, payment providers, apps and settings. The guides under Guides and Store management apply as they are.

To build the theme in code, run eekaam theme dev against the dev store. Your edits show up in a local preview as you save them. See Building a theme.

A few things to do before handing a store over:

• Remove the sample products. They are there for the theme, not the client.
• Leave payment providers to the client unless they gave you their credentials. Merchant IDs and API keys belong in the client's own accounts.
• Connect the client's domain after the transfer. The domain is the client's to point at the store. See Custom domains.

Show the client a preview

On the dev store's page, Preview links → Create link makes a URL the client can open without an account, and copies it for you. It shows the storefront with the theme as it is now. Each link shows how many times it has been opened.

A link lasts 7 days, or 14 or 30 if you choose. Delete it to stop it working early. Preview links all stop working when the store is transferred, because the store is no longer your sandbox.

Transfer the store

When the client is happy:

1. Open the dev store. Transfer to a merchant is below the store's details.
2. Enter the Merchant's email address, the address the client will sign in with.
3. Press Send invitation.

The client gets an email titled "[You] built [store] for you on Eekaam", with a button to accept. If the email cannot be sent, the dashboard shows the Invitation link for you to copy and send yourself.

The invitation lasts 14 days. While it is waiting it shows as Waiting for the merchant, and you can cancel it. A store has only one pending invitation at a time, so cancel the first one before inviting a different address.

From the terminal:

A dev store that is the demo store of one of your theme store themes can't be transferred. Create a separate dev store for client work.

What the client sees

The link opens a page that shows the store's name and address and who built it. The client:

1. Signs in, or creates an account, with the email address the invitation was sent to. Another address is refused, and the page offers to switch account.
2. Chooses whether to tick Keep [you] as an admin. It is off by default.
3. Presses Accept the store.

What changes at handover

All of this happens at once, the moment the client accepts:

The trial is the same one the client would get from signing up themselves. See Plans and pricing.

You get an email when the client accepts, saying whether you kept access. The store then leaves your list of dev stores and no longer counts toward your 5.

If you kept access, the store appears in your store switcher like any other store you work on. You are a collaborator, so you don't take up one of the client's staff seats.

Path 2: work on a client's existing store

The client shares a code

The client creates a collaborator code in their admin:

1. Settings → Users → Security → Collaborators.
2. Generate new code creates a 4-digit code.
3. They send you the code and their store's address.

Generating a new code replaces the old one. Remove code stops the store accepting requests until the client generates another.

You send a request

1. In the developer dashboard, open Client stores.
2. Under Request access, enter the Store address. This is the .myeekaam.com address or the store's own domain, for example glow.myeekaam.com or glow.pk.
3. Enter the Collaborator code.
4. Add a Message if you want to: who you are and what you'll work on. The owner sees it.
5. Press Send request.

The request shows under Your requests as Waiting for the owner. You can withdraw it while it waits. You can send up to 10 requests an hour, so a wrong code can't be guessed by trying them all.

The owner answers

The owner sees Collaborator requests on Settings → Users, with your name, email address and message. They choose the access to give you and approve, or decline. Only the store owner can answer a request.

• Full access lets you do everything an admin can. Choose this for anyone building or redesigning the store.
• Staff access lets you into the store with limited rights. You can't be given individual staff roles yet, so most store work needs Full access.

You get an email either way. Once you are approved, the store is in your store switcher and the request shows as Approved, with the access you were given.

Collaborators on the client's side

Collaborators are listed on Settings → Users with the store's staff, but they work differently:

• They use no staff seat. A client on a plan with two staff accounts can still let an agency in.
• Their account is their own. It also works on other stores, so the owner can't rename, suspend or delete it. The owner can switch them between Full and Staff access, or remove them from the store, which ends their access at once.
• Approvals, access changes and removals appear in Settings → Users → Security → User activity logs.

When the work is finished, the client should remove the agency, or switch it to Staff access if it stays on for support. See Staff and permissions.

Which path to use