Where is your team, and what hours do you actually work?

Canada, on Mountain Time, which is UTC−7 in winter and UTC−6 in summer. Our normal working day is 08:00 to 16:30 Mountain, and we open it early, from 06:00, for booked calls with merchants in the UK and Europe. That early window is 13:00 to 16:00 in London and 14:00 to 17:00 in Berlin, Paris and Amsterdam, every business day.

Can I get a live call if I am in Australia or Singapore?

Yes, booked rather than ad hoc. We take scheduled Asia-Pacific calls at 16:00 to 18:00 Mountain, which lands early the next morning in Singapore and mid-morning the next day in eastern Australia — the exact hour shifts with daylight saving on both sides, so the invite carries the real time. Day to day, Asia-Pacific work runs async-first: anything you send during your working day is answered before your next working morning, because our day runs through your night.

How often will I hear from you, and what is in the update?

A written update every week, plus one scheduled call a week on a project or one a month on a retainer. The update contains what shipped with a link to the thing itself, what is in progress, what is blocked on your side with the date we asked, the delivery date restated, hours used, any change raised with its estimate, and what happens next week. If there is nothing to decide, we cancel the call and send the update. We do not hold a call to demonstrate that we are working.

How fast do you reply during an engagement?

Anything blocking a delivery date, same business day. An ordinary question, within one business day. A written estimate for a change, within two business days. A failed daily assertion on a retainer raises its own alert on the run that catches it, with the failing evidence attached — the checks run on a schedule rather than continuously, so that is the run and not the second the failure occurs. Anything arriving after 16:30 Mountain on a Friday is answered Monday: we are not a round-the-clock on-call team and we will not sell you one.

What happens when I ask for something outside the scope?

Work on it stops, it is written down as its own item, and you get an estimate in writing within two business days: hours at $135/hr USD, and what it does to the delivery date. You approve, decline or park it. Only an approved estimate gets scheduled, and it reaches the invoice with your approval attached. You should never read a line item for the first time on an invoice.

Do you charge for fixing your own bugs?

No. Defects in work we delivered are covered by a 30-day bug-fix warranty on project work, and calling one a change order would be a way of charging you to finish the job. An ambiguity in the scope document is not a change either — we wrote the document, so if a line can be read two ways, the reading that does not cost you more is the one that applies. Nor is work needed to meet a target already in the scope, even where it turns out harder than we estimated. A fixed price is fixed, and the estimating risk is ours.

What access do you need to my Shopify store?

A staff account in a named person’s name so your activity log shows who did what, and a custom app with the specific API scopes the work needs. You get a list with one line per scope explaining which check or sync it is for; if we cannot write that line, we do not ask for the scope. We never ask for the account owner login, never for your payment provider or billing, and never for a credential over email or chat. Credentials sit in an encrypted store scoped to the people on your engagement, and you can revoke everything yourself from your admin at any time.

Do you sign a data processing agreement?

Yes, before access is granted rather than after the first invoice. Building or running order plumbing means processing merchant customer data — names, addresses, order contents — so a DPA is signed as part of onboarding. It names what we process, why, where it is held, who else touches it, how long it is kept, and what happens to it when the engagement ends.

What do I own at the end?

Everything we build in your store belongs to you. All code — theme, custom app, middleware, assertion definitions — plus the runbook, the diagrams and the exported exception queue. Ownership is assigned, not licensed, and nothing stops working if you stop paying us. Accounts and repositories are created in your name on day one rather than transferred at the end, so there is nothing sitting in our name to hand back.

Is there a minimum term on a retainer, and how do I leave?

No minimum term, no auto-escalating renewal, no cancellation fee. Retainers run month to month with 30 days written notice either way, and an email is enough — you do not owe us a reason. The notice month is worked rather than coasted, handover happens inside it, and on the last day we deactivate our own access and confirm it in writing. Questions about what we built are answered free for 30 days after that.

What if my next developer has questions after we part ways?

