Available for projects & agency overflow · Quick reply, from the person who does the work

Building a PrestaShop store

PrestaShop is built for a catalogue with structure. Cross-referenced variants, per-group pricing, multiple carriers, several VAT rates, several storefronts on one database: all of it ships as standard. In exchange it is software you host, you upgrade, and whose security you carry.

Describe my issue Send a message

A store standing on its own server, with a product variant grid, two carriers and price tags.

What is already there, and paid for elsewhere

PrestaShop’s value sits in its product model. A product carries attributes, their combinations become variants stored in ps_product_attribute, each with its own reference, stock, weight and price difference. A clothing catalogue with ten colours and twelve sizes is entered with no extension, and images attach to a colour rather than to the whole product.

Then comes pricing. Customer groups, per-customer or per-quantity specific prices and cart rules cover almost every trade selling case with no development. Then logistics: zones, weight or price bands, multiple carriers, pickup points through a module. Then tax: several rates, per-country rules, ex-VAT or inc-VAT display by group.

Finally multistore: several shopfronts, several domains, one catalogue and one back office. It is the most underrated function at decision time, and the most expensive to rebuild anywhere else.

What PrestaShop does not give away

  • Hosting. An entry-level shared plan, OVH included, will carry a shopfront but not a back office that indexes, regenerates thumbnails and exports. It needs PHP memory, real execution time and a database server not shared with three hundred neighbours.
  • The theme. The default theme is a starting point, not an identity. Either you buy a market theme and accept its choices, or you have one built, and that is the most variable line in the quote.
  • Payment and shipping modules. Most French gateways ship a free official module, but pickup points, labels and returns often mean paid extensions with an annual subscription.
  • Upgrades. Every major version step touches the theme and the modules. It is predictable and it can be costed, but it is never zero.
  • Security. The admin folder must be renamed, the install directory deleted, file permissions tightened and patches applied. Nobody does it for you.
  • Importing an existing catalogue, if you have one. It is almost always the heaviest line, far ahead of appearance.

How I set up a PrestaShop store

  1. Settle the stack before installing

    PrestaShop version, PHP version, database engine, catalogue size expected in three years. An install built on an end-of-life PHP version will have to be redone within the year; better to start on the right side.

  2. Model the catalogue before typing it in

    What is an attribute, what is a feature, what is a separate product. Getting this wrong is the one genuinely expensive mistake: rebuilding variants on a catalogue already entered and already indexed is paid for twice.

  3. Import rather than retype

    A serious catalogue arrives as a file, with references, stock, prices and images. I prepare the import, run it on a small subset, check the variants and the generated URLs, then push the full volume.

  4. Wire payment and shipping early

    These are the two points that depend on third parties. A distance selling contract and a carrier account take weeks to obtain. I connect them in test mode as soon as the accounts exist, not the night before launch.

  5. Lock it down before opening

    Admin folder renamed, install directory removed, debug mode off, automatic backups proven by an actual restore, and legal pages online.

Related pages

Frequently asked questions

Which PrestaShop version should a new store use?
The latest stable branch, never a version out of support. Opening today on an old 1.6 or 1.7 means scheduling a paid migration in the short term, with modules that will not follow. The only defensible argument for an older version would be an essential module that exists nowhere else — and then you must check its publisher is still active.
Is shared hosting enough to start?
For a low-traffic launch, often yes, provided you check three things: the memory allocated to PHP, the maximum execution time, and whether scheduled tasks can run. The back office saturates first, not the shopfront. A thumbnail regeneration or a catalogue import is what exposes the limits.
Buy a theme or have one built?
A market theme costs tens to hundreds of pounds and imposes its choices; a built theme costs several days. The real criterion is not aesthetic: it is how many pages you will need to drag out of its template. If you already know the product page has to be rewritten, the saving on a bought theme is fictional.
How many products can PrestaShop handle?
Product count is the wrong unit: what carries the weight is variant count and the number of active filters. A few thousand references sit comfortably on a decent server; the same catalogue with dozens of variants per product and faceted navigation open on every attribute needs indexing and caching.
Can I build the store myself and call you afterwards?
Yes, and it happens often. The point to watch is catalogue modelling: if variants were created as separate products, fixing it later touches URLs, and therefore rankings. Have that reviewed before typing in a thousand records — half a day that saves several.

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

version
besoin
etat
theme (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.