Technical questions, answered in writing

A custom website costs between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on language count and complexity, delivered in 7 days. Platforms start from 15,000$4,084€3,597, with an MVP in 2 to 6 weeks; marketplaces are priced per project. We publish the method rather than a fixed price, because scope is what moves the number and we remove anything that will not earn its cost.

No. Both carry a plugin ecosystem that is the single largest source of security incidents and performance loss on the web. We build custom, which means no plugin conflicts, no forced updates, no monthly platform fee and nothing on the page we did not write. For a simple brochure site a template may genuinely be cheaper, and we will tell you so.

Yes: mobile apps, Telegram mini apps, browser extensions and native desktop apps. Everything we build is mobile-first and installs to a phone home screen without an app store, which covers most requirements at a fraction of native cost. Where a project needs device features such as offline use, background location or push at scale, we build native for iOS, Android and Huawei.

Yes, under strict protocols: zero trust, a person in the loop, and an answer only when it is verified. The AI is our own, running on our servers, or a model reached through an API. The client decides where AI works in the project and can turn it off. We do not train AI on client data.

Full ownership of code, servers, domains and data. Security headers, encryption in transit and at rest, and no third-party scripts on the render path. Structured data so search engines and AI assistants read the site correctly. Automatic backups with tested restores. These are defaults, not upgrades, and a 5,500$1,500€1,321 website gets the same treatment as a platform.

A working MVP takes 2 to 6 weeks for most platforms and 1 to 2 months for a marketplace, with 3 months to a version ready for real commercial testing. Websites are much faster: 7 days, 10 days with an integration. Enterprise and complex multi-site builds are scoped after review.

Yes, and it often works well. We can take a defined component, an integration or the infrastructure layer while your team handles the rest. What we will not do is take responsibility for code we did not write, so the boundary gets agreed in writing at the start.

Either, under the same protocols. Our own AI runs on servers we operate. Where an outside model fits the job, it is reached through an API. The rules do not change with the model: zero trust, a person in the loop, and an answer only when it is verified. TEZZ AI, our own system, is in training and is reached by API only.

No, Gigagrams does not train AI on client data. A model built for a client belongs to that client alone. It is never trained on another client's data. The client also decides where AI works in their project and can turn it off. We run our own systems by the same rule.

It asks a clarifying question instead of answering. Our AI gives an answer only when the answer is verified, and it never guesses. People confirm each action, so a person stays in the loop. The same rule holds whether the model is our own or reached through an API.

AI work is built against ISO/IEC 42001 controls, self-assessed. Systems are built to SOC 2 and ISO/IEC 27001 controls, and each client certifies its own system; Gigagrams does not certify. Our security practice is self-assessed at NIST CSF Tier 3 (Repeatable), with Tier 4 (Adaptive) as the target. We never claim that a system is safe from all attacks.

Making two systems that were never designed to talk to each other exchange data reliably. An API, Application Programming Interface, is the defined way one system lets another request or send it data. Integration is building the connection that uses it correctly, including what happens when it fails.

Most systems were not built expecting to be connected to what they are now being connected to. Field names do not match, one system's "done" is another's "closed", and one side goes down occasionally without warning. The integration has to handle all of that without silently losing or duplicating data.

A properly built integration retries, logs the failure specifically, and alerts someone rather than silently dropping the data. When a connected system changes its API without warning, which happens, the integration is built to fail loudly rather than quietly feed bad data downstream.

Scoped case by case. Two systems with well-documented, modern APIs is a different job from ten legacy systems with undocumented protocols, and the honest answer depends on which one you actually have. Third-party service costs are billed at cost, never marked up.

Gigagrams builds four kinds of app: mobile apps, Telegram mini apps, browser extensions and native desktop apps. Mobile apps for iOS, Android and Huawei are work we have done. Each app is built to the same standards and ownership terms as everything else we build, and you own the code of each one from day one.

Most projects do not need a store app. Everything we build is mobile-first and installs to a phone home screen without an app store. Native is used where a device feature requires it, such as offline use, background location or push at scale. Which one a project needs is scoped during the technical audit, not assumed from the start.

A Telegram mini app is a full app that opens inside Telegram, where your customers already write to you. There is nothing to install and no app store. It is a different build from a Telegram bot, which works in the chat through messages and buttons. We build bots too, on Telegram’s own Bot API.

A browser extension makes sense for a tool your team uses on the pages and systems they already work in. A native desktop app makes sense for work that needs the whole computer: local files, long sessions and several screens at once. Both start from your answers, one question at a time, before anything is built.

Rules that move work forward without a person triggering each step: an approval routed to the right person automatically, data kept in sync between two systems that were never designed to talk to each other, a report that lands in an inbox on schedule instead of being compiled by hand.

At the handoff. A form submitted and forgotten, an approval sitting in someone's inbox for three days, a number retyped from one system into another because they do not share data. Automation removes the handoff, not the decision.

No. It routes the approval to the right person automatically and reminds them if it sits too long, the same principle of minimum human input applied elsewhere: removing repetitive coordination, not removing judgment from a decision that needs it.

From 15,000$4,084€3,597, depending on how many systems are involved and how much of the workflow is being automated. An MVP typically takes two to six weeks. Third-party services are billed at cost, never marked up.

Availability that cannot be double-booked, deposits collected at the time of booking, a defined policy for no-shows, and reminders sent automatically so a client does not forget. A calendar shows time slots. A booking system protects the business when someone does not show up for one.

A slot is held the moment someone starts booking it, not only once payment clears, so two people cannot both claim the same appointment while the second one is still filling in their details.

Whatever policy the business sets, a deposit forfeited, a fee charged, or a flag on the client record, applied automatically rather than decided case by case by whoever is at the front desk that day.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on complexity, number of resources being booked, and payment integration. Delivered in 7 days, 10 days with the payment integration wired in. Third-party payment services are billed at cost, never marked up.

Several sites or systems shown on one screen: uptime, traffic, errors, cost and security, instead of a separate dashboard for each tool. It exists so a problem on any one system is visible from the same place as everything else, rather than found by checking five different logins.

With one site, one dashboard is enough. With several, each in a different tool with its own login, a real problem can sit unnoticed on the one you did not happen to check that day. A single screen removes the guessing about which tool to open.

The same underlying category of system. All maintained sites are already watched from a Command Centre as part of standard care, and this page covers building the same kind of unified view for a client's own multi-site or multi-system operation.

From 15,000$4,084€3,597, depending on how many systems are connected and what data each one exposes. An MVP typically takes two to six weeks. Third-party services are billed at cost, never marked up.

Data as a Service sells access to structured, maintained data on a subscription, reached through an API rather than a user interface. SaaS sells software a person uses. DaaS sells data another system consumes, and the product is the accuracy and freshness of that data, not a set of screens.

Collection, cleaning and keeping it current. Raw data is often available somewhere for free or cheap. What a DaaS product actually sells is the ongoing work of structuring it consistently and updating it on a schedule a customer can rely on, so their own system does not have to do that work itself.

A stated update schedule and a way for a customer to verify it, a last-updated timestamp on every record rather than a general claim that the data is "current". Freshness that cannot be checked is a claim, not a feature.

From 15,000$4,084€3,597, depending on data sourcing complexity and update frequency. An MVP typically takes two to six weeks. Third-party data sources, where used, are billed at cost.

No. Every store here is built custom, without an app-stack subscription for every feature, and third-party services are billed at cost with nothing marked up on top. For a very simple catalogue a template can genuinely be cheaper, and we will say so.

Yes. Variant handling is built so each combination carries its own stock count rather than one shared number behind a dropdown, which is the specific failure that breaks most template stores once a catalogue gets complex. Perfume, flowers and made-to-order desserts on this site all run on the same underlying model.

Yes, by default. Stripe resolves card and currency edge cases in milliseconds and handles both single and multi-vendor settlement properly, which is why it is the payment layer on every ecommerce build here regardless of catalogue size or how many vendors are behind it.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and variant complexity, delivered in 7 days. Every build includes custom checkout and Stripe integration as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

One page, built for one action: sign up, book, buy, register. A full website has navigation, multiple pages and a structure meant to be explored. A landing page has one job and nothing pulling attention away from it.

There is no navigation structure to design, no content architecture to plan across multiple pages, and no need to account for how a dozen pages interlink. One page, one purpose, built and tested end to end without the scope a full site carries.

Yes. Security headers, no third-party script on the render path, and the same performance targets apply regardless of page count. A fast build is not a shortcut on how it is built.

Within the 5,500$1,500€1,321 to 36,700$10,000€8,807 website range, typically toward the lower end for a single page, delivered in two to five days. Exact scope depends on tracking, form complexity and any campaign-specific integration.

Shipment tracking, rate quoting, customs document handling, carrier integration and multi-currency quoting, whether that sits inside a public-facing freight website or a fleet dispatch system. If it connects an operational system to the people who need to see it, it falls under this category.

We operate Cetus Pro, a live dispatch and ELD compliance platform running across 48 US states, so this is a system we run ourselves, not one we have only read about. A logistics website in this category can connect to an existing dispatch or ELD system, or we can scope one from the ground up.

Yes. Tracking is built to pull from the operational system directly, so a customer sees the same status your own team sees, instead of a page that has to be updated by hand. That connection is scoped against whatever system you already run.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 for a website, delivered in 7 days, 10 days with the integration. A dispatch or ELD platform is a different scope, from 15,000$4,084€3,597, with an MVP in 2 to 6 weeks. You own the code, the server and the data from the day it ships.

A normal store has one seller and one bank account at the end of checkout. A marketplace has many sellers behind one checkout, so a single payment has to split correctly between them, hold in escrow until a condition is met, and survive a dispute without anyone getting paid twice or not at all.

Holding a payment in a neutral place until an agreed condition is met, delivery confirmed, a service completed, rather than releasing it to the seller the moment a buyer pays. It protects both sides: the buyer is not paying into a void, and the seller is not delivering on a promise.

Each seller's share of a payment is calculated and paid out on its own schedule, tracked against that specific transaction rather than reconciled by hand afterward. That tracking is what usually breaks first when a marketplace is built on top of a single-seller checkout instead of being designed for many sellers from the start.

Priced per project, depending on the number of sides, payment complexity and dispute handling required. An MVP typically takes one to two months, with three months to a genuine commercial test. Third-party payment services are billed at cost, never marked up.

Gigagrams built the Expo 2020 Korea Pavilion game and Hallyu Olympiad for the Korea Tourism Authority, “Think Before You Share” for a lead agency’s Meta engagement, K-Boosters for Samyang Foods through an agency, and the ENOC Women in Energy Award website. They were delivered between 2019 and 2022.

Yes. The Expo 2020 Korea Pavilion microsite is a touchscreen puzzle game with a timer, limited tries, registration and winner tickets. Hallyu Olympiad holds two games in one site, with registration, file uploads and winner tickets. The Expo game had its own admin panel, so staff saw entries and results while the pavilion ran.

A microsite is a standalone build for one campaign, launch or event, with its own address and its own measurement. It does not inherit the main site’s menu or history. It exists to do one job for a set period, then it closes cleanly.

It comes down cleanly, or a redirect sends its address somewhere useful. No orphaned pages stay indexed and no dead links point at a finished campaign. “Think Before You Share” was closed by the client when its campaign ended, and the Hallyu Olympiad and K-Boosters links are no longer live.

A microsite costs 5,500$1,500€1,321 to 36,700$10,000€8,807, the same range as any custom website, and a website takes 7 days. A launch page sits at the lower end. A game with registration, winner tickets and an admin panel sits higher. You own the code, the server and the data from the day it ships.

A visitor can add the site to their phone's home screen directly from the browser, and it opens full-screen like an app from that point on. No app store listing, no approval process, no separate download step before someone can use it.

For most functionality, yes. Native is used only where a device feature genuinely requires it: certain background processing, deep hardware integration, or a capability the browser simply does not expose. Everything else runs as an installable, mobile-first build by default.

Responsive means a desktop design that also works on mobile. Mobile-first means the phone experience is designed first, since it is where most visitors actually are, and the larger screen is the adaptation, not the other way round.

Scoped during the technical audit, based on which specific device features the project actually requires, rather than assumed from the start. Most projects do not need it.

A running product. Real data, real flows, and real payments where the idea actually needs them, not a series of screens that look right but do nothing underneath. A mockup tells you whether people like the design. An MVP tells you whether the idea holds.

An admin panel beyond the minimum needed to run it, edge cases, and scale work. All three cost real money and time, and none of them tell you whether the idea works. They get built once the idea is validated, not before.

It becomes the starting point for a full platform or marketplace build, scoped properly once you know what actually needs to exist. The MVP is not thrown away, it is the first real data point for what comes next, not a guess dressed up as one.

Two to three weeks from brief to a working prototype. Price is scoped individually because it depends entirely on what needs to be tested, but it sits well below full platform cost, since everything not needed to answer the question is deliberately left out.

WhatsApp, Telegram, email, SMS and web chat arriving in one inbox with the full conversation history, rather than five separate tools a person has to check individually. The channel a customer chooses does not matter; the conversation and its history are the same either way.

A customer who messages on WhatsApp today and follows up by email next week should not have to repeat themselves. Without a shared history, whoever picks up the second message has no idea the first conversation happened at all.

No, it sits alongside them. The individual channel bots handle conversation on their own channel; omnichannel messaging is the inbox layer that brings every channel's conversations into one place for a human to see, including ones a bot has already handled.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on how many channels and how much history migration is involved, delivered in 7 days, 10 days with the integration. Messaging runs on the WhatsApp Business API, billed at cost.

A CRM for leads and deals, a public listing marketplace, and tenancy and rent management, connected to the same underlying data instead of running as separate tools. A listing entered once appears live, a tenant record stays linked to its unit, and a lead does not depend on one agent remembering it.

Separate tools mean a listing gets entered twice, a payment gets reconciled by hand against a spreadsheet, and a lead goes cold because nobody followed up. Connecting CRM, marketplace and tenancy data in one system removes the manual re-entry that is where most of that breaks down.

Yes. Real Estate CRM and Micro Property Rentals are both platforms we operate ourselves, at different stages, one in build with 30 trial places and 6 already taken, the other in closed operational testing with limited participants with a clickable demo available.

From 15,000$4,084€3,597, depending on which parts (CRM, marketplace, tenancy management) are included. An MVP typically takes two to six weeks. Third-party services are billed at cost, never marked up.

SaaS, software as a service, is software a customer uses by subscription instead of buying a copy. It runs on the provider’s servers, and people sign in through a browser or an app. The provider keeps it running and updated. Secureline (working name), our app for business calls, video and messages, is built as SaaS.

DaaS, data as a service, sells access to structured, maintained data by subscription, usually through an API rather than screens. The product is the ongoing work of collecting, cleaning and updating the data. A customer pays for data that stays accurate, not for software to work in.

Yes, and Trust Load, our US logistics ecosystem, is to be both. People work in it as software, and its data is planned as a service of its own. Trust Load is in closed testing. What its data service will offer is not published yet.

Yes, Gigagrams has built survey platforms for clients, alongside booking systems, recruiting CRMs and logistics systems. The clients are not named. A survey platform is SaaS when customers sign in to build and send surveys. It becomes DaaS when the answers are sold as data.

Multi-tenant means every customer shares the same running application and database, separated inside the system. Single-tenant gives each customer an isolated instance of their own. Multi-tenant costs less per customer. Single-tenant keeps one customer apart from every other, which matters when a client, a regulator or a contract requires it.

