How we work
How we work, from first call to long after launch
The page to read before you sign anything: how an e-commerce project runs with us, what we need from you, and the things we will refuse to do.
The process
Seven stages, each ending in something you can read or test
-
01
Understand the business first
We start with how you trade: catalogue, pricing, order flow, integrations and the team who run the store. For an existing store we read the code as well as the brief.
- Discovery notes
- Risks and open questions
-
02
A written scope and a fixed price
Discovery ends in a document that says what will be built, what will not, and what it costs. You agree it before build work starts. Later changes are written down and priced before anyone acts on them.
- Written scope
- Fixed price
-
03
Design and architecture together
Page designs and the technical plan are drawn up side by side, so nothing is designed that cannot be built well.
- Page designs
- Technical plan
-
04
Short cycles on a staging site
Work lands on a staging site, a private copy of the store, in short cycles. Regular demos show what has changed, and you test it with real products while changes are still cheap.
- Staging site
- Regular demos
-
05
QA before anything goes live
We test on the browsers and devices your customers use, check accessibility and page speed, and run payment and order flows end to end, from basket to confirmation email and back-office hand-off.
- Test results
- Sign-off checklist
-
06
A runbook and a way back
Go-live follows a written runbook: every step, who does it and how it is checked. It includes a rollback path, so a launch that goes wrong can be reversed.
- Launch runbook
- Rollback plan
-
07
Looking after the store afterwards
We watch the store closely after launch and fix what real traffic reveals. After that, patching and improvements can continue on a monthly retainer.
- Post-launch checks
- Support plan
Communication
You talk to the people doing the work
There is no account-management layer here. The developer who scopes your project is the one who builds it, and the one who answers when you have a question.
How often we meet and how updates reach you are agreed at the start.
-
Direct access to developers
Questions go to someone who knows your code, not to a go-between.
-
A shared issue tracker
Every task, bug and decision sits in one tracker you can see, so status never has to be chased.
-
Written updates
Regular written updates say what was finished, what comes next and anything at risk.
Engagement models
Three ways to work with us
We do not publish prices, because an honest figure depends on your store. You have the number in writing before any work starts.
-
Fixed-scope project
For defined work such as a new build, a migration or an upgrade. A written scope and a fixed price, agreed after discovery.
-
Monthly retainer
For ongoing support and steady improvement: security patches, fixes and small features, with an agreed number of hours each month and priorities you set.
-
Audit or second opinion
An independent review of an existing store, a plan or a quote, written up in plain English with priorities. Yours to use whether or not you go on to work with us.
Both sides of the table
What we need from you, and what you keep
What we need from you
- One decision-maker with the authority to sign things off
- Access to the store, hosting, repositories and the third-party systems involved
- Content, product data and brand assets, or agreement on who produces them
- Timely feedback on designs and staging work, so the schedule holds
What you own
- Repositories in your name, with the full history
- Hosting and platform accounts in your name, with us added as users
- Documentation of how the store is built, deployed and configured
- A clean handover if you ever move on, with nothing held back
Ground rules
What we will say no to
Each of these saves a little time now and costs the merchant far more later. When we say no, we explain why and set out what we would do instead.
-
Core hacks
We do not edit Magento core files or work around a platform in ways the next upgrade will undo.
-
Launching untested
We will not put a store live before payment and order-flow testing is complete, whatever the date on the calendar.
-
Hiding problems
If we find a fault, including one we caused, you are told.
Questions
Questions about working with us
How does SoftAware Commerce price a project?
Defined projects such as a new build, a migration or an upgrade are quoted as a fixed scope and price after discovery. Ongoing support and improvement work runs on a monthly retainer with an agreed number of hours. In both cases the figure is confirmed in writing before any work starts.
What happens if the scope changes during a project?
Scope changes are normal and are handled in writing. When a new requirement appears, we describe the change, say what it does to the price and the schedule, and wait for your decision before acting on it. Nothing is added to the project that you have not approved first.
How do you test an e-commerce site before launch?
Pre-launch testing covers the browsers and devices your customers use, accessibility, page speed and the full order flow: basket, checkout, payment, confirmation emails, refunds and the hand-off to back-office systems. Launch itself follows a written runbook with a rollback path, so a problem on the day can be reversed.
Who owns the code when the project ends?
You do. Repositories, hosting and platform accounts are in your name, and we work inside them as invited users. The store is documented well enough for another developer to take over, so if you ever change agency you take everything with you.
Can we start with something smaller than a full project?
Yes. An audit or second opinion is a sensible first step if you have inherited a store, are unsure about a platform decision or want a plan checked. You get a written report in plain English with priorities, and it is yours whether or not you go on to work with us.