We will get on a call with them, and we offer that whether you left happy or not. We would rather answer questions directly than have someone reverse-engineer our work and quietly rebuild it at your expense. There is also a recorded end-to-end walkthrough in the handover so they can watch it in their own timezone without booking anyone.

What happens to a delivery date if I am slow?

The clock pauses while the work is with you. That is arithmetic rather than a penalty: we run a maximum of three concurrent projects so the dates are meetable in the first place, and a week spent waiting on one approval is a week the slot sits idle. The 25% credit toward the next engagement applies to a date we miss. It does not apply to a date missed because of merchant-side delay, third-party app defects, or a platform incident, and we would rather say that here than put it in a schedule at the back.

( /how-we-work )

How we work

01Mountain Time, stated in hours
02Changes quoted before they are done
03You own it, and you can leave

Carrtel Solutions is a Shopify Partner. We build stores on Shopify.

How we work — timezones, scope, and how you leave

Hiring a small remote team raises four questions that most agency websites answer by not mentioning them: what hours you can actually reach us, how often you will hear from us, what happens when the work changes, and what you are left holding if it ends. This page answers all four, in numbers where numbers exist.

A real daily overlap window for North America and for Europe
A written weekly update with a fixed set of contents
Changes estimated at $135/hr and approved before any work starts
Scoped access, an encrypted credential store, and a signed DPA
A 30-day exit with everything you own, documented and handed over

Read the exit terms first See every price we charge

The short answer

What is it like to work with Carrtel?

We are in Canada on Mountain Time and work 08:00 to 16:30 MT, opening at 06:00 for booked European calls, which gives 13:00 to 16:00 in London and 14:00 to 17:00 in Berlin. Asia-Pacific is handled async-first with a reply waiting before your next working morning, plus scheduled calls at 16:00 to 18:00 MT. Scope is fixed in a written document before work starts, and anything outside it is estimated at $135/hr USD and approved by you before it is done. Access is scoped rather than blanket, credentials sit in an encrypted store, and we sign a DPA because we process merchant customer data. Retainers are month to month with 30 days notice, and everything we build in your store belongs to you.

Last updated: August 2026

Timezones

We are on Mountain Time. Here is what that costs you.

Mountain Time is UTC−7 in winter and UTC−6 in summer. Every window below is a real bookable window, not a promise of availability that turns into an email chain.

Daily overlap between Carrtel's Mountain Time working day and each region we serve, with the equivalent local hours and whether the region is handled live or async-first.
Where you are	Our window	On your clock	What that means in practice
Western North AmericaPacific, Mountain	08:00 – 16:30 MT	07:00 – 15:30 Pacific Live, same day	Our day opens before yours and closes inside it, so there is no gap to schedule around. Mountain merchants are on our clock exactly.
Eastern North AmericaCentral, Eastern, Atlantic	08:00 – 15:00 MT	10:00 – 17:00 Eastern Live, same day	We stop booking Eastern calls at 15:00 our time so nothing lands after 17:00 on yours. Central sits an hour inside that on both ends.
United Kingdom and IrelandGMT / BST	06:00 – 09:00 MT	13:00 – 16:00 London Live, booked	Three hours, every business day. We start early rather than asking you to stay late, because the person who wants the meeting should be the one who moves.
Continental EuropeCET / CEST	06:00 – 09:00 MT	14:00 – 17:00 Berlin, Paris, Amsterdam Live, booked	The same window, one hour later on your clock. It is the closing stretch of your afternoon rather than your evening.
Asia-PacificSGT, JST, AEST / AEDT	No overlap inside business hours	Async, with a reply before your next morning Async-first	Our working day runs while you are asleep. Pretending otherwise would mean one of us taking a call at 02:00, and the one taking it would eventually be bad at it.

Daylight saving

North America changes clocks on different weekends from Europe, so for about three weeks each spring and one week each autumn the gap to the UK and Europe is six hours rather than seven. Windows move an hour on your clock during those weeks. Every invite we send carries the correct local time rather than a rule you have to apply yourself.