A platform starts from 15,000$4,084€3,597, depending on the tenancy model, the data side and the integrations. An MVP typically takes two to six weeks. Third-party infrastructure and services are billed at cost, never marked up. You own the code, the server and the data from handover.

Because that is where the conversation already happens. A widget waits for a visitor to notice it on a page they may never return to. WhatsApp and Telegram put the enquiry in an app people already have open, on the number they already use, which is why we run our own support through the same channel.

Enquiry handling, catalogue browsing, booking and routing to the right person, built on the WhatsApp Business API rather than a scraped integration that breaks when a policy changes. What it does not do is pretend to be a person indefinitely — it hands off to a human the moment a conversation needs one.

Scope and speed. A smart bot is built in days because it does one or two jobs on one channel, not because the engineering is shallow. If the requirement grows into a full CRM or an omnichannel inbox, that is a larger build we scope separately, not something this hides inside a small quote.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on how many flows it handles, usually toward the lower end for a single-purpose bot, delivered in days rather than the full 10-day-to-3-week range a website typically needs. You own the code and the integration from the day it ships.

Calls and recordings happening inside your own system, tied to the same customer record as every other interaction, rather than a separate third-party calling tool you log into and pay for on top of everything else.

A standalone app keeps call history and recordings in its own silo, disconnected from the customer record, the support ticket or the booking the call was actually about. Built-in voice and video keeps the call attached to the same context everything else already lives in.

Recording is scoped per project, consistent with data protection requirements in the relevant jurisdiction, not switched on universally without a stated reason and a place for the recording to be reviewed against.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on call volume and integration complexity, delivered in 7 days, 10 days with the integration. Calls are billed at cost.

No. Every site here is built custom, without a plugin ecosystem or a page builder, which is why pages load in under a second instead of the two to four seconds a typical template site carries. For a very simple brochure site a template can genuinely be cheaper, and we will say so.

The underlying build discipline is the same: no plugins, full ownership, fast by default. What differs is the data model. A real estate listing needs Arabic parity and Property Finder integration, a clinic page needs DHA licence display and consent tracking. Each industry page below covers its own specifics.

Yes, in most cases. Recruitment sites connect to an ATS, real estate sites connect to a CRM and marketplace feeds, clinics connect to booking and patient systems. The integration is scoped in writing before the build starts, not added afterward as an extra.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on industry and complexity, delivered in 7 days. Every build includes the industry-specific requirements as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Most UAE agencies list on both to maximise reach, since buyers and renters split their search between the two portals rather than using only one.

It should not, and the sync is built specifically to prevent it: a price change propagates to both portals at once rather than updating one and leaving the other stale.

It can, if the agency's assignment rules differ per channel. The integration tracks which portal an enquiry came from so that routing logic can apply.

Yes, alongside Property Finder integration, as standard within the 5,500$1,500€1,321 to 36,700$10,000€8,807 range, not priced separately afterward.

Past a monthly free credit, yes, billed per request. An unbounded autocomplete field on a busy page is the most common way a bill grows larger than expected.

Only if it is unrestricted. A key scoped to specific domains, IPs and specific APIs limits what anyone who finds it can actually do with it.

No. Geocoding accuracy varies by region and is markedly weaker in areas without a formal street-addressing system, which matters for delivery and service-area features specifically.

At cost. Third-party service costs, including Google's own usage fees, are billed exactly as charged, never marked up.

Most often because it was built as one request per record instead of using HubSpot's batch endpoints, which hits the account's rate limit quickly on any real volume.

Yes, if the integration does not enforce a consistent identifier across sources, a form submission, an import and a manual entry for the same person can each create a separate record.

It fails silently or is dropped rather than being created automatically, which is why custom properties are set up deliberately before the sync goes live.

It is scoped as part of the relevant build. Third-party service costs are billed at cost, never marked up.

Same-day, built into the sync deliberately. A unit gone off-market that still shows as available on the portal is treated as a compliance and trust problem, not a minor delay.

Deduplication runs against a stable reference number, so a unit arriving from two internal sources does not list twice on the portal under different IDs.

Yes, it is a mandatory field for advertised listings in Dubai, and a listing missing a valid one is rejected by the portal rather than flagged softly.

Yes, as standard within the 5,500$1,500€1,321 to 36,700$10,000€8,807 range for a real estate site, not priced separately afterward.

It has to be actively refreshed before expiry, or the connection fails quietly. That refresh handling is built in rather than left to fail and be noticed later.

It can, but needs a clear rule for which system owns which record. Without one, edits made in both places can produce duplicates or silently overwrite each other.

No. Rate limits and company-specific configuration, like the chart of accounts, can behave differently in production, so production behaviour is verified separately.

It is scoped as part of the relevant build. Third-party service costs are billed at cost, never marked up.

Hours-of-service data carries direct regulatory weight under FMCSA rules. A sync error that shows a driver as compliant when they are not is a compliance exposure, not just an incorrect number on a screen.

The data stream gaps rather than errors, and a dispatch system has to treat that explicitly as a gap, not interpret missing data as the vehicle being stationary.

Webhooks, for any fleet of real size. Polling hits rate limits quickly, and webhook-driven updates are the only approach that scales past a small number of vehicles.

Yes. Cetus Pro, a client platform for US dispatch and ELD compliance across 48 states, runs on exactly this kind of telematics and hours-of-service integration.

Because payment gateways fail quietly, and a card type, an amount threshold or a regional rule causing a decline is a lost sale the merchant never learns about. Stripe resolves those cases in milliseconds and handles single and multi-vendor settlement properly.

A properly built integration reconciles against Stripe's own record on a schedule, rather than trusting webhooks to arrive every time. Webhooks are the primary signal, not the only one.

Yes, on any build that needs payments. Third-party processing fees are billed at cost, never marked up.

Yes, some businesses run both. It adds integration complexity and is only worth it when domestic and international volume both justify maintaining two systems.

No. The app is a manual, single-device tool for small businesses. The Business API is programmatic, built for automated or high-volume messaging integrated into another system.

Because the 24-hour session window has closed, and only a pre-approved template can be sent at that point, not open text. This is a platform rule, not a bug.

It varies and is not fully predictable, which is why templates are prepared and submitted early rather than assumed to be ready by launch day.

Yes, for WhatsApp-based bots specifically. It is scoped as part of that build rather than priced as a separate add-on.

No. For low-volume, simple automations between common tools, it is genuinely useful and often the right call. The problem shows up specifically at volume and with complex branching logic.

Once automation volume or complexity grows past what per-task pricing and no-code branching handle well, a direct integration usually costs less to run and is easier to debug when something goes wrong.

Yes, that is common: keep Zapier for simple internal automations, and build a direct integration for anything customer-facing, high-volume, or needing near-real-time response.

Scoped case by case, depending on how many systems are involved and how well-documented their APIs are. Third-party service costs are billed at cost, never marked up.

Yes. Vehicle-fitment filtering, make, model, year, trim, is applied before a customer browses a category, since a part that does not fit is the single most common cause of returns in this category.

Yes. OEM versus aftermarket status is shown clearly per SKU, since customers actively search for one or the other and a catalogue that does not distinguish them loses both kinds of buyer.

Yes. Bulk and trade or workshop account pricing runs as a distinct tier from retail single-item purchases, which a standard consumer checkout does not support.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and fitment data complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Shade and colour variants are shown with an accurate visual swatch rather than a text label, since colour mismatch on screen is one of the largest drivers of returns in this category specifically.

Yes. Claims like paraben-free, cruelty-free and fragrance-free are structured, filterable product data, not a paragraph buried in the description.

No. Review and user-photo content is integrated without becoming a render-blocking script, since social proof matters enormously here and is also a common performance liability.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and variant complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Corporate and bulk gifting runs as its own ordering flow, with invoicing and purchase-order capture that a standard consumer checkout does not offer.

Yes. Ramadan pre-order demand is handled as a surge the checkout and stock are built to hold under, rather than the scramble an unprepared store goes through every single year.

Yes. Hamper building runs on real bundle logic, not a single fixed-contents product that cannot represent what a customer actually wants to send.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and corporate-order complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Bulk multi-recipient ordering supports a single payer and a shipping list of many different delivery addresses, structurally different from the one-buyer-one-address model most stores are built on.

Yes. Purchase-order and invoice handling captures a PO number and supports invoice payment, since corporate buyers frequently cannot complete a standard consumer checkout at all.

Yes. Custom branding is captured as structured data tied to the order, which the fulfilment team can act on directly rather than through a follow-up email exchange that delays a time-sensitive deadline.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on recipient volume and branding complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

A generic cart plugin assumes every product has the same shape: one price, maybe one dropdown of options. A custom checkout is built around what is actually being sold, so a fragrance with twelve size and concentration variants tracks stock per variant, not behind one shared number.

Variant stock. A shared stock count behind a dropdown lets a customer buy a size that is actually out, which then has to be refunded and apologised for after the fact. A custom checkout tracks each variant combination separately from the start.

No. Payment processing runs on Stripe by default, the proven layer. What is custom is the catalogue and cart logic around it, built for the actual products, not the payment plumbing underneath, which stays on infrastructure built for exactly this.

It is included in every ecommerce build in this category, priced within the 5,500$1,500€1,321 to 36,700$10,000€8,807 range depending on catalogue size and variant complexity, delivered in 7 days. Not billed as a separate add-on.

Yes. Spec-comparison tables, processor, RAM, storage, ports, are structured and filterable, not buried in a description tab nobody reads to the bottom.

Yes. Warranty and authorised-dealer status is shown clearly per product, since grey-market electronics are a real trust concern and an unclear warranty status is a common cause of returns.

Yes. Trade-in and bundle pricing, device plus accessories, trade-in credit against a new purchase, runs as real checkout logic, not a manual back-and-forth over email or WhatsApp.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and variant complexity, delivered in 7 days, 10 days with the integration. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Same-day delivery cutoff times are enforced at checkout, so an order that cannot physically be fulfilled that day is never accepted in the first place. The customer sees the next available slot immediately, instead of finding out by phone that the order cannot be made after it has already been placed.

Yes. Slots are booked by area rather than one shared citywide window, because a Marina run and an Al Quoz run are not the same drive and should not compete for the same capacity. Each area gets slots sized to how long its own deliveries actually take.

The substitution policy is built into the order flow itself, so a customer agrees to a substitution rule at checkout rather than discovering one after delivery. Stems go out of stock mid-day during peak weeks, and a silent swap is the single fastest way to generate a complaint.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on delivery area count and occasion complexity, delivered in 7 days. Every build includes cutoff enforcement, area-based slots and occasion capacity limits as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Freight and white-glove delivery quoting is built for oversized items specifically, since a standard weight-and-dimension calculator was never designed for a piece that needs its own truck and installation crew.

Yes. Stock is shown as in showroom, made to order, or several weeks out, rather than a single in-stock flag that hides the difference between a floor sample and a six-week production run.

Yes. Assembly and installation are bundled as part of the same purchase, rather than treated as a separate, disconnected line item the way a default product model does.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and freight complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

As close as the data allows. Real-time stock is tracked by store or warehouse, since grocery inventory changes hourly and a static stock number is wrong within the day.

Substitution handling is built into the order flow, approve substitutions or exclude specific items, since an out-of-stock item mid-pick is routine, not an edge case.

Yes. Cold-chain delivery logic distinguishes frozen, chilled and ambient items within the same order, which a single flat shipping rule cannot represent correctly.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and delivery zone complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Metal-price-linked pricing updates items sold by weight against a daily gold or silver rate, which a flat, static price cannot represent without going stale within a day.

Yes. Certification and authenticity documentation is attached per item, since provenance is part of what is actually being sold on pieces at this price point.

Yes. Engraving, ring sizing and strap customisation are captured as order-level data tied to fulfilment, not a note that nobody downstream reliably sees.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue value and certification handling, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Age-range and safety-certification filtering, age grading, choking-hazard warnings, safety standard compliance, is structured, filterable product data, the primary decision filter for a parent.

Yes. Gift registries run as their own flow, since the purchase is often made by someone other than the list's creator, a materially different pattern from a standard cart.

Yes. Bundle and set pricing runs on real bundle logic, multi-item toy sets and party favour packs, not a single fixed-contents product that cannot represent the combination.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and bundle complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Variant handling covers all four dimensions at once, where a standard three-option model would force a compromise or require a separate paid app to represent the same catalogue.

Yes. Measurement capture is tied directly to the order and its fulfilment, not a separate form disconnected from the piece that actually gets made.

Yes. Returns for a tailored or altered piece run through their own logic, since a standard return flow assumes every item is resaleable exactly as received, which a made-to-measure abaya is not.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and made-to-measure complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Each product carries its own lead time, so a celebration cake requiring 48 hours and a box of macarons requiring two hours are both handled correctly in the same checkout. A customer cannot accidentally order a cake for same-day delivery the kitchen has no way to bake.

Yes. Cake personalisation is captured as structured fields — message, tier, flavour per tier, allergen note — that the kitchen reads directly, not a free-text comment someone has to interpret. Nothing about a custom order depends on a person reading it correctly under pressure.

Delivery windows are built around a cold chain, so a dessert is not sitting in a hot car for an hour before it reaches the door. A dessert delivered warm is a refund and a bad review, and the scheduling is built to prevent it rather than apologise for it afterward.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on product range and personalisation complexity, delivered in 7 days. Every build includes per-product lead time, structured cake orders and Stripe checkout as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Each size and concentration — 30ml, 50ml, 100ml, EDP, EDT, extrait — is handled as its own purchasable item with its own stock count, not as a dropdown sitting on top of one shared inventory number. A sellout of the 50ml EDP does not touch the 100ml EDT.

Yes. Discovery sets and samples sit alongside full-size bottles in the catalogue, because most customers will not spend on a 100ml bottle of an oud they have never smelled. It is built as a normal product with its own variant, not a workaround.

Stock and delivery rules are built to change for peak periods, since a single fortnight can carry a quarter of a perfume store’s annual volume. That is a configuration the store supports directly, set once in advance, not a manual scramble the team repeats by hand every single year.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and variant complexity, delivered in 7 days, 10 days with the integration. Every build includes variant-level stock, discovery sets and a gifting flow as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Subscribe-and-save reorder is core checkout logic, since pet food is one of the most naturally recurring purchase categories in ecommerce, and a bolted-on subscription app adds unnecessary failure points.

Yes. Recommendations are tied to a pet profile, species, breed, weight, age, so suggestions and portion sizing are relevant rather than generic.

Yes. Veterinary and prescription products run through the same verification logic a pharmacy needs, since some pet products are prescription-restricted.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and subscription complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Yes. Prescription upload and pharmacist verification are built into the order flow for prescription-only items, rather than sold through a standard checkout with no verification step.

Yes. Expiry-date and batch tracking is live stock data, since selling near-expiry medication without disclosure is a real regulatory and trust problem in this category.

Yes. Refill subscriptions run as core checkout logic, since repeat, predictable-timing purchases are a large share of pharmacy revenue.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and regulatory complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

Handling the cases where a payment fails quietly: a card type, an amount threshold or a regional rule that causes a decline. Stripe resolves those in milliseconds and shows the customer why, rather than a blank failure that just looks like the site is broken.

A customer retries twice, gives up, and leaves. The merchant never learns the sale existed, because nothing logged the attempt as a specific, explainable failure. It looks like lost interest when it was actually a payment gateway problem.

Yes. Stripe handles single and multi-vendor settlement properly, splitting a payment between multiple parties and tracking who is owed what, which is why it is the payment layer on marketplaces as well as single-seller stores here.

