A Salla store is ready to launch when a customer can select the correct product and pay the expected amount, and your team can fulfil, ship and, when necessary, cancel that order. An attractive homepage is not sufficient evidence. You need dependable catalogue data, tested payment and delivery settings, business-owned accounts and a record of unresolved issues.
This guide is for Saudi businesses launching a store or rebuilding an existing one. It defines the work and its acceptance criteria rather than forecasting sales or planning advertising. Use it when commissioning Salla store development and launch, or to review a delivery already in progress.
1. Define the scope before choosing a theme
Write down what you sell and how orders reach customers. Product count alone is a weak estimate of the work: one product with many sizes and colours can require more checking than several simple products.
Agree on:
- Product types, customer-facing categories and anything excluded from the first release.
- Options that affect stock or price, such as size or volume.
- Delivery areas, the fulfilment location and responsibility for updating quantities.
- Required payment methods and the actual activation status of each.
- Languages, and who approves descriptions and translations.
- The account owner, implementer permissions and final approver.
Separate implementation fees from platform subscriptions, themes, apps, and payment or delivery provider charges. Replace “connect all services” with named providers, defined connections and responsibility for supplying account details. If your team has conflicting answers, product discovery and requirements can resolve the scope before those disagreements become development changes.
2. Check native features before commissioning custom work
Salla documents product quantities and options, including size and colour. A size selector is therefore not automatically a custom-development requirement. Start with the platform’s existing capabilities and identify what is genuinely missing. Source: Salla’s physical-product guide, in Arabic.
Its current payment guide says Basic supports bank transfer and cash on delivery, while electronic payment methods require a paid plan. A payment logo in a design is not proof that the method is activated. Check the plan, account status and live configuration during implementation. Source: Salla payment methods, in Arabic.
| Requested outcome | Check before committing |
|---|---|
| Different colours, typography or spacing | Theme settings and whether additional styling is needed |
| Separate stock for product variants | Complete variant data and its behaviour in an order |
| A specific payment method | Plan availability, account eligibility, activation and provider conditions |
| External stock-system connection | Suitable integration, synchronisation direction and failure handling |
| An unusual purchasing step | Platform or app support, or whether the business process must change |
Salla provides CSS-based storefront styling. That does not establish that every backend rule or checkout step can be changed freely. Ask for evidence that the particular requirement is feasible before accepting a custom-build quote. Source: Salla CSS customisation guide, in Arabic.
3. Prepare a catalogue that does not require guesswork
Give every product a stable reference, understandable name, associated images, approved description, price, quantity and shipping weight where relevant. Distinguish a product from its variants: showing a blue item does not establish how many blue items are in stock.
Add a readiness field: approved, incomplete or excluded for now. Avoid publishing temporary descriptions and assuming someone will replace them later. Check a sample containing difficult cases, such as a higher-priced option and an unavailable size, before applying an import to the full catalogue.
When information is scattered across supplier files and team messages, catalogue preparation is a separate deliverable. Product catalogue design and localisation can help structure approved material before store setup. Clarify whether the scope includes data organisation alone or also writing, editing and translation. These are different commitments.
4. Test payment and delivery rules together
For each delivery area, record the available carrier, displayed charge, exceptions and compatible payment choices. Include an address outside your coverage. The customer should receive an understandable outcome rather than discovering an unexplained dead end after entering their details.
Salla’s shipping settings include cash-on-delivery controls. Automatic order-status updates through shipping companies apply to supported carriers when the relevant option is enabled. Test the carrier you actually use rather than assuming all integrations behave identically. Source: Salla shipping settings, in Arabic.
Reconcile amounts across the product page, cart, order and payment record. Have the appropriate person in your business approve tax and invoice settings rather than asking an implementer to infer your business status. Prepare contact, shipping, returns and privacy pages that reflect your actual operation, and review the official requirements applicable to your activity.
5. Worked example: a gift shop in Khobar
This is a hypothetical example, not a LAB client project. A shop sells mugs in three colours and gift boxes, with different delivery arrangements across its service areas. The owner initially requests “a new design and product uploads.”
Writing acceptance criteria reveals three operational requirements: blue mugs are unavailable; the selected delivery service does not cover every address; and a gift message must reach the packing team. The scope becomes more useful: configure stock and options, verify shipping coverage, and select a supported way to collect the gift message and expose it to fulfilment staff.
| Test case | Required outcome |
|---|---|
| Select an unavailable colour | The order cannot violate the agreed stock policy |
| Select an available colour | The correct colour appears in order details |
| Enter a covered address | The approved delivery option and charge appear |
| Enter an uncovered address | The store does not promise an unavailable delivery service |
| Enter a gift message | The packing team can see it in the agreed place |
| Cancel a test order | Order state, money and stock follow the approved procedure |
Use testing methods permitted by the platform and provider. If a real transaction is necessary, agree the amount, fees and cancellation or refund procedure with the owner first. Prevent an accidental shipment. Retain test identifiers without exposing customer information.
6. Additional checks for an existing store
Inventory what must survive: products, URLs, apps, custom code, shipping settings and operating procedures. Record the current configuration and available recovery options before changing it. A product export is not a complete restorable backup of every platform setting.
If category names or URLs change, map old addresses to their intended destinations and verify the platform’s available redirect options. Include the migration in an SEO review; neither changing a theme nor creating redirects automatically guarantees a ranking improvement or preservation.
Decide how to handle orders received during the work and who coordinates simultaneous team changes. Do not overwrite current data with an older test copy simply because that copy was used for approval.
7. Acceptance and handover checklist
- [ ] Approve a representative sample of products, options and prices, then reconcile the complete import.
- [ ] Check search, categories and product pages on mobile in Arabic.
- [ ] Test agreed payment and delivery combinations.
- [ ] Confirm correct order details and necessary notifications reach the fulfilment team.
- [ ] Test the cancellation or refund path included in scope and record any fees.
- [ ] Deliver a results log showing each case, outcome, evidence and remaining owner.
- [ ] Keep account, domain and subscription ownership with the business.
- [ ] Have a staff member add a product, change stock and process an order without live coaching.
These checks can form a scoped software quality assurance engagement. Acceptance means completing the agreed tasks, not receiving a storefront tour or an unsupported statement that everything works.
Common handover mistakes
Avoid buying apps before establishing a need, using photographs as a substitute for variant data, testing successful payment but ignoring cancellation, mixing recurring supplier charges with implementation fees, and launching before assigning responsibility for new orders. Account ownership should be settled at the beginning, not on the final day.
Frequently asked questions
Do I need a developer for every Salla setting?
No. Many catalogue, appearance, payment and shipping settings are built in. Specialist assistance should add value through scope definition, data preparation, genuine gap resolution, testing and a usable handover.
Is the most expensive plan always necessary?
No. Match requirements to the capabilities available when purchasing. Some requirements need a paid plan, but that is not a reason to buy the highest tier without a specific need.
Does changing the theme count as rebuilding the store?
Not necessarily. It may be a storefront refresh or part of a broader project involving catalogue, apps and operations. Define what changes and what stays before approving the proposal.
When is the store ready for advertising?
When critical purchasing and operational cases pass, launch-blocking defects are resolved, and the team knows how to manage incoming orders. Operational readiness is a starting condition, not a sales guarantee.
Your next step
Prepare a representative product sample, delivery areas, required payment methods and known problems with the current store, if any. Use these to request a defined launch scope, handover deliverables and acceptance criteria rather than a generic “professional store.”
Sources
Reviewed on 26 October 2026. Salla features, dashboard labels and plan availability may change.