Public holidays

We work Canadian statutory holidays into the schedule before a date is agreed, and we tell you which ones fall inside your project when we set the date. A date is not set and then apologised for later.

The honest limit

One team on one continent cannot cover every clock. Being explicit about the overlap is the alternative to implying a coverage we do not have and then discovering it together at the worst possible moment.

Asia-Pacific

Async-first, with the parts that have to be guaranteed

( 04 commitments )

There is no honest live overlap between a Mountain Time working day and a Singapore or Sydney one. Rather than describe a fourteen-hour gap as “flexible hours”, here is what we commit to instead, and it is deliberately the sort of thing you can hold us to.

A reply waiting when you open your laptop

Anything you send during your working day is answered before your next working morning. The gap works in your favour here: our day happens overnight for you, so a question sent at the end of your Tuesday has an answer sitting at the top of your Wednesday.

Questions that only need answering once

We do not send a question that generates another question. Each one arrives with the options, our recommendation, and what happens if you choose each. You answer once, and the work moves. A round trip is one day, not three.

A live call when you need one, booked

We will take a scheduled call at 16:00 – 18:00 Mountain, which lands early the next morning in Singapore and mid-morning the next day in eastern Australia. The exact hour moves with daylight saving on both sides, so the invite carries the real time. We ask that these be booked rather than ad hoc, because they sit outside our normal day.

Decisions in writing, not in meetings

Every decision is recorded in the tracker with the reasoning attached, so nothing waits for a call to become real. If you are twelve hours away, a decision that can only be made live is a decision that costs you a day.

Communication

One tracker, one weekly update, one call you are allowed to cancel.

Distance hides work before it slows it down. Not being able to see whether anything is happening is a reporting problem rather than a delivery one, so it gets a fixed answer here instead of a reassurance.

Where the work is tracked

One written tracker you can open yourself, whenever you like, without asking. Every item has a number, an owner and a state, and the owner is either us or a named person on your side. If you already run a board or a shared channel, we work in yours rather than making you check two places.

How often you hear from us

A written update every Friday by 12:00 Mountain, sent Thursday instead for Asia-Pacific merchants so it lands on your Friday morning. One scheduled call a week during a project, one a month on a retainer, 25 minutes, agenda the day before and a written summary after.

When we cancel the call

If there is nothing to decide, the call is cancelled and the written update goes out instead. A standing meeting held to demonstrate activity is a meeting you are paying for twice: once in the retainer, and once in the hour it takes out of your week.

The weekly update

Seven sections, every week, in the same order

( 07 )

A fixed structure is what makes an update readable in ninety seconds and comparable to the one before it. It also makes an omission obvious, which is the point of section three.

What shipped, with the thing itself attached

Not "progress on the product template". A link to the pull request, the preview URL, the theme version, or the assertion that now runs. If you cannot open it, it did not ship.

What is in progress and what it is waiting on

Each open item with its state and its blocker, if it has one. An item that has not moved for two weeks is called out as an item that has not moved for two weeks.

What is blocked on your side, by name and by date

The specific approval, credential or asset we are waiting for, who we asked, and the date we asked. This is the section most likely to be uncomfortable, which is exactly why it is in every update rather than saved for the end.

The delivery date, restated every week

Either unchanged, or changed with the reason and the arithmetic. A date that moves gets reported the week it moves. You should never find out at the end that a date slipped in the middle.

Hours used against the scope or the retainer

On a retainer, fix-hours used out of the monthly allowance. On a project, where we are against our own estimate. That number is ours to manage on a fixed price, but you get to see it.

Any change raised this week, with its estimate

Anything that came up outside the scope, what we think it costs at $135/hr, and what it does to the delivery date. Listed whether or not you have decided on it.

What happens next week

Three or four lines. Enough that if the next update does not match it, you have a question to ask us.

Response times

What you can expect, and what you cannot.

( 06 )