Payment gateways fail quietly, and Stripe resolves the specific edge cases, card type, amount threshold, regional rule, in milliseconds rather than leaving a customer stuck. Third-party services including Stripe are billed at cost. We do not mark up other people's software.

Yes. Subscribe-and-save reorder is core checkout logic, not a bolted-on subscription app with its own separate points of failure.

Yes. Stack-building tools let customers combine multiple products, which a standard single-product checkout was never built to bundle or price correctly.

Yes. Restrictions are respected at the SKU level, since a product legally sellable in one Gulf market is not automatically sellable in every neighbouring one.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and subscription complexity, delivered in 7 days. Every build includes the requirements above as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

The Federal Motor Carrier Safety Administration is the US regulator overseeing commercial trucking safety, including hours-of-service rules that limit how long a driver can be on duty. Compliance means the system enforcing those limits accurately and keeping the records an inspector or auditor can check.

Fines, and in some cases a driver or vehicle taken out of service on the spot during a roadside inspection. The cost of non-compliance is immediate and operational, not just a paperwork problem discovered later.

The device records hours accurately, which is necessary but not sufficient. The system around it, how records are stored, how edits are logged, how a driver certifies a log, also has to meet the specific requirements an inspector checks against.

Yes. Cetus Pro, a client platform we built and operate, handles hours-of-service compliance across all 48 contiguous US states, covering exactly this requirement in production.

Yes. Tracking pulls directly from the operational system, so a customer sees the current status online instead of phoning the desk for an answer someone has to look up manually. The status shown is always the same one your own team sees.

Quoting is built by lane, weight and equipment type, with accessorial charges priced in at the point of quoting rather than added to the invoice afterward. A quoted price and an invoiced price match, which is what stops a dispute before it starts.

Yes. Bills of lading, packing lists and certificates of origin attach directly to the shipment record, so the paperwork travels with the shipment instead of living in a separate email thread someone has to search for later, days after it was actually sent.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on carrier integration and quoting complexity, delivered in 7 days, 10 days with the integration. Every build includes shipment tracking, lane-based quoting and multi-currency support as standard, not priced as a separate add-on afterward. You own the code, the server and the data from the day it ships.

A listing system matching available freight, a load that needs moving, with available capacity, a carrier or driver with space and a route. It works like a marketplace: shippers or brokers post loads, carriers see what is available and claim one.

A generic third-party load board charges a subscription and shows your loads to every competitor also posting on it. A load board built into your own system keeps your shipper and carrier relationships inside a platform you own, without paying a per-seat fee to a board you do not control.

The load is held the moment a carrier starts claiming it, the same principle applied to booking systems generally, so two carriers cannot both commit to the same freight while the second is still confirming.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on complexity and integrations, delivered in 7 days, 10 days with the integration, within the same range as the rest of the logistics and ELD category.

Holding a payment in a neutral place until an agreed condition is met, delivery confirmed, a service completed, rather than releasing it to the seller the instant a buyer pays. It protects both sides: the buyer is not paying into a void, and the seller is not delivering on a promise with nothing to show for it yet.

Settlement is what happens after the condition is met: calculating each party's share of a payment and actually paying it out. Escrow holds the money. Settlement moves it to where it is owed, split correctly when more than one party is entitled to a piece of it.

Each party's share is calculated against that specific transaction and tracked to its own payout, rather than reconciled by hand afterward. A shipper, a carrier and a broker on the same load each see their own settled amount, not a lump sum someone has to divide up manually.

Yes. Trust Load, a US logistics marketplace we co-founded, runs on this exact escrow and settlement model, currently in closed operational testing with limited participants.

The amount a specific vendor is owed from a specific transaction, calculated after fees and any held-back reserve, and moved to that vendor on a defined schedule. It is the step after settlement decides who is owed what.

A vendor who does not know when they get paid stops trusting the marketplace, regardless of how well the storefront works. A stated schedule, daily, weekly or on a rolling basis, is part of what makes a vendor treat the platform as a real channel rather than a side experiment.

A portion of a payout withheld temporarily to cover the risk of a refund, chargeback or dispute after the fact. Without one, a marketplace can pay a vendor in full and then have no funds left to refund a buyer when something goes wrong days later.

Escrow and settlement covers holding a payment and calculating who is owed what. This page is specifically about the payout mechanics: schedule, reserves and how a vendor actually receives their share.

A native app is compiled specifically for iOS or Android, giving it direct access to device hardware and OS-level capabilities a browser cannot reach: certain background processing, deep camera or sensor integration, or OS-level push behaviour beyond what a progressive web app supports.

When a specific device feature required by the product is not exposed to browsers at all. Most functionality, including offline use and push notifications, does not need it, which is why native is the exception here, not the default.

Yes, native apps are distributed through the iOS App Store and Google Play, which brings an approval process and a store fee on transactions that a progressive web app avoids entirely. That trade-off is part of why native is scoped deliberately rather than assumed.

From 15,000$4,084€3,597, depending on platform count and device feature complexity. An MVP typically takes two to six weeks, a different scope from a website build.

A website that behaves like an installed app: it can be added to a phone's home screen, opens full-screen without a browser bar, works offline for content already loaded, and can send push notifications, all without going through an app store.

No approval process, no store fee cut on any transaction, and no forcing a visitor through a download before they can use the product. A link is enough; installing it is optional, not a barrier to entry.

A service worker, a small script the browser runs in the background, caches what has already been loaded so the app still opens and shows recent content without a connection, rather than a blank error screen.

Included by default, within the 5,500$1,500€1,321 to 36,700$10,000€8,807 website range, not billed as an add-on discovered after the fact.

Every customer runs on the same application and the same database, separated logically inside the system rather than each getting their own physical copy. One codebase, one deployment, many customers using it at once, each seeing only their own data.

Every query is scoped to the customer making it, enforced in the application and the database layer, not left to a client remembering to filter correctly. A bug in that scoping is the single most damaging failure mode a multi-tenant system can have, which is why it is tested deliberately rather than assumed to work.

One set of infrastructure serves every customer, so adding the hundredth customer costs a fraction of what standing up a hundredth isolated instance would. The saving compounds as the customer count grows, which is the whole economic case for building SaaS multi-tenant in the first place.

When a customer, a regulator or a contract requires complete infrastructure separation, not just logical separation inside a shared system. At that point single-tenant is the honest answer, scoped separately rather than forced into a multi-tenant shape it was never designed for.

Each customer gets their own isolated instance of the application and database, rather than sharing infrastructure with every other customer. Nothing about that customer's deployment is touched by another customer's traffic, data or downtime.

When a customer, a regulator or a contract requires complete infrastructure separation, not just logical separation inside a shared system. Some industries and some contracts do not accept "your data is scoped correctly inside a shared database" as sufficient, and single-tenant is the honest answer at that point.

No. The application code is the same, deployed as its own running instance per customer, not maintained as a fork per customer that would drift apart over time. One codebase, many isolated deployments.

More per customer, because infrastructure is not shared. From 15,000$4,084€3,597, with an MVP in 2 to 6 weeks, the same as any platform build, but the ongoing infrastructure cost per customer runs higher than a shared multi-tenant deployment.

A channel broadcasts one-to-many, for announcements and updates nobody needs to reply to. A group is many-to-many, for a community that talks to each other. A bot is the automated layer that can operate inside either, or answer someone directly, and the three are usually combined rather than chosen from.

Structured buttons that appear inside the chat itself, so a customer taps an option instead of typing a free-text answer a bot then has to interpret. It is faster, harder to get wrong, and it is a Telegram-specific interaction pattern we build around rather than working against.

Yes. Telegram has its own payment flow built into the conversation, so a customer can pay without leaving the chat or being redirected to a separate checkout page. It connects to the same payment infrastructure everything else we build uses.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on how many flows it handles, usually toward the lower end for a single-purpose bot, delivered in days rather than the 10-day-to-3-week range a website typically needs. You own the integration from the day it ships.

The Business API is the official, verified way to run WhatsApp at scale, with a confirmed business profile customers can trust. A scraped integration built on the regular app can get the number banned the moment WhatsApp detects automated behaviour, which is why we build on the official channel rather than around it.

Yes. WhatsApp's own catalogue feature sits inside the chat, so a customer sees products, prices and availability without switching to a website or an app. It is the same conversation the enquiry started in, not a handoff that loses them.

Yes. Order status updates and booking confirmations push directly into the same thread, and the bot handles both without a person until the conversation actually needs one. Handover happens the moment it does, with the full history intact for whoever picks it up.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on how many flows it handles, usually toward the lower end for a single-purpose bot, delivered in days rather than the 10-day-to-3-week range a website typically needs. You own the integration from the day it ships.

Separate pages. UAE Corporate Tax, in effect since June 2023, and VAT are separate compliance obligations with separate filing calendars, and folding both into one generic services page answers neither question a visitor actually came with.

Yes, where it matters. Free zone and mainland entities carry different audit and tax filing requirements, and a site that treats every visitor the same is giving half of them the wrong answer before a conversation even starts.

Through a client portal built for it, not as email attachments. Sensitive financial statements sent by email are both a data protection exposure and a genuinely worse workflow than a proper upload and exchange system built into the site.

Yes. Every published before-and-after image is tied to a recorded patient consent, not stored loose in a folder nobody checks. If consent is withdrawn, the image comes down and the record shows when and why, which matters the day a regulator or a patient asks.

On the clinic's own page and on every practitioner's profile, which is where DHA rules require it on healthcare advertising in Dubai. It is treated as required content, not an afterthought added to satisfy a checklist during a later review.

Yes. The consultation form captures the treatment of interest at the point of booking, so the clinic knows whether it is a filler enquiry or a surgical one before the phone rings. That single field changes who calls back and how fast.

Images load progressively. A project page opens in under a second with a compressed preview, and the full-resolution render loads in behind it, instead of a visitor staring at a white screen while a 4MB hero image downloads. This is the specific fix for the failure that costs most architecture sites their Core Web Vitals score.

Yes. Each project carries client, scale in square metres, completion year and discipline as structured data, not as text buried in a paragraph. A visitor can filter the archive by discipline or size directly, and the same structure is what lets search engines understand and surface individual projects rather than one long portfolio page.

Yes. Drawing and specification files sit behind a short form, so a download is tied to a name and an email address rather than an anonymous link anyone can share. You see who requested the document, which matters when what you are sharing is unbuilt work.

Yes. Daily specials and sold-out items update from a phone in seconds, not through a CMS login that takes five minutes when the till is busy, and the change reflects on the site immediately.

Yes. Pre-order and click-and-collect slots are tied to kitchen throughput, so the shop never accepts fifteen 8am collection orders it can only physically make ten of.

Yes. A mall kiosk and a full cafe location are kept as one structured record rather than duplicated pages, so a price change updates everywhere at once instead of drifting out of sync.

Yes. Fleet availability is live, by specific vehicle and date range, not a generic SUV-from-$X price page that does not reflect which vehicles are actually free.

Yes. Insurance tier and excess or deposit options are selected as part of the booking flow, since this is where rental agreements are usually disputed after the fact if not made explicit upfront.

Yes. Driver document verification, licence, passport, age requirements, is captured digitally before pickup, rather than discovered as a problem at the counter that delays the handover.

Yes. Instant or near-instant quoting is based on property size, service type and frequency, rather than a generic contact form that requires a phone call before the customer even knows the rough price.

By default, yes. Recurring bookings assign a fixed cleaner or team, since trust in a specific person entering someone's home is the primary retention driver in residential cleaning.

Yes. Add-on services are priced and bundled at the booking step, rather than negotiated after arrival, which is a common source of disputed final invoices in this category.

Yes. Each virtual brand gets its own separate storefront rather than one menu with a filter, since a customer ordering from a brand has no reason to know it shares a kitchen with four others.

Yes, on every order it captures. Delivery platforms typically take 20 to 30 percent per order, and an owned ordering site is the actual mechanism for keeping that margin on repeat customers.

Yes. Ordering windows are capacity-aware, since a cloud kitchen has no dining room to absorb a rush, and an oversold slot means food arriving cold or not at all.

Yes. RFQ and tender submission is a real upload workflow, not a contact form asking someone to email a document instead. Most serious enquiries in this industry arrive as a formal document, and the site is built to receive one properly the first time.

Where the client has it, yes. Classification and grading, issued by Dubai Municipality or the equivalent authority in other emirates, determines which project sizes a contractor is even eligible to bid on, and displaying it is a credential, not a formality.

Clearly, and separately from general company information, since a tender shortlist is filtered on safety compliance such as ISO 45001 before price is even discussed. Burying that in a PDF download costs a shortlist spot before anyone reads further.

Yes. Desk and meeting-room availability is shown live by specific space and time, not a generic book-a-tour contact form that hides actual availability until a phone call.

Yes. Hot desk, dedicated desk and private office tiers are tracked against their own usage limits, since a flat membership page cannot represent tiered access rules.

Yes. Day-pass and drop-in booking runs as a separate, lighter flow from full membership signup, since a walk-in visitor should not need a full membership application.

Yes. Booking is procedure-length aware rather than running on one flat slot size, since a cleaning, a filling and a root canal occupy a chair for entirely different durations. A flat 30-minute default either overbooks a long procedure or wastes the gap after a short one.

As structured, consented image sets tied to the specific procedure, veneers, whitening, alignment, rather than a generic stock-photo carousel that could belong to any practice. Consent is captured at upload, not assumed.

Both, where the data supports it. Many UAE health plans cap or exclude dental cover entirely, so an insurance panel that only says 'accepted' without an out-of-pocket estimate is answering the wrong question. We show the panel as searchable data with that gap made explicit.

Yes. Hotel pickup-zone logic accounts for how location and timing change route feasibility, rather than treating hotel pickup as a single generic checkbox the way most booking tools do.

It rebooks automatically. Weather and heat-advisory cancellation is handled specifically for desert conditions, not a generic force-majeure clause that nobody actually knows how to trigger correctly.

Yes. Add-on activities are priced and bundled together as one order, rather than sold as separate disconnected purchases that fragment the booking.

Yes. Lesson-credit packages, a 10-lesson package used down over weeks, are tracked properly, rather than treated as one-off bookings that cannot represent a prepaid balance.

Yes. Progress across lessons, skills covered and instructor notes, is visible to the student, not kept only in an instructor's private notebook the way it usually is.

Yes, where integration is agreed. RTA test booking coordination and eligibility tracking accounts for the specific stage and test requirements of UAE driving licence processes, which a generic booking tool has no concept of.

Yes. Navigation is built around structural, MEP, civil and geotechnical categories, because that is how a client actually searches, not around the firm’s internal department names. A visitor lands on the discipline they need in one click instead of guessing which department handles it.

Yes. Each project carries scope, sector, client type and completion year as structured fields, so a procurement search can match your capability to their requirement directly. That structure is also what lets the page surface in search rather than sitting inside one long case study document.

Version control on every technical document and specification, so the file a client downloads today is the current one, not an outdated PDF still live from a previous update. Superseded versions are kept on record but never served as the default download.

Yes. Ticketing carries real inventory per ticket type and date, with waitlists and tiered pricing built in, which shallow built-in event tools on site builders do not track properly.

Yes. RSVP, payment and guest list are unified in one flow, rather than a payment record and a guest list that have to be reconciled by hand from two separate exports.

Yes. Each event gets a genuinely branded page rather than one generic events template reused for every listing, since a sponsor or vendor is evaluating that specific event, not the company's homepage.

