Something already has a date on it: a booked drop, peak season, or orders failing at checkout. Tell us which, and we will say what we would build and what it costs.
A senior software engineer replies, usually within a working day, and either scopes the build or says we are not right for it.
Buying your first store
You are signing personally, with no software engineer of your own to judge the work.
Already running one
You have a storefront and a release process, and outsiders would be working near both.
Taken from public reviews of builds that went badly.
You cannot judge the work yourself
One merchant, after paying for a build: highly disappointed, and could not put into words the lack of quality. Another lost more than four thousand dollars and got a low-quality store before communication stopped. Without a software engineer on your side, every reassurance sounds the same.
You may not own what you paid for
The builder stops replying, or the relationship sours and somebody locks you out of the admin. This now comes up before signing, word for word: if one of us needs to part ways, what process makes that smooth.
A slow checkout loses orders like a broken one
Tickets say checkout is broken. Usually it works and is just slow enough that people leave. Nobody notices until the sales number moves, and by then the cause is three releases back, in an extension nobody audited.
If it goes down on the day, you explain it
The drop is booked, the deposits are taken and the supplier terms are set. When the store is down there is nobody else in the room to answer for it.
Every one of those is decided before the build starts, by who owns what and who answers when it breaks. All of it can be settled in writing now.
What the measurements say
Deloitte and Google, 37 brands over four weeks
Deloitte and Google, same study and brands
Failed payments outrank every other operational problem
Both movement figures describe the brands in that study and are quoted here as a category signal. Neither is a result we produced and neither is a forecast for your store. What a tenth of a second costs is decided by what the page loads, in what order, and how much work happens before a shopper can act, which are build decisions rather than design or campaign ones.
| Item | Published P1 response |
|---|---|
| Web Powerhouse | 0.25 h |
| CTI Digital | 0.5 h |
| Just After Midnight | 0.5 h |
| Adobe Commerce (Enterprise) | 0.5 h |
| WolfSellers (Enterprise) | 0.5 h |
| 1Digital Agency | 1 h |
| Pinnaxcle | 2 h |
| WebDesk Solution | 4 h |
| MageMontreal | 24 h |
Every one of these firms markets support. The commitments behind that word run from 15 minutes to 24 business hours, and two more firms in the same survey publish no numbers at all. So 'do you offer support' is not a question worth asking.
Three things to take to any vendor, including us. Ask what P1 means in their contract, because if it does not say storefront down, checkout broken or payment failing, it does not cover the thing you are afraid of. Ask when the clock starts, because a 30-day stabilisation clause moves the whole promise past your launch. Ask who carries the pager on a Saturday in November, and get the name of the rotation. Two firms in the same survey, IWD Agency and Just After Midnight, publish no severity tiers at all, so there is nothing to hold them to.
Work with us if
You are buying a store to be built or rebuilt, and you want the terms of the build in writing before you sign
You already run a storefront and need capacity that will work inside your repository, your CI and your release process
You want the code, the cloud accounts and the data to be yours from day one, with an exit path written down at the start
You would rather hear a stated limit than an unqualified guarantee
Do not work with us if
You need a severity-tiered incident SLA with a weekend pager today, which we publish nowhere and will not write on a page to win an enquiry
You need a compliance certificate issued by us; we work inside regulated engagements with quarterly security audits, and sign-in handled by your identity provider so a leaver loses access everywhere at once (OAuth and SSO), but we do not certify against frameworks ourselves
You want the cheapest possible fixed-price store, where a template build from a platform partner will beat us and probably should
A store of this kind typically runs 10 to 16 weeks from start to launch, depending on scope.
You talk to a senior software engineer, not a salesperson. You leave with a scope taking shape, or with us saying the bench is not there for this.
Before any code exists, the requirements are written back to you in plain English. Shipping display, guest checkout, wallet payments and returns get decided at this stage.
Work happens in your Git, your cloud and your storage, or we provision them and hand you the keys. Daily standups, sprint reviews, a demo every two weeks.
Launch is a date, not an ending. Post-launch continues as an annual maintenance contract or a lean arrangement, with new features on the same change-note process.
01
Architecture decisions
Not a diagram made for the pitch, but the document your team reads in eighteen months to find out why checkout works this way.
What you receive
A technical requirement specification recording the architecture decisions, and the reason each one was taken rather than the alternative.
02
Every merge
Every merge, not just the important ones. If you have software engineers, this is the surface they judge us on.
What you receive
A pull request reviewed by a senior software engineer, on a GitFlow branch, with unit and integration tests, gated by CI/CD before it merges.
03
The repository itself
Yours from day 1. There is no version of this where the thing you paid for lives somewhere you cannot reach.
What you receive
Every line of code is yours from the start, in your Git, your cloud and your storage, or ones we provision and hand over.
04
The storefront
Accessibility here is a build standard we hold rather than an add-on you buy, which also happens to be the cheapest legal position to be in.
What you receive
A frontend that meets WCAG 2.2 by default and is fast on every device, with higher compliance targets on request.
If this is already the shape of what you need, the form takes a minute.
The left column is written down somewhere you can check. The right is a limit you hear now, not in month three.
| The term | Committed in writing | Not committed |
|---|---|---|
| Who owns the code | Committed in writingYours from day one, including custom work. | Not committedWe retain no licence and no reusable-component carve-out, and make no claim on what we wrote for you. |
| Exit | Committed in writingA written handover process agreed at the start. | Not committedDocumentation, credentials, and code another team can work from. Ask any vendor for theirs before you sign. |
| Availability | Committed in writingPipelines targeting 98 to 99 percent uptime under normal operating conditions. | Not committedCloud-provider outages sit outside that. We say so rather than implying we control them. |
| Incident SLA | Committed in writingWe publish none. | Not committedIf you need severity tiers and a weekend pager contractually, we are weaker than a platform support specialist on exactly that. The chart above tells you what to demand from whoever you buy it from. |
| What it costs | Committed in writingAn estimate that is real once you sign off. | Not committedA number before we understand the catalog, the payments and the integrations. Anything quoted earlier is a guess. |
| How we engage | Committed in writingA dedicated team, sprint-based work, or a scoped project. | Not committedWork starting before the full specification is approved. That sequence is what keeps the estimate from moving. |
| Scope changes | Committed in writingA change note stating time, effort and cost, approved by you in a meeting and in writing before the work starts. | Not committedNothing in the build moves on a re-scope you have not accepted. |
| Warning time | Committed in writingWhen something changes you hear it three weeks early, not three days late, in the week the risk appears. | Not committedWe do not promise there will be no surprises. |
| The team | Committed in writingNamed software engineers you meet, not a sales team. | Not committedWe say whether the people exist today or whether we would recruit for your role. Both answers are honest; only one is fast. |
The closest commerce work in our record
Anonymous by policy. The class of company, and what actually moved.
We transformed a lagging frontend into a high-performance shopping experience with SSR, state management, and memory-optimized rendering.
Faster carts, smoother mobile, and onboarding across 4 cities.
We say so on the first call If the exact skills your store needs are not on our bench this quarter, we tell you. Then we either recruit specifically for the role or tell you to go elsewhere.
We do not relabel whoever is free What we do not do is put available people on your store and describe them as specialists in a stack they have not shipped.
Tell us the catalog, the payments and the deadline. You get the engagement shape that fits and what drives the number.
Taken from published agency-selection guides and merchant threads, in the wording they were asked in. Two answers are worse than you want.
One scoped conversation, two good outcomes, both named before you commit to anything.
Tell us what has a date on it and what the current store does badly. One of two things happens on that call: we scope the build with you, or we tell you the bench is not there today and what to ask the next vendor.
A senior software engineer reads what you send and answers it. Not a form router, not a follow-up sequence, and not a salesperson who books you in with someone technical three days later.
Every line of code is yours from day 1, whether or not we work together after the call.
