Systems, Stores and Websites — Technical Decisions You Pay for for Years

Always start by looking for something off the shelf, and build custom only when that search fails. A ready system is cheaper, faster, and already tested by thousands of users before you. Custom becomes justified in three cases: when your way of working is itself your competitive advantage and you will not reshape it to fit a product, when your subscription spend exceeds the build cost over three years, or when nothing ready covers your field at all.

WordPress makes sense for a content site and blog updated daily by a non-technical team, provided you keep up with its security updates, because plugins are the most common breach route. Custom code on a modern framework such as Next.js is better when speed and visibility in search and AI answers are priorities, or when the site carries its own business logic. The common middle path: a front end built in modern code with content managed from a separate system.

Salla and Zid are built for the Saudi market: full Arabic support and ready integration with e-invoicing, local payment gateways, and local couriers — which saves weeks of work. Shopify is stronger globally with a wider app ecosystem but needs extra effort for local compliance. A custom store is justified only by pricing or bundling logic no platform supports. Start on a local platform and move when you actually need to.

For sites that must appear in Google and in AI answers, Next.js with the App Router is the practical choice: it renders pages on the server so crawlers read them immediately, generates fast static pages for stable content, and optimises images automatically. But the rule that matters more than the technology name: choose what whoever maintains your site in two years can actually work with. The best framework nobody can maintain is the worst choice.

A responsive website is enough when customer contact is occasional — buying or enquiring a few times a year. An app is justified when use recurs at least weekly, or when you need device capabilities such as the camera, notifications, or offline operation. The middle option that saves a great deal: a progressive web app that installs to the home screen and sends notifications without the cost of building two native versions and shipping them to stores.

Do not build from scratch before running a ready CRM for three months — the trial reveals what you actually need instead of what you think you need. If you decide to build, start with four elements only: the customer record, the interaction log, the deal stage, and the next reminder. Everything else gets added later on real demand. Custom CRMs usually fail because they were built comprehensive, so the team refused to enter data into them.

Move in stages, not all at once. Start with the sheet more than one person uses simultaneously, because that is the source of the biggest errors: conflicting copies and rows deleted by accident. Clean the data before migrating — migration copies the mess, it does not fix it. And keep the spreadsheet running in parallel for a full month after launch. Migrating every sheet in one go is the single biggest reason teams drift back to Excel within weeks.

The integration goes through stages: registering the system with the authority and obtaining a certificate, generating the invoice in the approved format with a QR code and electronic signature, then submitting it for clearance or reporting depending on the invoice type. In practice it takes one to three weeks depending on your system’s readiness. Do not go live before passing the full sandbox environment, and always check the requirements published on the authority’s site, as they are updated in phases.

Through a payment gateway serving the Saudi market. Opening the account requires a commercial registration and a bank account in the business name, and approval usually takes days to two weeks. Technically, never store card data in your system — it passes directly to the gateway, which is what keeps you outside the heavy PCI obligations. Compare gateways on the percentage per transaction plus the fixed fee, not the percentage alone, because the difference shows clearly on small orders.

Four conditions: a separate URL per language such as /ar and /en rather than a JavaScript toggle on one URL, hreflang tags linking the two versions, correct page direction with a design that genuinely works right-to-left rather than merely mirrored text, and human translation for marketing content at minimum. The most expensive mistake is switching language on the same URL: you lose half your pages from indexing, because the search engine only ever sees one version.

Four causes cover most cases: images uploaded at original size with no compression or resizing, many plugins each loading its own files, crowded shared hosting, and external fonts and scripts delaying first paint. Start with Google’s free PageSpeed Insights report and work on only the top two items — usually images and scripts — because they deliver most of the improvement for the least effort.

Six measures cover most real risk: update the platform and plugins as soon as security patches ship, enable two-factor authentication on every admin account, give each user the least permission that suffices, enable automatic backups and actually test a restore once, serve HTTPS on every page, and rate-limit repeated login attempts. Outdated unpatched plugins are the number one breach route on small sites.