Yes. Class booking runs on real capacity tracking rather than an embedded third-party widget, so a class that shows as available online is actually available, and the front desk sees the same numbers the website shows.

Membership billing includes proper dunning on a failed card, so a lapsed membership from a declined renewal gets chased rather than quietly disappearing as revenue nobody notices left.

Yes. Waitlist handling is built into the booking flow itself, since a manually managed WhatsApp waitlist is how a class ends up both overbooked and half empty at the same time.

Yes. The portfolio is structured by space type and style as filterable data, residential against commercial, minimalist against classic, rather than one long scroll a prospective client has to dig through to find something comparable to their own project.

Where relevant, yes. Fit-out and structural changes need a Dubai Municipality or developer NOC before work starts, a step separate from the interior design trade licence itself, and a client planning a timeline benefits from that being stated plainly rather than discovered later.

As part of the site experience itself, not emailed as a disconnected PDF a client has to go hunting for in their inbox three weeks later. A proposal stays linked to the project record it belongs to.

Yes. Photo upload happens at the booking step, so a tradesperson sees the actual problem before arriving, reducing the wrong-parts, wrong-tools callback that is common in this category.

Yes. Callout and materials pricing is shown as a transparent structure, callout fee, hourly rate, materials at cost, rather than a vague we'll-quote-you, a major source of distrust in this category.

Yes. Job status and technician ETA are visible to the customer, since someone-will-call-you is the standard failure a scheduling plugin bolted onto a template site usually produces.

Both. Healthcare advertising rules in the UAE require the clinic's DHA or MOH licence and each individual doctor's own licence number, and the two are not interchangeable. A site built for this shows both correctly, on the clinic page and on every doctor's own profile.

Yes. The panel and TPA list are built as structured, filterable data rather than a scanned PDF or a flat image, since which insurers a clinic accepts is usually the deciding factor before a patient calls, and a patient searching by their own insurer needs an answer in seconds, not a downloaded file.

Intake forms capturing medical history submit into a secure record rather than a plain email inbox or a WhatsApp thread, since a message carrying patient history sitting in an inbox is a data protection exposure the clinic is directly responsible for, not a minor inconvenience.

Yes. Quoting is inventory-based, room count, item list, volume estimate, rather than a flat hourly rate that ignores how much is actually in the property.

Yes. Access difficulty, stairs, no elevator, narrow street, parking restrictions, is captured at booking, since these are the actual drivers of a job running over time and over budget.

Yes. Storage add-ons for moves needing interim storage between properties are priced and booked as part of the same order, not a separate disconnected service.

Yes. Booking, contract signature and deposit collection are handled as one flow, since a client making a booking decision does not experience it as three separate steps the way most studios currently run it.

Yes. Private galleries are built to hold a real shoot's worth of high-resolution images without the slow load that pushes many photographers toward a disconnected third-party gallery tool.

Yes. Print and product fulfilment is integrated with gallery delivery, rather than a separate lab-integration app that adds its own checkout step and its own failure point.

Yes. Listings sync from both portals into one record, with deduplication when the same unit arrives from two sources under different reference numbers, which is the usual way a duplicate ends up live on a site. A single update changes the price everywhere at once, instead of leaving one portal showing a figure the other has already moved past.

Yes, by design. Each listing is one record with translated fields, not two separate pages maintained on two different schedules by two different people. Change the price once and both languages update together, so the Arabic version never shows last month's figure while the English page has already moved on to a new one.

The web address stays live. Listing pages are built to survive a unit going off-market, so the search authority that specific page earned over months is not thrown away the moment something sells or a landlord pulls a unit. A new listing can reuse that position instead of starting from zero rankings.

Yes. The site connects to the ATS or recruitment CRM over API, so a vacancy created in the system of record publishes to the website and to job boards without anyone retyping it. Closing a role in the ATS closes it on the site at the same time.

CV parsing runs on submission, so an application arrives as structured fields your CRM can search and filter, not as an attachment someone has to open one at a time. The original file is kept too, but the parsed data is what your team actually works from.

Yes, by design. Employers and candidates get separate journeys from the first click, because posting a role and applying for one need opposite layouts and opposite calls to action. Neither audience has to wade through content meant for the other.

Yes. Menus are published as structured, searchable content instead of an uploaded PDF or photographed page, so a dish going out of stock or a price changing can be updated from a phone in seconds, and the change is visible to search engines too.

No. Reservation handling is built without depending on an embedded third-party widget loading before the rest of the page becomes interactive, which is the usual cause of a slow, janky booking button on restaurant sites.

Yes. A multi-location restaurant gets genuinely separate branch pages, each carrying its own hours, menu and reservation availability, rather than one generic template duplicated with the address swapped.

Yes. Booking shows real-time next-available-chair rather than a rigid appointment grid built for hour-long spa treatments, which fits how a barbershop actually turns customers over.

Yes. Rebooking defaults a returning client back to the same barber, since loyalty to a specific person is the primary retention lever in this category, more than the shop's own brand.

Yes. Membership haircut plans are tracked as usage against a plan, unlimited or discounted monthly visits, which a standard one-off-booking tool has no way to represent.

Yes. Multi-resource booking checks all three at once, since a single-resource widget will double-book the treatment room or the therapist even when the calendar looks clear.

Yes. Package and multi-session pricing is tracked against actual usage, rather than kept on a spreadsheet because the booking tool only understands single appointments.

Yes. Allergies, medical conditions and consent are captured and tied directly to the booking record, not a paper form filled out in the waiting room and never digitised.

Yes. Capacity is tracked per departure, tied to a specific date and vehicle or guide, so a tour never oversells nine seats on a six-seat vehicle the way a generic book-now button can.

A waitlist and next-departure suggestion is built into the flow, so a sold-out date offers the next available one instead of a dead end that sends the customer to a competitor.

Yes. Group and private tour pricing is handled as its own path with its own quote logic, distinct from the standard per-seat rate on a shared departure.

Yes. Flights, hotels, transfers and activities are priced and bundled together as structured data, so a real itinerary can be assembled and quoted without someone building a PDF by hand for every enquiry.

Yes, where the agency has access. Third-party GDS, hotel and activity inventory integration is scoped in writing before the build starts, since an agency's catalogue lives in other companies' systems.

Yes. Multi-currency, multi-passenger booking is handled as one flow, since group and family bookings are common in this category and a single-traveller checkout forces an awkward workaround.

The specific unit. Equipment and vessel-specific availability is tracked individually, not a generic activity booked against unlimited inventory, so the jet ski or boat reserved is the one that actually shows up.

It rebooks automatically. Weather and sea-condition cancellation is built into the flow, since marine activities are cancelled for conditions far more often than land-based tours and a manual refund process does not scale.

Yes, where required. Certification and waiver capture, dive level and liability waiver, is handled as part of the booking flow rather than a paper form signed dockside on the day.

Yes. Vendor coordination is shown as structured packages, venue, catering, photography, bundled or itemised, rather than a static services list disconnected from actual vendor relationships.

Yes. Budget tracking is one live record shared between planner and client, rather than a spreadsheet emailed back and forth that goes stale within a week.

Yes. Galleries are organised by venue and style rather than a flat chronological feed, since couples typically search by the specific venue or aesthetic they already have in mind.

Yes. Each vessel carries hourly, half-day and full-day rates in the same calendar, so a booking made for two hours shows a different price to one made for the full day. Peak dates such as New Year, Eid and National Day run on their own pricing rules, set once rather than edited by hand every season.

Yes. A deposit is captured the moment a booking is confirmed, with the balance due before departure. A charter held without a deposit is not a booking, and the system will not hold a slot open against a payment that never arrives.

The cancellation policy is built into the booking flow itself, with automatic rebooking to the next available slot rather than a refund conversation. The customer sees the new date immediately on screen, instead of waiting on an email reply that might not arrive until the next morning.

No, provided the migration is done properly. We map every old web address to its new one, preserve page titles and structure where they already work, and keep your Search Console history. Rankings usually recover within two to four weeks and often improve, because the new site is faster and cleaner for search engines to read.

Admin access to the current site, plus Google Analytics, Google Tag Manager and Google Search Console. We need all four to map existing keywords, rankings, traffic sources and user behaviour, so nothing valuable is lost in the move and domain authority carries across intact.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on page count, languages and complexity, delivered in 7 days. The technical audit beforehand is free and unconditional. We remove anything from scope that will not earn its cost.

They stop. There is no platform subscription, no app or plugin licence and no builder fee on a site we build. You pay for hosting, which is usually a few dollars a month, and an optional care plan. Third-party services are billed at cost with no markup.

Sometimes. If the problem is images, caching or a handful of plugins, a speed rescue in three to five days is the honest answer and we will say so. If the slowness comes from the platform itself, optimising it is temporary and the cost returns. The audit tells you which situation you are in.

You can, or we can. The code is yours and any competent developer can work on it, because there is nothing proprietary in it. If you want us to keep monitoring and updating, a care plan runs quarterly rather than monthly, because a custom build needs far less attention than a plugin stack.

They are different scopes with different pricing. A website runs 5,500$1,500€1,321 to 36,700$10,000€8,807, delivered in 7 days. A platform starts from 15,000$4,084€3,597, with an MVP in 2 to 6 weeks, because it is custom software rather than a set of pages.

A second or third language is not a translation plugin dropped on top. Copy is written natively, and for Arabic the layout mirrors properly rather than just flipping text direction, both of which take real time regardless of project type.

It is a typical range for the scope you selected, not a quote. The exact number depends on your specific catalogue, integrations and content, which is what the free technical audit establishes before anything is priced precisely.

That is a separate number, calculated further down this page: platform subscriptions, apps, licences and retainers added up into what your current site actually costs every year, compared against a one-time rebuild.

Shopify is a hosted ecommerce platform: a monthly subscription for the platform itself, plus a transaction fee on every sale unless you use its own payment processor, plus whatever paid apps the store has installed for things the base platform does not do natively.

Each app that solves one problem, a better search, a loyalty program, a custom field, adds its own monthly fee, and most stores keep adding them rather than removing the ones no longer earning their cost. The transaction fee applies to every sale indefinitely, which a one-time rebuild does not.

Shopify's checkout is built for its own product model, which assumes a fairly standard variant structure. A catalogue with unusual combinations, like a fragrance with size and concentration variants tracked independently, or made-to-order items with delivery windows, often needs a custom checkout built around the actual product rather than the platform's assumptions.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and variant complexity, delivered in 7 days, the same range as any custom ecommerce build here. The technical audit that comes first is free and unconditional.

Wix and Squarespace are closed, drag-and-drop website builders: the site only exists inside their platform, and there is no way to export the working site to run anywhere else. A custom build is code in your own repository, runnable on any server, closed to nobody.

Leaving means starting over. There is no export that hands you a working copy of the site to move elsewhere, only content you can copy manually into something new. The platform fee is the visible cost. Being unable to leave without a rebuild is the hidden one.

They are built for ease of editing, not for page weight or load speed, and that trade-off shows up as heavier pages than a purpose-built static or server-rendered site would carry for the same content. The gap widens as a site grows past a simple brochure.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on page count, complexity and languages, delivered in 7 days. The technical audit that comes first is free and unconditional.

WordPress is a content management system that runs on plugins, small add-on programs installed to add features a template does not include natively. A site rarely starts slow. It accumulates plugins over years, each one adding its own code, its own database queries and its own update schedule, until the page weight and the attack surface have both grown well past what anyone intended.

No. A simple brochure site with a handful of pages and no growth plans can run fine on it for years, and we will say so if that describes your situation. The problem shows up at scale: ecommerce, booking, multi-language, anything that needs real data structure rather than pages of content.

Content, products and media are exported and mapped into the new structure, every old URL is redirected to its new one, and Search Console, Analytics and Tag Manager data are used to make sure nothing that currently ranks or tracks disappears in the move.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on page count, plugin complexity and languages, delivered in 7 days. The technical audit that comes first is free and unconditional.

Same audit, same four areas: speed, security, search and cost. This page covers the extra layer that matters specifically before a migration: the baseline captured so a rebuild can be checked against it afterward, not just diagnosed once and forgotten.

The standard audit runs externally, no passwords needed. A migration is different: without Search Console, we cannot see which specific pages actually rank, for what terms, so we would be guessing which URLs must survive the move rather than knowing.

The rankings, traffic and page weight recorded before anything changes, so the after-rebuild numbers can be compared against something real. Without a baseline, "did the rebuild work" is a guess instead of a measurement.

Yes. About a third of the audits we run conclude the honest answer is not a rebuild. That verdict is in the report either way, free and unconditional, whether or not it leads to work for us.

The default variant picker shows a text label or a basic colour block, not an accurate shade preview. Colour mismatch on screen is one of the largest drivers of returns in this category, and the default picker does little to prevent it.

Filtering by paraben-free, cruelty-free or fragrance-free needs structured product metafields, not the generic tags Shopify's default filtering was built around. Left unconfigured, a customer cannot actually filter by the claims that matter to them.

Review and user-photo apps like Loox or Yotpo are common in this category because social proof matters enormously here, but they frequently load as render-blocking scripts if not implemented carefully, directly working against the page speed that also drives conversion.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on SKU count and shade variant complexity, delivered in 7 days. Accurate shade swatches and structured ingredient filtering are included, not priced as separate apps.

A consumer checkout has no native purchase-order field or net-terms invoicing, both of which a company ordering hundreds of Eid gift boxes actually needs. Without a real B2B flow, that order gets handled manually outside the platform.

Demand concentrates into a short window, and dates specifically have a short shelf-life freshness window, so pre-orders have to lock a delivery date tied to freshness rather than accept an order the kitchen cannot actually fulfil on time.

It does not. Shopify's shipping has no concept of a temperature-controlled delivery window, so chocolate melting in transit during a Gulf summer is a routine, foreseeable failure rather than an edge case anyone planned for.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on corporate ordering and hamper complexity, delivered in 7 days. Corporate ordering and heat-sensitive delivery logic are included, not priced as separate apps.

Shopify's checkout has no built-in time-of-day cutoff logic. Enforcing "no same-day orders after 2pm" needs a delivery-date app layered on top, and those apps have their own limitations around cutoffs that vary by delivery zone.

Shopify's native shipping rates are calculated by weight and zone, not by a calendar time slot. Booking a specific delivery window by area needs a shipping-app override, since the platform was not built around slot-based logistics.

Shopify's native oversell protection depends on safety-stock buffers configured correctly in advance. A peak week that outpaces those buffers sells past what the florist can actually fulfil, and that is discovered as a cancellation, not prevented at checkout.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on delivery zone complexity, delivered in 7 days. Cutoff enforcement and slot booking are included, not priced as separate app subscriptions.

Shopify's native shipping calculator works on weight and dimensions the way a parcel courier prices a package. A piece that needs its own truck and an installation crew was never the shape of item that model was built to price.

Shopify's product model treats a service add-on as a separate, disconnected line item rather than part of the same purchase, so assembly or installation usually needs an app to bundle it properly.

Shopify's default inventory is a binary in-stock or out-of-stock flag. It does not distinguish a floor sample available today from an item that is made to order and six weeks out, and a customer who assumed the former gets a real complaint.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on freight complexity and catalogue size, delivered in 7 days. Honest stock status and freight quoting are included, not priced as separate apps.

Basket sizes in jewellery and watches carry materially higher chargeback exposure than most ecommerce categories, and the default fraud tools were tuned for a general store, not for orders where a single chargeback can be a significant loss.

Shopify's product model has no native way to attach a certificate to a specific, one-of-a-kind item. Without deliberate setup, provenance documentation sits disconnected from the product it actually belongs to.