Anything blocking a delivery date: Same business day
Including a "we do not know yet, here is when we will". Silence is not an acceptable holding pattern on the thing your date depends on.
An ordinary question during a project: Within one business day
A question sent inside the overlap window can be answered while you are still at your desk, because it lands while we are at ours. One business day is the ceiling we commit to, not a description of past averages.
A failed daily assertion on a retainer: On the run that catches it
The check raises the alert itself, with the failing evidence attached, rather than being summarised or held back for the weekly reconciliation receipt. The checks run on a schedule rather than continuously, so the alert arrives with the run that catches the failure and not the second it occurs.
A message from an Asia-Pacific merchant: Before your next working morning
Our working day sits inside your night, so a question from your Tuesday is answered by your Wednesday morning.
A written estimate for a change: Within two business days
Hours at $135/hr, plus what it does to the date. Nothing is started on a change until you have that in writing and have said yes.
Anything that arrives after 16:30 Mountain on a Friday: Monday morning
We are not a round-the-clock on-call team and we will not sell you one. Continuous cover needs people awake in more than one timezone, and we do not have them, so the weekend is written here rather than discovered on a Saturday.

Scope and change control

Nothing reaches an invoice that you have not already approved.

A bill containing work nobody remembers agreeing to is what a verbal scope and a silently absorbed change produce between them. Both are mechanical failures, so both get a mechanical answer below.

Scope is fixed in writing before anything starts

Every engagement begins with a scope document that both sides sign. No work starts on a verbal scope, a call summary, or a proposal deck. The document is the thing we are both held to, including us, and it is deliberately specific enough to be inconvenient to write.

01Every template by name, so "the storefront" is never the unit of measurement.
02The SKU ceiling, and what happens past it rather than what it costs to find out.
03Each integration named, with the direction data moves and the system on the other end.
04The acceptance tests: what has to be true for the work to be finished, agreed before it starts.
05The delivery date, and what each side has to do on which day to hold it.
06An explicit list of what is NOT in this scope, because that list is what decides whether a later request is a change or something already paid for.

This is a change · quoted at $135/hr

Billable, and estimated before it is started

A template that is not on the list, however small it looks from the outside.
A second destination system on an integration priced for one.
Redesigning something that was already approved and built to that approval.
A third-party app introduced mid-build that changes what we have to integrate with.
A change of theme, platform or data source after work has begun.
Work created by reversing a decision after it was approved and built against.

This is not a change · not billed

Ours to absorb, and we would rather say so in public

A defect in something we delivered. That is the 30-day bug warranty, and calling it a change order would be a way of charging you to finish the job.
An ambiguity in the scope document. We wrote it. If a line can be read two ways, the reading that does not cost you more is the one that applies.
Work needed to meet a target already written into the scope, even where it turns out harder than we estimated. A fixed price is fixed, and the estimating risk is ours.
Our own rework, including anything we have to redo because we misunderstood something you told us clearly.
A conversation. Asking what something would cost is free, and asking does not commit you to it.

The change process

Five steps. Step four is the one that matters.

( 05 steps )

It stops and gets written down

The moment a request looks like it might sit outside the scope, work on it stops and it is written down as its own item. It is not quietly absorbed, and it is not quietly done and mentioned later.

We estimate in writing, within two business days

Hours at $135/hr, what it changes about the delivery date, and what happens to the rest of the schedule. If the estimate has a range, you get the top of the range as the number to plan against.

You approve, decline, or park it

Declining is free and the original scope continues exactly as it was. Parking puts the item on a list for after delivery, where it will still be waiting with its estimate attached. Nobody is going to make declining awkward.

Only then is it scheduled

No approved estimate, no work. This is the rule that makes the other four enforceable rather than decorative: without it, every step above it is a preference, and an invoice can still arrive carrying something you never agreed to.

It appears on the invoice with the approval attached

Every line traces back to a message you sent saying yes. You should never read a line item for the first time on an invoice. If you do, we have made a mistake and it comes off.

The rate

