Online stores built in code, not assembled from plugins

Both, and the honest answer often is the platform. If your catalogue and workflows fit Shopify or WooCommerce, using one is faster and cheaper and we will say so rather than quote a build. We build custom when the platform fee, the plugin stack or the checkout constraints start costing more than they save - typically with large catalogues where speed and filtering become real problems, with pricing rules a template cannot express, or where the store has to integrate deeply with a warehouse or an ERP. The cost of a platform is rarely the monthly fee; it is the accumulation of plugins bought to work around limitations, each one a security and update dependency, and the checkout you are not allowed to change.

Yes, and this is usually where template stores break down. We integrate the Israeli card clearing provider and the invoicing system you already use - Morning (Green Invoice), Greeninvoice, iCount or Rivhit - so an order produces a payment and a legally valid invoice automatically instead of someone re-keying it at the end of the day. It is worth knowing the failure mode this prevents: when such a connection breaks, nothing on the store looks wrong. Orders keep arriving and no invoices are generated for them, which is typically discovered weeks later by an accountant rather than immediately by a customer. Our maintenance plans include integration upkeep and monitoring that flags a failed hand-off, because providers change their APIs without warning.

You do. The repository, the deployment pipeline, the product and customer data and every service credential are yours, and documentation is handed over with them. There is no licence that stops working if you stop working with us, and no component held in our name, so the store can move to another developer without being rebuilt. This is the practical difference from a hosted platform, where your catalogue and design are yours but the system selling them is not, and where leaving means exporting what the export tool happens to support. Worth checking in writing in any proposal you are weighing: a supplier who will not commit to it on paper has answered a different question than the one you asked.

Yes, and this is the single most important part of a store migration. The work includes a full URL map with permanent 301 redirects from every old address, preserved page structure, headings and metadata, product and customer data migration, end-to-end payment testing in a staging environment, and monitoring of index coverage and rankings after launch. We also switch over during a low-traffic window rather than mid-day. Most ranking loss in migrations comes from URLs quietly changing - a category path that gains a segment, a product slug that changes format - and a redirect map is what prevents it. A store that ranks today represents years of accumulated equity, and it is entirely possible to lose it in an afternoon.

It depends far more on catalogue complexity and integrations than on design. A focused store with a clean catalogue, one payment provider and one invoicing connection runs from about one to three months; multi-market stores with ERP integration, unusual pricing rules or thousands of SKUs take longer. The variables that actually move the date are the product model - variants, options, pricing rules, filters - and the number of external systems involved, since each integration carries its own error handling. We give a schedule after the catalogue and requirements step rather than before it, because a date quoted before anyone has seen the catalogue is a guess. Product photography and copy are, as usual, the most common source of delay.

More than a marketing site does, and the difference is not marginal. Payment and invoicing providers change their APIs, dependencies need security patches, shipping partners change formats, and traffic patterns shift around campaigns and holidays. A store also fails silently in ways a brochure site cannot: a broken checkout or a failed invoice hand-off can run for days while orders keep arriving. Our plans cover uptime and transaction monitoring, updates, backups, integration upkeep and support, so problems surface through an alert rather than through a customer complaint. Pricing is published by plan and response times are written into the agreement, including for stores we did not build ourselves.