Shopify prices are static per variant by default. An item priced against a daily gold or silver rate needs a pricing-sync mechanism pulling that rate and updating the price, or the listed price is wrong within a day.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on customisation and certification volume, delivered in 7 days. Metal-price-linked pricing and per-item certification are included, not priced as separate apps.

An abaya or kaftan genuinely varies by length, fabric, colour and size, four dimensions where Shopify natively supports three option types. One of those four usually gets forced into a workaround or a paid variant app.

Shopify's product model has no native field for a customer's measurements tied to the order. Without deliberate integration, a measurement form sits disconnected from what actually gets sent to production.

Shopify's built-in return flow assumes an item is resaleable as received. A tailored or altered piece is not, and processing it through the standard flow risks a refund on something that cannot actually go back on the shelf.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on variant complexity and made-to-measure volume, delivered in 7 days. Four-dimension variant handling is included, not priced as a separate app.

Shopify natively supports three option types and a hundred variants per product. A fragrance line with size, concentration and gift-set combinations can exceed both limits, forcing either an option-combining workaround or a separate paid variant app.

Bundling several sample SKUs into one purchasable set is not native to Shopify's product model, and usually needs a bundling app layered on top, adding another checkout dependency and another monthly fee.

Neither is a native Shopify checkout field. Capturing a gift message or a wrapping choice needs a cart-attribute app or a custom checkout extension, which is where this specific feature usually breaks first.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on variant count and gifting complexity, delivered in 7 days. Variant-level stock and gifting flows are included, not priced as separate app subscriptions.

Shopify does not handle recurring billing natively, so a subscription app like ReCharge or Bold sits on top of the core checkout, with its own monthly fee and its own point of failure, on a business model where reorder is the entire point.

A standard Shopify product description is unstructured rich text. Regulatory information like ingredient lists, batch numbers and expiry dates has to be set up deliberately as structured metafields, or it defaults to a static, unmaintained PDF.

Shopify Markets can geo-restrict a product by country, but it requires deliberate configuration. Left at the default, a product containing an ingredient restricted in one Gulf market can sell into it without anything stopping the transaction.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on SKU count and subscription complexity, delivered in 7 days. Subscription checkout and structured product data are included, not priced as a separate app.

Wix Events and Squarespace Events offer shallow inventory tracking, with no real waitlist and no dynamic tiered pricing per ticket type, which a multi-date, multi-tier event genuinely needs.

Payment records and the guest list do not stay in sync automatically. Reconciling who paid against who is actually attending usually means exporting two separate lists and matching them by hand.

On these platforms an "event page" is usually just another page in the same site navigation, not a genuinely separate, brandable space. A sponsor or vendor evaluating a specific event is really looking at the company's general site with a different heading.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on ticketing complexity and event volume, delivered in 7 days. Real inventory tracking and unified guest management are included, not priced separately.

Structurally similar, and in one way worse: a native form on these platforms submits to a connected email with no self-hosted control over where that data ultimately lands, compared to at least being able to reconfigure a WordPress plugin's notification settings.

Wix Bookings supports staff members, but assigning different service durations per specialty across several doctors becomes unwieldy in the native interface, and clinics commonly give up and fall back to one generic calendar.

The same static-content problem as anywhere else, made worse because neither platform easily supports a genuinely searchable, filterable table without custom code injection, which both restrict.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on doctor and specialty count, delivered in 7 days. Per-doctor booking and secure intake are included, not priced separately.

For a simple portfolio, genuinely yes, and we will say so rather than sell a rebuild nobody needs. The mismatch shows up once a studio needs client galleries, contracts and print fulfilment working as one system rather than three separate tools bolted together.

Native galleries were not built to hold a full shoot's worth of high-resolution images without a slow load, which pushes many photographers toward Pixieset or ShootProof regardless of the platform underneath, fragmenting the client experience.

A client making a booking decision thinks of it as one step. On Wix or Squarespace it is usually a booking widget, a separate DocuSign link and a separate Stripe payment link, none of which share data with each other.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on gallery volume and fulfilment integration, delivered in 7 days, 10 days with the integration. A unified booking-contract-deposit flow is included, not priced separately.

It is a closed content block with no real data structure behind it, so there is no way to add dietary or allergen filtering, and no way to export the menu content to use it anywhere else on the site or off it.

Native booking tools and most embedded widgets check a single resource per slot. A table booking actually needs to check table availability and covers together, which a single-resource model was not built to represent.

Wix and Squarespace are built around one site. A chain either runs separate sites per branch, losing shared search authority, or duplicates pages inside one site by hand, and hours and menus drift out of sync between them.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on location count and menu complexity, delivered in 7 days, 10 days with the integration. A structured menu and real reservation logic are included, not priced separately.

Wix Bookings and Squarespace Scheduling check one resource per slot, either the staff member or the room, not both together with the treatment's actual duration. A treatment needing a specific therapist, room and duration all free at once is exactly what a single-resource check cannot guarantee.

Native booking tools track individual appointments, not usage against a prepaid package of sessions. Without that, package tracking usually falls back to a spreadsheet kept alongside the booking system rather than inside it.

A store feature like Wix Stores and a booking feature like Wix Bookings do not share data by default, even inside the same account. A purchased voucher has to be applied manually rather than showing up as credit at the booking step.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on service and staff complexity, delivered in 7 days. Multi-resource booking and package tracking are included, not priced separately.

A generic gallery plugin like Envira or NextGEN stores images with no consent metadata attached. Nothing in the plugin ties a published photo to a recorded patient permission, so the gallery is one accidental upload away from a genuine problem.

Contact Form 7 with no treatment-of-interest field makes a filler enquiry and a surgical consultation look identical when they arrive, so front desk cannot triage or prioritise a high-value enquiry over a low-value one.

Attachments, including patient photographs, are usually emailed as plain attachments through Contact Form 7's default notification, which is a genuine data protection exposure for clinical material.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on treatment count and gallery volume, delivered in 7 days. Consent-tracked galleries and secure enquiry handling are included, not priced separately.

Renders are exported at full resolution, often 8 to 20MB before compression, and uploaded straight into the media library with no resizing pipeline. A page builder like Elementor or Divi then wraps each gallery image in extra containers on top of the raw file weight.

Client, scale and completion year are usually stored as unstructured text through a custom-fields plugin, with no consistent taxonomy across projects. That makes filtering by sector or scale impossible, which matters more for a firm competing on capability than most industries.

Yes, when embedded as an eager-loaded iframe, a Matterport or YouTube embed blocks the first paint of the page even if the visitor never scrolls down to view it.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on portfolio size and gallery complexity, delivered in 7 days. Progressive image loading and structured project data are included, not priced separately.

WordPress's media library has no version control. When a specification is updated, the old file usually stays live at its own URL, still indexed, and Google has no way of knowing the new one is the one that matters.

They usually arrive through a plain contact form into a shared inbox, with no workflow tracking who is handling what. A request that needs a same-day response to make a submission deadline can sit unread for a day.

A client searching for a structural engineer is not the same search as one looking for MEP, and a WordPress category taxonomy built for blog tags rarely maps cleanly onto the discipline structure a procurement search actually uses.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on document volume and project count, delivered in 7 days. Document version control and discipline-based structure are included, not priced separately.

Tracking is typically an iframe embed of a separate third-party portal, completely disconnected from the site's own branding and navigation, so a customer bounces out of the experience entirely just to check a status.

A static contact form stands in for a real quote engine, meaning a lane, weight and equipment-type quote takes a phone call and a manual lookup rather than an instant, structured answer.

Bills of lading, packing lists and certificates of origin are usually emailed as loose attachments rather than attached to the shipment record itself, so nothing keeps the paperwork and the shipment in sync.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 for the website layer, delivered in 7 days, 10 days with the integration. A dispatch or ELD platform underneath it is a different scope, from 15,000$4,084€3,597.

A plugin like Amelia or Bookly, or a MindBody iframe embed, adds its own script weight and rarely matches the rest of the site's branding, so the booking step feels like leaving the gym's own site even when it technically has not.

WooCommerce Subscriptions handles a recurring charge, but without a configured dunning sequence for a declined card, a lapsed membership from a failed renewal looks identical to a deliberate cancellation, and the revenue just disappears.

Most booking plugins do not support waitlist logic at all, so a popular class ends up managed over WhatsApp, which reliably produces both an overbooked class and empty spots in the same week.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on class volume and location count, delivered in 7 days. Real capacity tracking and dunning-managed billing are included, not priced separately.

A booking plugin with no real property management system connection has its own separate rate table, which drifts from what the PMS actually charges. The property gets ranked lower on Booking.com and Expedia for the mismatch, as well as distrusted by the guest.

Without a live PMS connection, availability in the plugin is a separate number from what the front desk actually has. A room can show available on the site after it was already sold through another channel, because nothing keeps the two numbers in sync.

WPML duplicates a rate page per language rather than translating one underlying record, so a rate change made to the English page does not automatically reach the Arabic or Russian version, creating both a parity problem and a duplicate-content indexing issue.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 for the website layer, delivered in 7 days. Real PMS-driven availability and rate parity are scoped based on which property management system is actually in use.

A search for a specific practice area, a divorce lawyer or a construction dispute specialist, converts at a completely different rate than a generic landing page. An anchor link on a shared page has no real URL of its own and cannot rank for that specific search.

A generic forms plugin typically emails the submission as plain text, which means case detail covered by a confidentiality obligation is sitting in an inbox rather than a system built to hold it.

Without routing at first contact, every enquiry lands in one shared inbox regardless of practice area, and a fast response is often the deciding factor for someone comparing firms after an incident.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on practice-area count and attorney profiles, delivered in 7 days. Separate practice-area pages and secure intake are included, not priced separately.

A generic forms plugin like Gravity Forms or WPForms typically emails a submission as plain text the moment it is sent, which means medical history is sitting unencrypted in an inbox rather than a system built to hold it securely.

Most clinic sites publish their accepted insurers as a scanned image or a PDF uploaded to the media library, which is unindexable, hard to update and often the single most-needed piece of information before a patient calls.

A multi-doctor practice booking every specialty against one WordPress appointment plugin instance means a paediatrician and a dermatologist appear to share availability that does not actually exist, which shows up as booking errors.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on how many doctors and specialties are involved, delivered in 7 days. Per-doctor booking and secure intake are included, not priced separately.

A forms plugin can collect a document upload, but there is rarely any applicant-facing status tracking behind it. A parent submits transcripts and a birth certificate and then has no way to see whether the application has even been opened.

WooCommerce was built for one-off purchases. Forcing term-based, recurring tuition through a subscriptions add-on is a common source of failed renewal handling, since the plugin was never designed around an academic term calendar.

KG, Primary and Secondary pages built from one template with the year group swapped read as near-duplicate content to search engines, which depresses all of them in ranking rather than helping any single one.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on curriculum stages and enrolment volume, delivered in 7 days. Trackable admissions and proper term-based billing are included, not priced separately.

The listing feed plugin syncing Property Finder and Bayut on a cron schedule that fails silently, leaving sold units live for days. Arabic listings duplicated as separate posts via WPML that drift out of price sync. Elementor-built agent pages carrying the same defensive markup weight every page-builder site carries.

Most real estate plugins regenerate the listing slug or unpublish the post entirely once a unit is marked sold, which breaks the URL and throws away whatever search ranking that page had earned. The address a search engine indexed simply stops resolving.

The data does, but it usually arrives as a plain typed custom field with no validation, so migrating it is an opportunity to check every listing actually has a current, correctly formatted number rather than one nobody has looked at since it was entered.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on portfolio size and language count, delivered in 7 days. The listing feed integration and Arabic parity are included, not priced as separate add-ons discovered later.

It usually has no real connection to the agency's ATS or CRM, so vacancies get re-typed by hand from the system that actually holds them. Every manual re-entry is a chance for a listing to go stale or a role to close on the CRM while it still shows open on the site.

Gravity Forms or WPForms treats an uploaded CV as an email attachment, arriving as a file someone has to open manually rather than structured, parseable candidate data the CRM can actually use.

Getting listed requires correctly implemented JobPosting structured data, which a generic listing plugin often implements incompletely or not at all, quietly cutting off a major source of candidate traffic.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on integration depth with the existing ATS or CRM, delivered in 7 days, 10 days with the integration. ATS-connected listings and CV parsing are included, not priced separately.

Search engines cannot read text trapped inside a PDF or a photographed page the way they read real page content, so the dish someone is actually searching for never surfaces. It also cannot be updated from a phone at the pass when a dish sells out.

An iframe-embedded OpenTable or Resy widget usually loads before the rest of the page becomes interactive, which is a common, specific cause of a slow, janky booking button on restaurant sites.

Talabat, Deliveroo and Careem often carry different prices and menu items than the restaurant itself, and a static button linking to each one has no mechanism to flag when what is shown no longer matches reality.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on location count and menu complexity, delivered in 7 days. A structured, searchable menu and reservation handling are included, not priced separately.

Most booking plugins are built around one rate per bookable item, and a single vessel commonly carries three rates in one day, hourly, half-day and full-day. Forcing that through a plugin built for one price means either a manual booking process off-platform, or a price that is wrong for most of the day.

Usually a manual refund conversation, because no general-purpose booking plugin has a concept of a weather-contingent charter. Rebuilt properly, a weather cancellation triggers automatic rebooking rather than a dispute over whether a refund is owed.

A charter held without a deposit is not a real booking, and a generic payment plugin does not enforce a balance due before departure on its own. That logic has to be built into the booking flow itself, not assumed to happen because a payment button exists somewhere on the page.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on fleet size and pricing complexity, delivered in 7 days. Per-vessel booking with seasonal pricing and deposit handling are included, not priced separately.

A quick service fixes a specific, scoped problem — speed, payments, SEO or local search — without touching anything else. A rebuild replaces the whole site. If the foundation is sound and only one thing is broken, a quick service is faster and cheaper, and we say which one applies rather than defaulting to the bigger job.

There is no published price, because scope varies too much to quote honestly in a table. Every quick service is scoped in writing before work starts, usually once the free technical audit has identified exactly what needs fixing and how much of it there is.

Not strictly, but it helps. The audit tells you which of these services actually applies, or whether none of them do. Skipping it means we scope the fix from a shorter conversation instead of from a two-day written report covering every finding.

We say so before doing further work, not after billing for it. Some sites are held together by exactly one broken thing. Others have a platform-level problem no quick fix will solve, and patching around it would cost more over time than starting over.

A verified Google Business Profile, LocalBusiness structured data on the site itself, and the same name, address and phone number everywhere they appear. Get one wrong and search engines either cannot confirm the business is real or show conflicting information, and either one keeps it out of local results.

Schema markup that tells search engines exactly what the business is, where it is and how to reach it, in a format they can read directly rather than infer from a page. This site runs the same schema type we set up for clients.

An unverified or inconsistent one often does more harm than having none. We check the profile is verified, the category is correct, and the address on it matches the address on the website and everywhere else the business is listed, since a mismatch is what actually suppresses local ranking.

One physical location or service area as standard. Multiple locations are scoped separately, since each one needs its own verified profile and its own consistent listing, and the work scales with the count rather than staying flat regardless of how many there are.

Payment gateways fail quietly. A card type, an amount threshold or a regional rule causes a decline, the customer retries twice and leaves, and the merchant never learns the sale existed. We test the checkout against the specific conditions that trigger silent failures, rather than waiting for a customer to complain.