$135/hr USD for anything outside a fixed scope, and for fix-hours used past a retainer allowance. It is the same rate for everyone and it is published on the pricing page.

The ambiguity rule

We wrote the scope document, so we carry the cost of it being unclear. If a line can be read two ways, the reading that does not cost you more applies. This is written down precisely so it is not renegotiated in the moment.

Estimating risk

A fixed price does not move because the work turned out harder than we thought. That risk belongs to the party who did the estimating, and that party is us.

See the full price list

Access and security

Scoped access, and a list of what we will never ask for.

Handing a stranger the keys to a live store is the genuinely risky part of this arrangement. The mitigation is not a reassuring sentence. It is a short list of specific permissions, each with a reason attached.

A Shopify staff account in a named person’s name

So every action taken in your admin carries a name in your own activity log, and you can audit us without asking us anything.

One account per person, never a shared login. Permissions for the work in the scope document and nothing beside it. Never the account owner login.

A custom app with named API scopes

Assertions and integrations read through the API rather than through a browser session, so they can run on a schedule and be checked by you.

You get the scope list with one line per scope saying which check or which sync it is for. If we cannot write that line, we do not ask for the scope. It is not published to the App Store.

Read access to logs on the receiving side

A dropped order is only provable by comparing both ends. Without the receiving log we can tell you Shopify sent it, and nothing at all about whether it arrived.

Logs, not the ERP or the 3PL itself. We do not need to be able to change anything in your back office in order to check that it received an order.

A repository for theme and app code

So every change has a diff, an author and a date, and so undoing something is a revert rather than a rescue operation.

Created under your organisation, not ours. You are the owner from the first commit, which is also why there is nothing to transfer at the end.

Protected customer data approval, where the work needs it

Order data is protected customer data under Shopify’s rules, and an app that reads it has to be approved for it. That is a real step in onboarding rather than a formality.

We tell you which parts of the work require it and what we can still do if you would rather not grant it. Some things genuinely cannot be checked without it, and we will say which.

What we will never ask you for

Your account owner password. Not once, not temporarily, not "just to set it up".
A credential sent over email, chat or a screenshot. If one reaches us that way we will ask you to rotate it, and we will say why.
Your payment provider, your bank, or your Shopify billing. We never need the ability to move your money in order to check that it moved.
Blanket administrator rights on your ERP, 3PL or accounting system.
Access to any system that is not named in the scope document.

If anyone claiming to be from Carrtel asks you for one of these, it is not us. Send it to support@carrtelsolutions.com and we will tell you so in writing.

Credentials

Encrypted, inventoried, and revocable without us

( 04 )

Held in an encrypted store, scoped to your engagement

Credentials live in an encrypted secrets store, never in a document, a spreadsheet, a chat thread or someone’s browser. Each entry is scoped to your engagement and readable only by whoever is working on it.

Inventoried, so you always know the size of the blast radius

Every credential and every scope we hold appears on a written inventory, and you get a copy of it. You should never have to guess what you would need to rotate if you decided to rotate everything today.

Revocable by you, without asking us

You can deactivate our staff accounts and uninstall the custom app from your own admin at any moment, without a ticket and without a conversation. We would rather that lever sit in your hand than in ours.

Time-boxed to the engagement

Access exists for the work in front of it. It is reviewed at the end of every project and every retainer month, and it is removed on the last day of the engagement rather than whenever someone remembers.

We sign a DPA before access, not after the first invoice

Building or running order plumbing means we process merchant customer data: names, shipping addresses, order contents, sometimes email and phone. That makes us a processor acting on your instructions, so a data processing agreement is signed as part of onboarding rather than produced later if someone asks. It names what we process, why, where it is held, who else touches it, how long it is kept, and what happens to it the day the engagement ends.

Order data is also protected customer data under Shopify's rules, so an app that reads it has to be approved for that access. We tell you which parts of the work require the approval, and what we can still do without it if you would rather not grant it.

The agreement is not published on this site. Ask for it and we send the current version to read before anything is signed and before any access is granted, which is the order that matters.

