A picture of a store you admire does not reveal where its functions were built. Changing a product card's color may be a setting or styling task, while sending an order to an external warehouse requires data flow, permissions and operation. Asking a company for “Salla programming” is therefore insufficient without explaining what the buyer sees and what must happen afterward.
Distinguish an available setting, theme customization, an existing app and, when needed and verified, custom app development. These are not quality levels ranked from cheapest to best; they are different ways to address a need. A simple setting may meet your purpose, while a solution that looks simple on screen may hide an important operational dependency.
Separate the visible request from its operational result
In a fictional homeware store, the merchant wants consistent product cards, a preparation message and approved orders sent to warehouse software. This is not an actual implementation. Combining these requests under “interface changes” makes comparison misleading because each requires different acceptance evidence.
Ask where the preparation message comes from: fixed text, product-specific information or a warehouse response? Then ask where it is stored and who can update it. Its appearance alone does not establish whether the solution works when data changes or an employee needs to review the order in administration.
Four request cards to send the supplier
- Appearance: The page, element, requested difference and a permitted reference image, with the phones and languages to test.
- Interaction: What the visitor does, the visible result and whether it persists after refreshing or using another device.
- Data: Fields, their source and who reads or changes them, including whether staff need the result outside the storefront.
- Operation: The initiating event, external party, failure state, person monitoring it and evidence of successful processing.
The supplier should state a proposed method for each card and evidence that it is available for your store's circumstances. If an experiment is needed, define its question, output and limits. An app title or technology name should not replace an explanation of how the requested result will be achieved.
A theme does more than change colors, but does not authorize every function
Twilight documents color, font and customization settings through CSS and JavaScript. This helps identify requirements concerning presentation or interaction within the theme. It does not establish that your theme exposes every modification point, or that interface code can change operational data or bypass the platform's approved restrictions.
Request a preview in an appropriate copy before applying changes to the live store, distinguishing theme settings from additions. Review how checks will be repeated when the theme or product content changes. You do not need to memorize filenames; you need to know who maintains the change and how the previous state can be restored if it fails.
When should apps enter the discussion?
Salla documentation describes public and private apps for merchant integrations and ties store-data access to authorization and scopes. A Salla app here is a platform extension, not necessarily a mobile app customers install. Clarify the term in your request so you do not compare different services under the same name.
If the supplier suggests an existing app, request a demonstration of the task, failure cases, subscription limits and support. For a custom app, request verification of the required interfaces and scopes, along with ownership of operation, data retention and integration maintenance. An API's existence does not mean every request is possible or platform approval is guaranteed.
Accepting the example requires two different tests
For appearance, inspect a long product name, a differently proportioned image and an out-of-stock state on a phone. For the proposed warehouse integration, use a synthetic order and an agreed test method, follow its reference through both systems and inspect what appears when sending fails. If processing remains manual, staff should know where to find it and who approves closure.
Separate the theme modification fee from app setup or development, operation and any external service. Name the settings, documentation and appropriate access you will receive, and what requires renewal or follow-up. The final picture is not evidence that the function happening outside it is complete.
Review Salla store design scope for content and setup readiness. When requesting Salla implementation from Nextwave, send the four cards to establish whether you are buying an appearance change or an operational result requiring additional work.
References defining the limits
Documentation on theme data, app creation and authorization was opened on 4 November 2026. The cards and example are editorial material without eligibility, pricing or supplier accreditation guarantees. AI tools assisted preparation, with content and translation review.