Not always, but often. Stripe resolves card and currency edge cases in milliseconds and handles single and multi-vendor settlement properly, which is why it is our default. If your existing gateway is not the actual problem, we fix the configuration instead of replacing it.

Yes. Split payments across multiple sellers or partners is one of the more common reasons a checkout breaks silently, since most off-the-shelf plugins were never built for it. We repair the settlement logic so it reconciles, not just so it stops erroring.

Three to seven days, depending on whether the fix is configuration, a gateway migration, or untangling a multi-vendor settlement problem. You get a written summary of what was failing, what changed, and how to test the checkout yourself once it ships.

Not keywords or content, the structural things that stop Google from reading pages correctly at all: indexation, canonical tags, structured data, duplicate titles and mobile usability failures. A page can have excellent content and still be invisible in search because of a problem here.

Yes. We audited one site with 212 pages published and only 96 indexed by Google, caused by missing canonical tags and a blocked directory in robots.txt, not by the content itself. Fixing two structural issues brought the other 116 pages back into contention.

It fixes what is stopping pages from being read and shown properly, which is a precondition for ranking, not a guarantee of it. If the pages Google can now see are thin or duplicated, that is a content problem this service does not cover, and we will say so.

Three to five days, depending on how many of the five problem areas are present and how large the site is. You get a written summary of what was found and what changed, the same detail level as the free audit.

We rebuilt a booking site from a 4.1MB WordPress page scoring 31 to a static site scoring 100 on PageSpeed mobile, measured 9 October 2026. That is a rebuild, not a rescue, but it shows the ceiling. A rescue on a site with a sound foundation typically gets close, without replacing the platform underneath it.

No. A speed rescue is scoped to load time and the specific causes behind it — images, scripts, caching and dead weight. Design, content and functionality stay exactly as they are unless you ask us to change something separately, in a separate piece of scoped work.

We say so before doing the work. Optimising images and scripts buys real speed on a sound foundation, but if the platform itself is the bottleneck, a rescue only buys a few months before the slowness returns. That is when a rebuild is the honest answer, and only then.

Three to five days from the moment we have access to the site, depending on how many pages and how many separate causes are involved. You get a before-and-after PageSpeed score you can test yourself once it ships, not just our word that it is faster.

Yes. There is no charge, no card required and no obligation to work with us afterwards. The written report is yours to keep, and you are free to hand it to another developer. We do this because it qualifies both sides honestly: we find out whether we can help you, and you find out whether we know what we are talking about.

Just your web address. Everything in the standard audit is tested from outside your site, so no access or passwords are needed. If you also grant read access to Google Search Console and Analytics, we can add ranking and traffic analysis, but that is optional.

Two working days from the moment we have your web address. You receive a written PDF report by email. No discovery call is required beforehand, though we are happy to walk you through the findings afterwards if you want.

Only if the report supports it. Roughly a third of the audits we run conclude that a rebuild is not the right answer, and we say so in writing. If the problem is images, caching or a handful of plugins, a short fix is the honest recommendation and we will tell you that instead.

Yes, and many clients do. The report names specific problems with specific fixes, so it is directly usable by whoever maintains your site now. We do not mark it confidential and we do not ask for anything in return.

Yes. For a platform, a marketplace or an internal system the audit covers the same four areas plus architecture, database structure and integration points. It takes three to four days rather than two, and it is still free.

Because a custom build does not generate monthly work the way a plugin-based site does. There is no theme update to apply, no plugin conflict to resolve, nothing breaking on someone else’s release schedule. Quarterly billing matches how often there is actually something to do.

Not always. A custom build carries no plugin ecosystem, which is the biggest source of ongoing maintenance on the rented-platform sites we usually see. Some clients take no care plan and simply call if something comes up. A care plan buys monitoring and priority response, not a subscription you need to justify.

Monitoring from our own Command Centre, security patching, and priority response within support hours, for around 400$109€96 a quarter. Anything beyond that scope, such as content changes or new features, is quoted separately rather than folded into a flat fee that quietly expands.

Priced by agreement rather than a flat quarterly figure, because the operational complexity varies far more than a website does. We scope it the same way we scope the build itself: in writing, before anything is agreed to by either side.

Because the business behind it changes even when the code does not. New products, new pricing, a seasonal offer, a different handover contact, all of these need the bot’s flows updated to match, which is a content and scope task rather than an infrastructure one.

Yes. The scenario editor in the bot management console lets your own administrator make those changes directly, no code and no developer required. Bot maintenance as a care plan is for when you would rather we handle the updates directly, on an agreed schedule, instead of doing it in-house yourselves.

That is absorbed as part of maintenance. Both platforms change their APIs and policies over time, and keeping a bot working through those changes is exactly the kind of thing a plugin-free custom build still needs someone actively watching for and adjusting.

Quarterly, like all care plans. It is scoped by how many flows and channels are involved, the same way the original bot build was, rather than a single flat figure applied regardless of complexity or how much actually changes each quarter.

The same three measures behind every system we build: security headers configured correctly, encryption in transit and at rest, and no third-party script on the render path. Hosting is not a separate security posture from the build, it is the same one extended to the infrastructure.

Releases are atomic, so a deploy either completes fully or does not apply at all, and a broken one rolls back with a single command rather than a manual scramble to undo half-applied changes. The site is never left in a state that is half the old version and half the new one.

We restore them. An untested backup is a hope, not a control, so restores are rehearsed on a schedule rather than assumed to work because a backup job reported success. The first time a restore is tested should never be during an actual incident.

It is included in what a standard care plan covers for a website, billed as part of the same quarterly figure. For a platform or marketplace, hosting is scoped as part of the wider care agreement rather than priced on its own.

The site is down, a security incident, or payments or forms are failing — something a customer actually cannot use. A content typo or a request to change a headline is a normal support matter, handled in support hours rather than on the 24/7 critical line.

A first-response time is not yet published. What is fixed is which incidents qualify as critical and which plan covers 24/7 response for them — see below.

Included by default on either care plan, Watch or Assurance. All maintained sites are watched from the same Command Centre, so a problem is usually caught before a client notices it.

Monitoring is part of both care plans. 24/7 critical incident response specifically is an Assurance feature — see /care/plans/ for what each plan covers.

Watch is the proof that this is not rent: uptime, SSL and domain expiry monitoring, security updates of the server and its dependencies, backups, and critical incidents handled in support hours, all for 200$54€48 a quarter. Assurance adds 24/7 critical incident response, a dated quarterly report against speed, links and redirects, security headers and accessibility, and anything that report finds has regressed since the last one is fixed at our cost.

No. Care keeps what already exists running: monitored, patched, and responded to quickly if something goes wrong. New features or content changes are scoped and quoted separately, the same way the original build was, rather than folded into a flat fee that quietly expands to cover anything asked of it.

That is allowed, since you own the code. What it changes is the plan: a change made outside our process, without our written agreement and review, is not fixed free if something goes wrong with it. We either restore the last version we signed off, or review the change at an hourly rate.

The site keeps running, on your server, on code that is already yours. Nothing goes down and nothing is taken away. Monitoring stops, and any future fix becomes hourly work instead of something already covered.

Because the operational complexity varies far more than it does for a website. A marketplace handling payments and multiple vendors carries a different risk profile from a brochure site, so it is priced by agreement rather than a flat quarterly figure, scoped the same way the build itself was.

No, and we will not tell you it is. No completely secure system exists, and anyone who claims otherwise is selling you something. What we publish instead is the specific measures every build carries: security headers, encryption in transit and at rest, and no third-party script on the render path. Measures, not guarantees.

NIST Cybersecurity Framework Tier 3, Repeatable, is where formal policies exist and are consistently applied across the organisation, not just followed ad hoc. That is our current tier, and we are working toward Tier 4, Adaptive. It measures security practice maturity, a different thing entirely from Uptime Institute's Tier III, a datacentre redundancy standard that happens to share the same number.

No. Hardening a system built on a weak foundation is fitting an armoured door to a clay house. If your current site has real security gaps, the honest fix is usually a rebuild, not a patch, and we will say so rather than sell you door fitting on a house we did not build.

Two-factor sign-in, and sign-in bound to the owner’s device, so a known password alone does not let anyone in. On the user’s computer, a guard watches network routes and cuts any remote session that was not allowed. Inside the system, monitoring watches what runs in real time. These are measures, not a guarantee.

Nobody gets standing access by default, including us. Access is granted for what a task requires and expires when the task ends, rather than employees or systems carrying broad permissions indefinitely. It is one of the engineering principles behind every system we build, alongside minimum human input and digital hygiene.

In transit means data is scrambled while it moves across a network, between a browser and a server, so intercepting the connection reveals nothing readable. At rest means the same applies to data sitting on a disk, so a stolen or improperly accessed drive is still unreadable without the key.

HTTPS covers encryption in transit, which stops the connection itself being read. It says nothing about what happens to that data once it lands on a server or a backup drive, which is why encryption at rest is a separate, equally necessary measure.

With encryption at rest applied consistently, a lost or stolen drive is unreadable without the key, which is not stored alongside the data. Without it, whoever has the drive has the data in plain, readable form.

By default, on every system we build, regardless of budget. It is one of the three measures that cost nothing extra to include because they are how we build anyway, not an upgrade a client has to specify or pay more for.

A defined sequence for handling a security event: detect it, contain it so it stops spreading, remove the cause, recover the system, then tell the people who need to know what happened. The word "incident response" describes that sequence, not just the act of noticing something went wrong.

Fast reflexes handle the first ten minutes. A documented process determines whether the next ninety are spent containing the problem or arguing about who owns which step. Without one, the response is improvised at the exact moment improvising is most costly.

The 24/7 line covers uptime and functional incidents, a site being down or a checkout failing. This page covers the security-specific discipline of containment and recovery when the event is a breach, a compromised credential or an exploited vulnerability, a narrower and more specific case.

A review of what happened and why, feeding back into the documented process so the same gap does not reopen. This is the same feedback loop that moves a security practice from Tier 3 toward Tier 4 on the NIST CSF scale.

Monitoring inside systems means watching what runs inside a system while it runs, in real time. A check at the door decides who comes in. Monitoring inside looks at what happens after that, so activity inside the system is seen while it happens, not found later in a report.

A check at the door, such as sign-in protection, looks at each person once, on the way in. Monitoring inside the system keeps watching after that, at system level, for as long as the system runs. One decides who enters. The other watches what runs inside, so the two work as separate layers.

Yes, we practise the same approach every day on our own systems. Runtime threat detection at system level is one approach for clients and for ourselves. All maintained sites are also monitored from the Command Centre. We publish this as a measure we take, never as a guarantee that nothing gets through.

No. No completely secure system exists, and we publish measures instead of guarantees. Monitoring inside systems watches what runs while it runs. It is one layer of the enterprise cybersecurity we build, beside sign-in protection and post-quantum encryption, and next to a set plan for incident response.

A voluntary set of guidelines published by the US National Institute of Standards and Technology for organising and assessing how an organisation manages cybersecurity risk. It does not certify anyone. It gives a shared vocabulary for describing how systematic a security practice actually is, from reactive to fully adaptive.

Most small businesses with no dedicated IT function sit at Tier 1, Partial, where security decisions happen case by case rather than following a written, repeated process. That is not a criticism, it is simply what an informal practice looks like measured against this scale.

No, and the shared number is a coincidence vendors sometimes exploit. Uptime Institute Tier III measures datacentre redundancy, physical infrastructure. NIST CSF Tier 3 measures security practice maturity, an organisational discipline. Always state which framework you mean.

It means the security measures on your build, headers, encryption, no third-party script on the render path, are applied the same documented way on every project, not decided fresh by whoever happens to be working on it that week.

Post-quantum encryption is encryption designed to hold against attacks by quantum computers, as well as by the computers of today. It matters most for data that has to stay private for years, because encrypted data recorded today could be read later by a quantum computer if the encryption was made only for today’s machines.

Because data can be recorded now and read later. An attacker who cannot read encrypted traffic today can still copy it and keep it. If that data has to stay private for years, the encryption has to hold for years too, including against the computers that arrive in that time.

Post-quantum encryption is part of the encryption we build. On Secureline, our platform for business calls, video and messages, it is part of the encryption plan, and its status is Planned. Secureline is in its final build before testing.

No, and we will not call it that. No completely secure system exists, and we publish measures instead of guarantees. Post-quantum encryption is designed to hold against attacks by quantum computers. It is one layer, beside sign-in protection, monitoring inside systems and encryption in transit and at rest.

The current state of the measures actually in place right now, as opposed to a general claim made once and left to go stale. A posture page states what is true today and carries a visible date, so a reader can judge whether it is current rather than trusting a claim with no timestamp on it.

A security claim without a date could be from before or after the last dependency update, the last header change, the last audit. Dating it lets a reader judge freshness for themselves instead of taking "we are secure" on faith indefinitely.

No. This page states our own measures. The free technical audit examines a specific site, yours, and reports what is actually exposed on it. One is a standing position, the other is a specific diagnosis.

No. No completely secure system exists, and stating otherwise would be the exact claim this page exists to avoid. What it states instead is which measures are active as of the date shown.

No, a known password alone does not let anyone in. Sign-in also asks for a second factor, and it is bound to the owner’s device, so someone with the password on another device is turned away. These are measures, not a guarantee: no completely secure system exists, and we will not tell you one does.

Two-factor sign-in asks for two separate proofs before it lets anyone in. The password is the first. A second factor is asked for as well, so a password that leaks, or that someone guesses, does not open the account on its own. It is one of three parts of the sign-in protection we build.

The guard watches network routes on the user’s computer. When someone tries to reach that computer through a remote session that was not allowed, the guard cuts the session. It is not a spam filter. It sits quietly, watches the routes and acts only on a remote session that nobody allowed.

No. No completely secure system exists, and we publish measures instead of a guarantee. Sign-in protection is one layer of the enterprise cybersecurity we build, beside post-quantum encryption and monitoring inside systems. Nobody gets standing access either, including us, and access ends when the work ends.

A record of who did what, when, kept in a form an auditor can review without having to ask the team what happened from memory. SOC 2 is a common compliance standard that examines exactly this kind of evidence. "SOC-ready" means the record already exists in that shape, not that the system itself is SOC 2 certified.

A dispute over who changed a price, deleted a listing or accessed a customer record is not only a large-company problem. Without a log, the answer is whoever shouts loudest or whoever still remembers. With one, the record settles it in seconds.

No. A server access log records requests, not actions, and an analytics report is aggregated and anonymised by design. An audit trail records a specific action, by a specific account, at a specific time, attributable and reviewable individually.

Which actions get logged, where the record is stored and how long it is retained are scoped during the technical audit for that project, rather than fixed as one blanket figure that would not hold true for every system we build.

A stated way for someone who finds a security flaw to report it safely, and what happens after they do. It exists so a researcher who finds a real problem has somewhere to send it other than posting it publicly first, and so a business is not caught off guard by a stranger emailing a general inbox.

Email hello@gigagrams.com with what you found and how to reproduce it. Include the specific system affected. We reply within our standard new-enquiry window, or within 1 to 3 hours if the report is critical.

No. There is no paid bounty programme currently. A genuine report is still read, acknowledged and acted on, it is simply not compensated financially at this time.

The affected system or URL, the steps to reproduce the issue, and what you expected to happen versus what actually happened. A clear, reproducible report gets fixed faster than a vague one.

No user, device or system is trusted by default, even one already inside the network. Every request has to prove itself, every time, rather than being waved through because it came from somewhere considered safe. It is a design principle, not a single product you buy and install.