Ask us for the DPA How to verify us

How you leave

Everything we build in your store belongs to you

A clean exit is the part of any arrangement a supplier has the least commercial reason to make easy. It is also the first thing a careful buyer wants to know, so the terms sit on a page you can read before signing rather than in a contract you read after.

What you own at the end

Ownership is assigned to you on final payment for the work it belongs to. It is not licensed and it is not rented. There is no component we keep and bill you to keep using, and nothing in what we built stops working if you stop paying us. That is a design decision, not a concession: a system that holds its owner hostage is one we would have to defend, and we would rather keep the work by doing the work.

01All code written for your store: theme code, custom app code, middleware, scripts, and the assertion definitions that check them.
02The documentation: the runbook, the architecture diagrams, and the plain-language description of what every assertion checks.
03Every account created for the work, because it was created in your name on the first day rather than transferred to you on the last.
04The exception queue and its history, exported in a format you can read without us.
05The data. It was always yours; we process it, we do not hold a copy of it as an asset.

Accounts are created in your name on day one

This is the mechanism that makes the rest of it real. The repository is created under your organisation, cloud resources under your account and billed to you, the custom app installed on your store. Nothing has to be transferred at the end, because nothing was ever in our name. An exit that depends on a migration is an exit somebody can slow down.

What you cannot take, stated plainly

Third-party app subscriptions. Those are between you and the vendor, and they always were — we never held them, so there is nothing for us to hand over.
A tool we license across all of our work. Which is exactly why nothing your store depends on is built on one. If a piece of work would need it, we tell you before you buy the work, not at the exit.

Notice and lock-in

Thirty days, by email, no reason required

( 04 )

Month to month, no minimum term

Retainers have no lock-in period, no auto-renewal that escalates, and no cancellation fee. There is no clause that makes leaving in month four more expensive than leaving in month forty.

30 days written notice, either direction

An email is enough. You do not owe us a reason, and we will not ask you onto a call to give us one. The same 30 days applies to us, so you are never told on a Friday that Monday is not happening.

The notice month is worked, not coasted

Your fix-hours in the final month are still yours, and handover work is done inside the retainer rather than billed on top of it. A month you have paid for is a month of work.

Project work carries no ongoing commitment at all

A build or a migration ends when it is delivered and accepted. Taking a retainer afterwards is a separate decision, made after you have seen the work, and declining it changes nothing about what you already own.

Handover

What arrives in the last week

( 09 items )

A handover is not a folder of files. It is whatever the next person needs in order to run the system without ever speaking to us, assembled while we still remember why each decision was made.

The repository, full history, you as owner

Every commit, every branch, every message. Not a zip file of the final state. Our accounts are removed from it on the last day.

A runbook

What runs, where it runs, on what schedule, what it talks to, and what to do when each piece of it fails. Written for someone who has never seen the system before, because that is who will read it.

The assertion set in plain language

What each daily check compares, what a pass looks like, and what a failure actually means about your store. A check nobody can interpret is a check nobody will keep running.

The credential and scope inventory

Every credential we held and every API scope we used, with what each one was for, so rotating us out is a list to work through rather than an investigation.

The architecture, drawn

How data moves between Shopify and every other system, as a diagram. Descriptions of integrations in prose are how integrations get misunderstood by the next person.

The exception queue, exported

Every item, its state, its history, and the ones still open with what we know about them. Including the ones we never got to the bottom of, marked as such.

A recorded walkthrough

A screen recording of someone talking through the system end to end, so whoever inherits it can watch it at 2am in their own timezone without booking us.

A live call with your next developer, if you want one

We would rather answer their questions directly than have them reverse-engineer our work and quietly rebuild it. This is offered whether you left happy or not.

Thirty days of questions answered at no charge

After the last day, for a month, questions about what we built are answered without an invoice attached. Not new work — questions about the thing you already own.

And what we do on our side, the same day