Not that the design shrinks to fit the screen, but that it is rearranged to fit the use: buttons large enough for a thumb, text readable without zooming, tables that scroll horizontally instead of pushing the whole page sideways, and menus reachable one-handed. Test it yourself on your phone: if you have to zoom even once to read text or hit a button, the site is not responsive whatever you were told.

Yes if content changes more than once a month — prices, products, news, team. Without one you are hostage to the developer’s availability to change a word. You do not need one if the site is a static brochure updated once or twice a year; there the build cost never pays back. The middle decision: a simple panel covering only what genuinely changes, not a comprehensive version managing every element on the page.

In a fixed order: copy the whole site to the new host and test it there on a temporary URL, lower the domain record’s time-to-live a day before the switch so the change propagates quickly, freeze edits on the old site during the move, change the record, then keep the old hosting live for a full week. The common mistake is cancelling the old host immediately — some visitors stay routed to it for hours.

Shared means your site shares a server with hundreds of others, so your speed suffers from their traffic; it is cheaper and fine for a brochure site with modest visits. Cloud allocates resources and scales automatically under load, which is the right choice for a store or a system. The practical rule: if an hour of downtime costs you sales or credibility, the price difference between them is far cheaper than that hour.

Three rules: keep at least three copies, in two different locations, with one of them off the hosting itself — because a copy stored on the server that failed is no help. More important than all of it: actually test a restore at least once. Most people who discover their backups are corrupt discover it on the day they need them. Put that test in the calendar as an annual appointment.

Through four elements in this order: a sound technical base — speed, correct indexing, a clear link structure; a dedicated page per search intent rather than one page trying to cover everything; content answering the question in the first paragraph rather than after a thousand words; then external signals from real sites. Expect three to six months for substantial results. Anyone promising the first page in two weeks is either targeting a term nobody searches or using methods Google penalises.

Five signs: it does not work decently on mobile, the platform it was built on no longer receives security updates, every small change breaks something else, you cannot update content yourself, or it does not appear in search results despite existing for years. One sign is fixable. Three or more mean every riyal spent patching is deferring an inevitable decision at a higher cost.

Booking needs three elements: a calendar reflecting genuine availability, prevention of double-booking the same slot, and reminders before the appointment. Recurring subscriptions need a gateway supporting scheduled charges, clear handling of renewal failures, and a page where the customer can cancel themselves. The case always forgotten in subscriptions is failed payment: without an automatic follow-up path for it, you lose customers who never intended to leave.

A content management system that stores content and serves it through an API without dictating how the site looks. Its benefit is that the same content serves the website, the app, and any other channel without duplication. You need one if you have more than one surface showing the same content, or want full design freedom while keeping editing easy for a non-technical team. For a single simple site, it is added complexity with no clear return.

Prepare at least two weeks ahead: publish the offers page on its own permanent URL early so it is indexed before the season rather than after, enable caching and a content delivery network, load-test the site at roughly three times your expected peak, and prepare an automatic WhatsApp reply because message volume multiplies. A page published on the day of the occasion itself usually is not indexed in time.

Most couriers operating in the Saudi market provide an API that creates a waybill automatically on order confirmation, returns a tracking number, and updates shipment status. Ask the courier for its API documentation and a sandbox account before signing. The most important practical point: calculate shipping in the cart from the real city and weight, because a flat fee loses you money on distant orders and loses you sales on nearby ones.

Do not test on your own device alone — that is the most common reason faults are discovered by customers. Test on at least four cases: a recent iPhone, a mid-range Android rather than a flagship, a tablet, and a large desktop screen. Add a test on a slow network, and with the system font size increased. A mid-range device on a slow network is the truest test, because it represents the majority of your actual visitors.

Start by describing the process, not the system. Write on one page: what happens today step by step, where time is lost or errors occur, and who uses the system and with what permissions. From that page a small first version is derived that launches in weeks rather than months. Send the page to WhatsApp wa.me/966573784181 and you get a free first read on whether a ready solution would already cover you before you spend on a custom build.