A perimeter fails once, completely. If an attacker gets past the firewall or a credential leaks, a trust-the-inside model gives them broad access from that single point. Zero trust limits what any one compromised account or device can actually reach.

Both. Nobody on our team gets standing access to a client system by default, including us. Access is granted for what a specific task requires and expires when the task ends, the same principle applied internally that we build into client systems.

No, and a VPN can be the opposite of zero trust if it grants broad network access once connected. Zero trust checks every individual request against what that specific user or device is allowed to do, rather than granting wide access because a connection was established.

A dispatch and hours-of-service compliance platform for US carriers, covering all 48 contiguous states. It handles the compliance side of running a fleet: driver hours, duty status and dispatch, in one system rather than several that do not talk to each other.

It is a client platform. We built it and we operate it day to day, which is why it appears in our own proof numbers, but it is not something we co-founded the way Varmont or Trust Load are. We describe it the way we describe any client project: honestly, and with the client's permission.

Lighthouse is Google's own measurement of speed, accessibility, best practices and SEO, out of 100 each. We measure cetuspro.pro with Google PageSpeed Insights every day, on desktop and on a phone, on Google's own servers, so the numbers move from day to day; the date of the last run sits beside them. It is not a claim we make about ourselves: anyone can run the same test against cetuspro.pro and see the result.

Yes, across all 48 contiguous US states, which is the core of what the platform does. Dispatch and driver status sit alongside it, built as one system rather than a compliance add-on bolted onto separate dispatch software after the fact.

Units, tenancies, rent collection and maintenance requests, for a landlord or small property manager running a handful of units rather than a large portfolio. It replaces a mix of spreadsheets, WhatsApp threads and manual bank transfers with one system.

It is built for the scale a spreadsheet stops working at but an enterprise property platform is overkill for, a handful of units to a few dozen. A tenant paying rent, reporting a leak or renewing a tenancy is tracked in one place instead of scattered across separate tools.

It is in closed operational testing with limited participants, not live. A clickable demo is available to walk through how units, tenancies, rent and maintenance actually work together before it opens more broadly.

Yes, alongside Real Estate CRM. Both are candidates for licensing into other markets once they move past closed operational testing.

It keeps a record of every lead, listing and conversation in one place so nothing depends on one agent remembering it. Most CRMs are filing cabinets that charge rent, decaying the moment staff stop feeding them. This one is built to bring an agent work automatically rather than ask them to describe work they already did.

A public-facing listing marketplace connected to the same data the CRM already holds, so a listing entered once appears live without being re-entered into a separate website or portal.

It drafts listing descriptions, follows up on leads that have gone quiet, and surfaces which conversations need a human reply first, based on the same CRM data. It assists the agent's existing workflow rather than replacing the agent's judgment on a deal.

It is currently in build, not live. There are 30 trial places available, 6 already taken, with three months free for early participants. It is part of the white label pipeline alongside Micro Property Rentals.

Secureline (working name) is a Gigagrams platform for business calls, video and messages. Gigagrams builds it for small and mid-size firms in the United States. Its status is Final build before testing.

Secureline is for small and mid-size firms in the United States first. It joins calls, video and chat, so a team does not need to switch between apps. Our New Jersey office works across all 50 US states and Canada.

Secureline is built to SOC 2 requirements. It has not had a SOC 2 audit.

Its plan for encryption includes post-quantum encryption.

Secureline is in its final build before testing. It is not live, and it takes no users today. The name is a working name and may change.

An internal AI system that runs inside the platforms we build, handling tasks like drafting, prioritising and flagging that would otherwise need a person to do them manually every time. It is currently in training and is not deployed to clients as a standalone product.

No. TEZZ runs inside Gigagrams platforms only. Customers connect to it through an API from within a platform we build, never by deploying TEZZ itself onto their own infrastructure.

Yes. AI projects are built to Gigagrams protocols: zero trust, human in the loop, multi-agent. It answers only when the answer is verified, otherwise it asks a clarifying question; it never guesses. A model built for a client belongs to that client alone and is never trained on another client’s data.

No. A model built for a client belongs to that client alone and is never trained on another client's data. Nothing learned from one account crosses into another.

A multi-layer US logistics ecosystem we co-founded, covering loads, carriers, brokers, settlement and escrow in one system rather than several tools that do not share data. It is near MVP, with closed operational testing running now rather than a public launch.

No. It is in closed operational testing with limited participants, not live, and we are not publishing uptime or load figures while testing continues. We would rather say plainly where it stands than round it up to sound further along than it actually is right now.

We are a founding partner in the business, building the platform itself rather than being hired to build a website for someone else’s logistics company. It runs on the same infrastructure and engineering standard as everything else we operate day to day.

That is the specific problem Trust Load is built to solve: money moving between shippers, carriers and brokers with a system tracking who is owed what, rather than reconciliation happening after the fact across separate, disconnected tools nobody fully trusts.

An engineering and architectural consultancy, varmont.ae, that we co-founded rather than built for someone else. It runs 34 projects right now through the same Virtual Studio workspace we use to deliver every other project on this site, not a separate process.

We are a founding partner in the business, not a vendor who built its website. Varmont’s client delivery runs through our studio because we built it that way from the start, which is also why we can speak to how it performs with the same confidence we have about our own systems.

Both. It covers architecture and engineering consultancy together under one practice, which is also why we build dedicated pages for each as separate industries on this site: the two disciplines search differently even when the exact same consultancy delivers both of them.

A platform we build sends TEZZ a request and gets a result back, the same way a checkout page sends Stripe a payment request without ever running Stripe's own servers. Nobody installs TEZZ, runs it on their own infrastructure, or gets a copy of it to operate independently.

TEZZ runs on Gigagrams’ own systems only. AI projects for clients are separate, built to our protocols. Keeping TEZZ API-only keeps the data isolation and training boundaries intact, which get harder to guarantee the moment a system is handed off to run outside our own infrastructure.

Yes, from within a Gigagrams platform, through that platform’s own API, rather than as a general-purpose API sold on its own.

No. The request and response pattern is how most production AI features work day to day, regardless of vendor. What API-only actually restricts is who can run TEZZ independently, not how a platform built on it functions for the end user.

Where the boundaries sit: which data a model can see, whether that data ever mixes with another client's, and where the system physically runs. Two AI products can use similar underlying technology and still differ completely on these boundaries, which is what actually determines the risk to a client's data.

No. A model built for a client belongs to that client alone and is never trained on another client's data. Nothing learned from one account crosses into another, by design rather than by policy alone.

Inside Gigagrams platforms only. It is never deployed onto a client's own infrastructure, and customers reach it exclusively through the platform's API rather than running it themselves.

Yes. It follows the same zero trust and least-privilege thinking applied to access control generally: nothing gets broader reach than the specific task requires, whether that is a person's login or a model's training data.

Which tasks it handles on its own, which it flags for a person, and where that line sits. A system that cannot describe that line is a black box, whatever it is built on. TEZZ is scoped to routine, repeatable tasks, with anything ambiguous or judgment-heavy routed to a person.

On routine, repeatable tasks, drafting and flagging, yes, consistent with minimum human input as an engineering principle. Anything that changes something materially, or that a reasonable person would want to weigh in on, is routed to a human rather than actioned automatically.

Minimum human input means removing repetitive manual work, not removing judgment from decisions that need it. The two get conflated often, and treating them as the same thing is how an AI system ends up making calls nobody actually reviewed.

Within a Gigagrams platform, decisions TEZZ makes are attributable to a specific action taken at a specific time, consistent with the audit logging principle applied across our systems generally.

We build and operate the platform. A regional partner licenses it under their own brand and domain, runs the commercial business in their country, and keeps the customer relationship. The partner carries no build cost, no engineering risk and no maintenance team, and we do not compete inside their agreed country.

A franchise sells you an operating manual and takes a cut of everything. A reseller agreement gives you someone else's branded product to sell. Here the platform carries your brand, your domain and your pricing, the customer relationship is entirely yours, and we take no role in how you run the business.

You do. Customer records, transactions and content generated in your country belong to your business and can be exported in full at any time. We process that data to run the platform and for nothing else. One partner's data is never used to improve another partner's business.

You take your data with you in full, in standard formats, and the agreement ends on the notice period written into it. There is no penalty clause designed to trap you. If the partnership stops working for either side, the exit terms are agreed at the start rather than argued about later.

Yes. If you know a market well and the platform for it has not been built, we will research it. We study market size, money flow and regulation before writing any code. Most proposals fail that stage, which is the point. Where the research supports it we build the platform, you license it, and you get the first licence in your country.

An ongoing arrangement agreed per platform and per country. The figures depend on market size and exclusivity, so they are set in the partnership discussion rather than published. You carry no development cost and no engineering salaries.

Branding, language, currency, pricing rules and local integrations are all configured for your country. The underlying product is shared, which is exactly why it stays maintained and keeps improving. If you need something built specifically for your market, that is a separate conversation and often a good one.

The agreement includes source escrow and a continuity clause, so a partner is never left with a platform nobody can run. The full terms are in the partnership agreement and we are happy to discuss them before you sign anything.

Not yet. It is in build, not live, so there is no running platform or country to license today. This page describes what it does and invites registered interest, not a live product.

Multi-vendor floristry: same-day delivery cutoffs, delivery slot booking, occasion calendars, and split settlement between the individual flower shops selling through it. It is scoped for markets where Eid and Ramadan drive a large share of annual demand, not a generic flower store template.

Nothing binding. It puts you in the conversation before the platform is live, and it tells us which markets want it first. The full research-and-commitment process for a country starts once there is a specific market and partner to evaluate.

The same research any country goes through: market size, money flow, regulation and realistic customer acquisition cost, evaluated for a specific market with a specific, committed partner attached to it. Registered interest without a committed partner and market is a signal, not a trigger on its own.

Twenty minutes, usually the same week you reach out. Bring the platform you are interested in, the country you have in mind, and what you already run there today. We will tell you on the call if it is obviously not a fit, rather than let a process run for weeks toward an answer we already know.

Market size, how money actually moves in that sector locally, regulation and payment rails. Two weeks is enough time to check these properly rather than skim them. We are deciding whether to commit engineering time and our own operating standard to a country, so this step is genuinely diligent, not a formality before an inevitable yes.

The area covered, the ongoing arrangement, exit terms and the notice period, all specific to the platform and market discussed in the first two steps. Nothing is agreed verbally and confirmed in writing later. It is written first, and both sides sign the same document.

Yes, at step five: a soft launch with a controlled first group of customers, before opening more broadly. Problems surface with people who will forgive them, and you have direct access to the engineer running your instance during that period, not a support ticket queue.

It is in closed operational testing with limited participants, not live. A clickable demo is available so you can walk through how units, tenancies, rent and maintenance actually work together before deciding on a country, rather than evaluating it from a description alone.

Units, tenancies, rent collection and maintenance requests, for landlords and property managers running a handful of units to a few dozen, the scale a spreadsheet stops working at but an enterprise property platform is overkill for.

The first licence in your market and real input into what closed operational testing surfaces before it opens more broadly. Closed operational testing exists specifically to catch what only real usage reveals, and an early partner is part of that process rather than joining after it is finished.

Structurally yes, a licence for your country under your own brand, with an ongoing arrangement agreed per market. Both are part of the same white label pipeline, at slightly different stages: this one is in closed operational testing with limited participants, Real Estate CRM is in build with early trial agencies already on it.

The term is set in the partnership agreement itself, agreed at the same time as the country and the pricing, because a young market and a mature one genuinely call for different terms. It is written into the contract before either side signs, not left open-ended or decided later.

You do. Customer records, transactions and content generated in your country belong to your business and can be exported in full at any time. We process that data to run the platform and for nothing else. One partner's data is never used to improve another partner's business.

You take your data with you in full, in standard formats, and the agreement ends on the notice period written into it. There is no penalty clause designed to trap you. If the partnership stops working for either side, the exit terms are agreed at the start rather than argued about later.

The agreement includes source escrow and a continuity clause, so a partner is never left with a platform nobody can run. The escrowed code and documentation release to you under terms set out in the agreement, so your business does not simply stop because ours did.

It is currently in build, not fully live, though it is running with early trial agencies: 30 trial places, 6 already taken, with three months free for early participants. A white label licence taken now launches as an early partner, not on a finished, mature product, and that trade-off is worth understanding before committing.

It keeps a record of every lead, listing and conversation in one place, connected to a public listing marketplace so a listing entered once appears live without being re-entered elsewhere. An AI copilot drafts listing descriptions and follows up on leads that have gone quiet, working from the same data rather than a separate tool bolted on.

The first licence in your market and a genuine say in what gets built next, since the roadmap is still being shaped by exactly this kind of real usage. An early partner is closer to shaping the product than one joining once it is already mature and set.

The trial places are for an individual agency using the CRM directly. A white label licence for a country is a different, larger commercial relationship: you license the whole platform, under your own brand, to run in your market, rather than using it as one agency among many.

Yes. If you know a market well and the platform for it has not been built, we will research it. We study market size, money flow and regulation before writing any code. Most proposals fail that stage, which is the point. Where the research supports it we build the platform, you license it, and you get the first licence in your country.

It goes into the same first conversation as any other white label enquiry: a short call to understand the market and what you already know about it, then, if it holds up, two weeks of research at our cost before anything is committed on either side.

Most markets someone proposes do not, on closer research, support a profitable platform once money flow, regulation and realistic customer acquisition cost are accounted for properly. That is the research doing its job. A proposal that survives it is a genuinely stronger basis for a platform than one built on optimism alone.

The first conversation and the research that follows establish who is actually being evaluated for that country. Submitting an intake promptly, with specifics rather than a vague idea, is the practical way to be the one in that conversation.

Whatever is agreed and written into the partnership agreement before launch, most often a country, sometimes a defined region within a very large market. There is no default size. It is set explicitly for the platform and market discussed in the first conversation, not assumed from a template.

It covers both, and the agreement says so explicitly rather than leaving it ambiguous. A dispute over whether another partner's website reaching into your area violates your exclusivity is exactly the kind of thing that should never come up, because it was already settled in writing before either partnership started.

No, not on day one. Exclusivity is granted for a specific, defined area you can actually operate in, not a broad claim on markets you have not yet demonstrated you can run. A strong track record in one area is the realistic path to being offered more.

That is a new conversation, evaluated the same way the first one was: market research, written terms, its own arrangement. An existing partnership in good standing is a genuine advantage in that conversation, but it is not an automatic right.

A running system. The code is built, maintained and updated on your behalf, and it is held in source escrow so you are never left stranded if we stop operating, but day-to-day you are not editing it yourself. If owning and modifying source code directly is what you actually want, a white label partnership is not the right fit, and a custom build is.

The actual operating interface of the platform itself, the tool your own staff log into every day to do the real work: agents managing leads and listings, or a property team managing units and tenancies, depending on which platform you license. It is your operational tool, not an engineering dashboard, and your customers and staff only ever see your brand on it.

Yes, and it becomes a separate conversation. If it is broadly useful, it can go on the shared platform roadmap and reach every partner once shipped. If it is specific to your market, it is scoped and priced as its own piece of work, distinct from the standard licensing arrangement.

We are, entirely. Servers, monitoring, security patching and incident response stay on our side of the line for the life of the partnership. You never hire an engineer, never get paged at three in the morning, and never have to decide which server to scale.

A shared workspace: one account you and our team both use. Steps, documents, sign-offs and comments live in one place, and either side can check them at any time.

By email, Google, or another provider where possible. Use the Sign in to the Studio button on this page.

Estimates and agreements are signed digitally inside your own account, not sent back and forth by email. The signed version stays in the workspace, with the milestone it belongs to.