Staff accounts deactivated, the custom app uninstalled, and repository access removed. We do it ourselves on the last day and send written confirmation with the time it was done.
Merchant customer data we processed is deleted on the schedule written into the data processing agreement, and you get confirmation of that too.
The credential inventory sent one final time, so your rotation list is in your hands before you need it rather than after.
Everything above is verifiable from your own admin without taking our word for any of it, and we would genuinely rather you checked.

What we need from you

Seven things, and the date holds.

A delivery date is a shared commitment: part of what holds it is our work, and part of it is yours. The 25% credit excludes a date missed because of merchant-side delay, so the honest thing is to publish exactly what we are asking of you before you agree to a date.

One named decision-maker, and a backup

A person who can approve without convening anyone, plus someone who can do it when they are away. Two people who each assume the other is deciding is the most expensive item on this page.

Access on day one

The staff account, the custom app install, the repository, and read access to the logs on the receiving side. A build that starts without access is a build that starts late, and the date was set assuming it did not.

Approvals inside two business days

A three-week wait on one approval does not compress back into the schedule afterwards — it moves the end date by three weeks. That is arithmetic, and it is why the approval window is written into the schedule rather than assumed.

Content in the agreed format, by the agreed date

Copy, images, product data. The format and the deadline are both written into the scope document rather than assumed. We can build around a gap; we cannot invent your product data.

A test account on every system we integrate with

A sandbox on your ERP, 3PL or accounting system, and a real person on their side we are allowed to email directly. Testing an integration against production is not a plan, it is a story about an incident.

A heads-up before you install an app

During a build, a new app can inject scripts into the theme we are working in. Told first, it costs a conversation. Told afterwards, it costs a debugging session, and the debugging session is the expensive one.

A tester during the acceptance window

Someone who knows what the store is supposed to do, available on the days written into the schedule. Acceptance is the point where the work stops being ours and starts being yours, and it needs you in the room.

The clock pauses while the work is with you

This is arithmetic rather than a penalty. We run a maximum of three concurrent projects, which is the only reason the dates we publish are meetable at all, and a week spent waiting on one approval is a week your slot sits idle. It does not compress back into the schedule afterwards.

Project work carries a 30-day bug-fix warranty, and if we miss an agreed delivery date you get a 25% credit toward the next engagement. That is a credit rather than a cash refund, and we would rather write it in this size of type than discover it together later. The credit covers a date we miss. It does not cover a date missed because of merchant-side delay, a defect inside a third-party app, or a platform incident at Shopify or a payment provider.

The guarantee, in full What a build actually involves

Common questions

( 12 )