A maximum of three review rounds per milestone, agreed in advance and written into the contract. The workspace shows how many are used.

No. It is an illustrative walkthrough of the same screens every project uses, built from the real components, with the client name and content replaced. It is read-only: nothing here is a live account you can log into.

A real workspace holds a specific client's documents, comments and sign-offs, which is not ours to publish. This page shows the same structure and the same screens without exposing anyone's actual project.

No. It is a public page, open to browse without logging in or registering anything.

A workspace is created automatically once a project starts. There is no separate signup or trial account to request in advance of that.

No. It runs in a browser, reached by logging into your own account with email, Google, or another provider where possible. Nothing to download or configure.

You use one of the three review rounds attached to that milestone, agreed before work started and visible in the workspace as you use them. A disagreement gets resolved inside the process, not as an unplanned extra round nobody priced in.

You and the specific team members assigned to your project, consistent with the zero trust principle applied everywhere else: nobody gets standing access to a client account by default.

Documents and sign-off history remain accessible in your account. The workspace does not disappear the moment a project ships, since a care plan or a future milestone may reuse it.

One pass of feedback on a milestone: a client reviews what was delivered and requests changes, the team makes them, and that is one round used. Three are available per milestone, agreed before work starts.

"Unlimited revisions" sounds generous and is not. It usually means a project drifts indefinitely while the team absorbs the cost quietly, or a limit gets enforced anyway once patience runs out, just never written down. Three, agreed in writing before the work starts, protects a client's timeline and our schedule equally, because both sides know the number in advance.

It is scoped and priced separately, agreed explicitly rather than absorbed silently. That keeps the first three rounds meaningful: real budget was allocated to get feedback right within them, not to defer decisions past them.

No. Rounds are attached to the milestone they were agreed for, not banked for later use elsewhere. A milestone approved on the first pass simply used one of the three available, not all of them.

A page written directly in Arabic or Russian by someone fluent in that language and its business register, rather than an English page run through a translation tool or a literal word-for-word conversion. The structure, tone and word choice are native to the language, not carried over from English.

A reader in the Gulf can tell within a sentence whether Arabic copy was written natively or translated. A translated headline reads stiff or slightly wrong in ways a native speaker notices immediately, and that reads as a business that did not invest in the market it is addressing.

The tagline is a mark, not a sentence to be understood word for word, the way a logo is not translated. It stays consistent across every language version so it functions as an identifier rather than a phrase competing for meaning against the localised copy around it.

Not where English is the professional norm locally. A term like "API" or "checkout flow" often stays in English inside Arabic or Russian copy because that is how professionals in the field actually use it, and forcing a translation would read as less credible, not more.

A native writer composes the copy directly in the target language, every component is checked against real text length in that language rather than an English estimate, hreflang tags are added so search engines serve the right version to the right audience, and RTL layout is applied if the language reads right to left.

Technically yes, but that produces the machine-translated or literal result this site avoids. Adding a language properly means writing it natively and checking every component still works with that language's actual text length and direction, not pasting a translated string into an English-shaped template.

Only right-to-left languages, Arabic being the relevant one here. A left-to-right language like Russian needs native writing and text-length accommodation, but not the bidirectional layout work Arabic requires.

It depends on how many pages exist and how many of the components have already been checked against that language's text length and direction. Scoped per project during the technical audit rather than quoted as one fixed timeline for every site.

Right-to-left, bidirectional layout. Arabic text reads right to left, but numbers, prices and embedded Latin terms still read left to right inside it, which is why it is called bidirectional rather than simply reversed. The whole interface mirrors, not just the sentence direction: navigation, icons, form fields, the reading order of a card.

Flipping direction with a single style rule reverses text but leaves icons pointing the wrong way, numbers reading backward, and form fields misaligned with their labels. Genuine RTL support mirrors the logical structure of the page, not only the visual direction of the text.

The same structure and components, mirrored correctly rather than redesigned. Introducing separate components for the Arabic version would mean maintaining two different layouts instead of one that correctly supports both directions.

They stay left to right inside the right-to-left flow, which is standard practice and matches how Arabic is actually written and read. A price does not reverse its digit order just because the surrounding text direction has changed.

Cyrillic text typically runs noticeably longer than the equivalent English for the same meaning, which can break layouts tuned tightly around English word lengths. Word order, formality and business register also differ, so a literal translation reads as foreign even when every word is technically correct.

A button, a heading or a card built to fit English copy exactly can overflow, wrap awkwardly or truncate when the same sentence runs longer in Cyrillic. Components have to accommodate that difference rather than assume every language fits the same space.

Business Russian used in professional contexts is broadly consistent across CIS markets, though register and specific terminology can shift by country. Written natively by someone fluent in the target market avoids the generic, slightly-off register a direct translation tends to produce.

Where English is the professional norm, yes, the same principle applied to Arabic copy. A term like "checkout flow" or "API" often stays in English because that is how professionals in the field actually use it locally, rather than being forced into an awkward translation.

Because a page that claims to win on everything is not useful to the person reading it, and it reads as advertising rather than information. Every comparison here names the specific situation where the alternative is genuinely the right call. If that situation is yours, we would rather you know it from us than find out after paying for a rebuild you did not need.

The technical differences are true everywhere. The pricing, regulatory notes and local examples are scoped to what we actually see working in Dubai and the wider UAE market, since that is where we operate and where we can speak from direct experience rather than general assumption.

Read the "where the alternative wins" section on the relevant page first. If your situation matches it, the alternative is probably the right answer and a rebuild is not. If it does not match, the free technical audit is a faster way to get a specific answer than reading eleven more pages.

Ask. The technical audit covers the same ground for your specific situation: what you have now, what it actually costs, and an honest answer on whether changing it is worth it.

No. It is a mature, reliable platform for a standard catalogue, and for validating a product idea fast it is often the right call. The problem shows up with catalogue complexity: unusual variant structures, made-to-order items, or a checkout that needs logic the platform was not built around.

It assumes a fairly standard variant structure. A fragrance with size and concentration tracked independently, or a made-to-order item with a delivery window, often needs a custom checkout built around the product rather than the platform's assumptions.

No, Shopify Payments avoids the additional transaction fee, but it is still a percentage per sale indefinitely, which a one-time custom build does not carry.

Between 5,500$1,500€1,321 and 36,700$10,000€8,807 depending on catalogue size and variant complexity, the same range as any custom ecommerce build here, delivered in 7 days.

No. It runs a large share of the web reasonably well, and for a simple site with no growth plans it can be the right call for years. The problem is specific: it shows up at scale, with ecommerce, booking, multi-language content, or anything needing real data structure rather than pages of text.

Plugins accumulate over years, each adding its own code, database queries and update schedule, until page weight and attack surface have both grown past what anyone intended. It rarely starts slow. It gets there gradually.

Yes, done properly. Every URL is mapped to its new address, and Search Console, Analytics and Tag Manager access is used to confirm nothing that currently ranks disappears in the move.

That page makes the full technical argument. This one is the shorter, side-by-side version, for a faster decision.

No. It is a genuinely fast way to test whether a two-sided marketplace idea has real demand, and for a standard rental or booking shape it can be exactly the right first step.

Escrow is holding a payment in a neutral place until an agreed condition is met, rather than releasing it to the seller the moment a buyer pays. A no-code template ships one version of that logic. A marketplace that needs a different split, schedule or reserve rule needs it built specifically.

Yes, and it is a common path: validate the idea on Sharetribe, then move to a custom build once the payout, settlement or dispute logic the business actually needs outgrows the template.

Yes. Trust Load, a US logistics marketplace we co-founded, runs on a custom escrow and settlement model, currently in closed operational testing with limited participants.

Not quite. Most agencies are priced to cover a wider overhead, more account management layers, more specialists on the bench, across many concurrent clients. We run one project at a time inside a fixed price range, which is a different cost structure, not a bigger or smaller one.

When the product needs someone embedded daily, indefinitely, shaping decisions as they come up in real time. That ongoing presence is a genuinely different thing from a scoped build, however well the build is delivered.

It is yours completely: code, server access and data, from handover. There is no proprietary framework or licensing dependency written into what we build.

A fixed range for the defined scope: 5,500$1,500€1,321 to 36,700$10,000€8,807 for a website, from 15,000$4,084€3,597 for a platform; marketplaces priced per project. No retainer, no ongoing headcount, no hourly billing.

No. It is a running product: real data, real flows, and real payments where the idea needs them, not a series of screens that look right but do nothing underneath. A mockup tells you whether people like the design. An MVP tells you whether the idea holds.

It becomes the starting point for the full build, scoped properly once you know what actually needs to exist. It is not thrown away, it is the first real data point for what comes next.

Yes, when the idea is already validated by other evidence, existing customers, a proven business elsewhere, a clear mandate, skipping straight to a full build is the honest, faster path.

An MVP is priced individually and sits well below full platform cost, typically ready in two to three weeks. A full build starts from 15,000$4,084€3,597, with an MVP-equivalent stage taking 2 to 6 weeks within it.

It is a real, fully functional web app that behaves like an installed one: full-screen, installable, works offline for loaded content, and can send push notifications. What it does not get is OS-level hardware access a browser cannot reach.

A service worker, a small script the browser runs in the background, caches what has already been loaded, so the app still opens and shows recent content without a connection, rather than a blank error screen.

Included by default, within the 5,500$1,500€1,321 to 36,700$10,000€8,807 website range, not discovered as an add-on afterward.

When a specific device feature required by the product is not exposed to browsers at all. That is a narrower case than most projects assume, which is why native is scoped deliberately here rather than assumed.

The free technical audit answers this directly: it identifies whether the site's problems come from the platform itself or from something cosmetic sitting on top of a sound foundation.

Sometimes, if the audit or the redesign work surfaces a platform-level problem that was not visible at first. That gets flagged honestly before continuing, not discovered as a surprise afterward.

We say so before doing the work. Optimising the surface on top of a fundamentally slow or insecure platform buys a few months at best, and the underlying problem returns.

No, provided it is done properly. Every URL is mapped to its new address, and rankings usually recover within two to four weeks and often improve, because the new platform is faster and cleaner for search engines to read.

Not inherently, but the failure mode is different and more damaging if it happens: every query has to be scoped correctly to the customer making it, enforced in the application and database layer. A bug in that scoping is the single most damaging failure a multi-tenant system can have, which is why it is tested deliberately.

Yes, that is a common pattern: build multi-tenant by default, and offer single-tenant as a specific arrangement for a customer whose contract or regulator genuinely requires it.

One set of infrastructure serves every customer, so adding the hundredth customer costs a fraction of what standing up a hundredth isolated instance would. That saving compounds as the customer count grows.

No. The application code is the same, deployed as its own running instance per customer, not maintained as a fork that would drift apart over time.

Not inherently, but it has more attack surface than a static site by design: a database and an admin login are both things an attacker can target, and a CMS platform's own updates have to be kept current to stay safe.

Yes, a headless CMS or a lightweight custom admin can sit in front of a static build, giving editors a familiar interface while the public site stays pre-built and fast. It is a deliberate addition, not the default.

Because most business sites here change content occasionally, not constantly, and the security and speed trade is worth it for that pattern. Where a genuinely high-frequency publishing need exists, that gets scoped and built for specifically.

Both fall in the same 5,500$1,500€1,321 to 36,700$10,000€8,807 range for a comparable site. The real cost difference shows up afterward: ongoing hosting, patching and plugin maintenance on a CMS, versus a few dollars a month and no maintenance on a static build.

Not worse, different. For domestic-only AED volume with a straightforward checkout, a local gateway can be the more economical and operationally simpler choice.

Because payment gateways fail quietly, and a card type, an amount threshold or a regional rule causing a decline is a lost sale the merchant never learns about. Stripe resolves those cases in milliseconds and handles single and multi-vendor settlement properly.

Yes, some businesses run a local gateway for domestic cards and Stripe for international ones. It adds integration complexity, and is only worth it when the split volume genuinely justifies maintaining two systems.

Third-party payment services are billed at cost, never marked up. Integration is scoped as part of the build, whether the gateway is Stripe, a local processor, or both.

We build and operate the platform. A regional partner licenses it under their own brand and domain, runs the commercial business in their country, and keeps the customer relationship, with no build cost, engineering risk or maintenance team of their own.

The partner does. Customer records, transactions and content generated in their country belong to their business and can be exported in full at any time.

That is a separate conversation, and a reasonable one. The white label agreement includes source escrow and a continuity clause specifically so a partner is never left dependent with no path forward.

From 15,000$4,084€3,597, with an MVP in 2 to 6 weeks. A marketplace is priced per project, depending on payment complexity and the number of sides involved.

A visual, drag-and-drop tool for arranging a page without writing code: Elementor and Divi on WordPress, or the built-in editors inside Wix, Squarespace and Webflow. It generates the HTML and CSS behind the scenes so a person can move blocks around visually.

A page builder cannot know what a person will drag next, so it wraps every element in extra containers to stay flexible for any arrangement. A heading that needs one tag in hand-written code often sits inside four or five nested wrapper elements a page builder adds defensively.

It shows up as more DOM nodes for the browser to build and more CSS to load and apply, both of which slow down rendering. Our own performance target keeps every page under 1,400 DOM nodes; a page-builder page frequently carries several times that for the same visible content.

For a non-technical person prototyping a rough layout privately before handing it to a developer, sure. Not for a public-facing production page, where the generated markup becomes the thing actually shipped to every visitor.

No, it runs reliably for a huge number of stores. The issue is not reliability, it is what running a store on it costs indefinitely: a subscription, a transaction fee on every sale, and an app stack that tends to grow rather than shrink over time.

For a small catalogue with standard products and no unusual variant or fulfilment logic, it can be fast to launch and perfectly workable for years. We will say so rather than sell a custom build nobody needs.

Three fees, all recurring: the platform subscription, a transaction cut on every sale unless the store uses Shopify's own payment processor exclusively, and paid apps for whatever the base platform does not do natively, which tend to accumulate rather than get pruned.

"Patisserie ecommerce" in our published proof numbers moved from 28 to 98 after a custom rebuild, 11 plugins down to a purpose-built checkout on Stripe. We do not have a Shopify-specific before-and-after on this site yet; when one exists, it will be published here.

A prospective client who recognises themselves in one of these four saves both sides a conversation that was never going to end in a project. That is worth more than the small number of enquiries this page might discourage.

It means these four are not edge cases we occasionally accommodate under pressure. If your situation is genuinely different from all four, the fastest way to find out is to ask, not to guess from this page alone.

No. That list is about what we refuse to build for, regardless of who is asking. This page is about the buyer's actual need, regardless of industry.

The core software is maintained and patched regularly. The risk sits in what gets installed on top of it: plugins, each one separately maintained code with its own update schedule, and some of them abandoned entirely while still running on live sites.

No. It runs a large share of the web reasonably well for what it was designed for: publishing content through an interface a non-technical person can use. The mismatch shows up when a business outgrows content publishing and needs real data structure: ecommerce with variants, multi-language done properly, a booking system with deposits and no-shows.

For a very simple brochure site with a handful of pages and no growth plans, it can be cheaper and perfectly fine for years, and we will say so rather than sell a rebuild nobody needs.

Panda ELD, audited 14 August 2026 before work began: WordPress, F-grade security headers, 34 out of 100. Shark Jet Ski: WordPress, 4.1MB homepage, scoring 31, rebuilt to a static site scoring 100 on mobile, measured 9 October 2026. Both scores are published and testable by anyone.