Where is your team, and what hours do you actually work?: Canada, on Mountain Time, which is UTC−7 in winter and UTC−6 in summer. Our normal working day is 08:00 to 16:30 Mountain, and we open it early, from 06:00, for booked calls with merchants in the UK and Europe. That early window is 13:00 to 16:00 in London and 14:00 to 17:00 in Berlin, Paris and Amsterdam, every business day.
Can I get a live call if I am in Australia or Singapore?: Yes, booked rather than ad hoc. We take scheduled Asia-Pacific calls at 16:00 to 18:00 Mountain, which lands early the next morning in Singapore and mid-morning the next day in eastern Australia — the exact hour shifts with daylight saving on both sides, so the invite carries the real time. Day to day, Asia-Pacific work runs async-first: anything you send during your working day is answered before your next working morning, because our day runs through your night.
How often will I hear from you, and what is in the update?: A written update every week, plus one scheduled call a week on a project or one a month on a retainer. The update contains what shipped with a link to the thing itself, what is in progress, what is blocked on your side with the date we asked, the delivery date restated, hours used, any change raised with its estimate, and what happens next week. If there is nothing to decide, we cancel the call and send the update. We do not hold a call to demonstrate that we are working.
How fast do you reply during an engagement?: Anything blocking a delivery date, same business day. An ordinary question, within one business day. A written estimate for a change, within two business days. A failed daily assertion on a retainer raises its own alert on the run that catches it, with the failing evidence attached — the checks run on a schedule rather than continuously, so that is the run and not the second the failure occurs. Anything arriving after 16:30 Mountain on a Friday is answered Monday: we are not a round-the-clock on-call team and we will not sell you one.
What happens when I ask for something outside the scope?: Work on it stops, it is written down as its own item, and you get an estimate in writing within two business days: hours at $135/hr USD, and what it does to the delivery date. You approve, decline or park it. Only an approved estimate gets scheduled, and it reaches the invoice with your approval attached. You should never read a line item for the first time on an invoice.
Do you charge for fixing your own bugs?: No. Defects in work we delivered are covered by a 30-day bug-fix warranty on project work, and calling one a change order would be a way of charging you to finish the job. An ambiguity in the scope document is not a change either — we wrote the document, so if a line can be read two ways, the reading that does not cost you more is the one that applies. Nor is work needed to meet a target already in the scope, even where it turns out harder than we estimated. A fixed price is fixed, and the estimating risk is ours.
What access do you need to my Shopify store?: A staff account in a named person’s name so your activity log shows who did what, and a custom app with the specific API scopes the work needs. You get a list with one line per scope explaining which check or sync it is for; if we cannot write that line, we do not ask for the scope. We never ask for the account owner login, never for your payment provider or billing, and never for a credential over email or chat. Credentials sit in an encrypted store scoped to the people on your engagement, and you can revoke everything yourself from your admin at any time.
Do you sign a data processing agreement?: Yes, before access is granted rather than after the first invoice. Building or running order plumbing means processing merchant customer data — names, addresses, order contents — so a DPA is signed as part of onboarding. It names what we process, why, where it is held, who else touches it, how long it is kept, and what happens to it when the engagement ends.
What do I own at the end?: Everything we build in your store belongs to you. All code — theme, custom app, middleware, assertion definitions — plus the runbook, the diagrams and the exported exception queue. Ownership is assigned, not licensed, and nothing stops working if you stop paying us. Accounts and repositories are created in your name on day one rather than transferred at the end, so there is nothing sitting in our name to hand back.
Is there a minimum term on a retainer, and how do I leave?: No minimum term, no auto-escalating renewal, no cancellation fee. Retainers run month to month with 30 days written notice either way, and an email is enough — you do not owe us a reason. The notice month is worked rather than coasted, handover happens inside it, and on the last day we deactivate our own access and confirm it in writing. Questions about what we built are answered free for 30 days after that.
What if my next developer has questions after we part ways?: We will get on a call with them, and we offer that whether you left happy or not. We would rather answer questions directly than have someone reverse-engineer our work and quietly rebuild it at your expense. There is also a recorded end-to-end walkthrough in the handover so they can watch it in their own timezone without booking anyone.
What happens to a delivery date if I am slow?: The clock pauses while the work is with you. That is arithmetic rather than a penalty: we run a maximum of three concurrent projects so the dates are meetable in the first place, and a week spent waiting on one approval is a week the slot sits idle. The 25% credit toward the next engagement applies to a date we miss. It does not apply to a date missed because of merchant-side delay, third-party app defects, or a platform incident, and we would rather say that here than put it in a schedule at the back.

Before you talk to anyone

Ask the awkward question now, not in month seven.

If something on this page is missing, vague, or would not survive contact with your lawyer, tell us and we will either fix the page or tell you why we will not. The prices are published in full, and the free Store Integrity Scan reads your public storefront in about ninety seconds without a signup or an app install.

Carrtel Solutions is a Shopify Partner. We build stores on Shopify and the order-and-tracking plumbing behind them, then stay on to prove, every day, that the money still arrives. Our integrity work is where that daily proof comes from.

Two ways in

Store Integrity Scan

Free, self-serve, no signup and no app install. About 90 seconds, and the result is not held behind an email address.

Run the free scan Ask us something on this page

This page last updated August 2026. Hours in Mountain Time; the hourly rate is USD.