Quotations list the types of websites by their finished shape: brochure site, landing page, online store, platform. What sets the cost, the timeline and the risk is a different question, namely what the site does with data. A site that serves pages prepared in advance, a site that receives a form, and a site that charges a card are three different systems even when they have the same page count and the same design.
This guide walks the boundaries between those functions and says, at each one, what actually enters your system: a database, user accounts, a payment gateway, an admin panel, hosting requirements, a legal obligation, and the indexing rules that decide whether the site appears in search at all.
Classify your site by function, not by appearance
The useful ordering is based on what happens after a visitor opens the page.
| What the site does | Its common name | What that pulls into the system |
|---|---|---|
| Serves content prepared in advance | Brochure site, landing page, blog | Content editing, pages built before the visit |
| Receives data from the visitor | Site with forms, booking page | Durable storage, server-side validation, somewhere your team reviews entries |
| Carries out a financial transaction | Online store | Payment gateway, order and stock state, tax documents |
| Gives every user an account and a permission | Platform, customer portal | Authentication, authorisation, isolation of each user's data |
| Hosts a full day's work | Web application, operations console | Background jobs, audit trail, deployment and monitoring |
Each row sits on top of the one above it rather than replacing it. A store is still a site that serves content and receives data; it adds the transaction. So "which type do I choose?" is not asked once. The real question is how far up you need to go right now.
The first boundary: when the site starts writing, not only reading
A contact form is the cheapest line in any quotation and the first thing that changes the nature of the project. Before it, the site reads files and displays them. After it, you own something that gets written, stored, reviewed and eventually deleted.
Three things appear here that a vendor rarely mentions. First, validating input in the browser is a usability feature, not protection: whatever the visitor sends reaches your server regardless of what the interface does. OWASP ranks injection third worldwide with more than 274,000 occurrences in the contributed dataset, and puts its leading cause in user-supplied data that the application does not validate, filter or sanitise.
Second, received data needs a place where humans read it, and that is the project's first real admin panel. Email is fine for ten messages a month and fails at fifty, because nobody can tell which ones were answered.
Third, a name and a phone number are personal data, and obligations begin that did not exist a day earlier: a lawful basis for collecting them, a retention period, and a response to a deletion request. What that turns into inside your database specifically is covered in our guide to customer data protection in Egypt and Saudi Arabia.
The second boundary: when the site takes money
Rules now apply that neither you nor the development team wrote. PCI DSS covers anyone who stores, processes or transmits cardholder data, and the merchant is required to attest to compliance annually, as Stripe's integration security guide explains (accessed 22 September 2026).
The practical gap between one integration and another is large. The same guide notes that touching raw card data on your own page can put you on the hook for over 300 separate security controls, while integrations that hand the card details straight to the provider, bypassing your servers, cut that obligation down. Ask whoever builds your store one question: does the card number touch our server at any point? The answer sets the compliance burden you carry every year. The guide adds two technical conditions: payment pages run on TLS 1.2 or later, and the only card details you may keep on your side are the brand, the expiry date and the final four digits.
The meaning of "database" changes too. A table of messages tolerates a mistake; an order has a state that moves, stock that decreases, a price at the moment of sale that must not drift afterwards, and a return that reverses all of it. Locally available gateways are compared in our guide to Paymob, FawryPay and InstaPay, and the build steps that follow the decision are in how to start an online store in Egypt.
Then comes the tax obligation. In Egypt, Minister of Finance decision 323 of 2022 obliged every Egyptian Tax Authority taxpayer to join the e-invoicing system by meeting three conditions: an electronic seal or signature, coding of goods and services, and electronic integration with the system. The e-receipt system for end consumers additionally requires being on the e-invoicing system first and then a mandating decision from the head of the Authority, and the Authority states that failing to comply carries the penalties set out in law (conditions and scope of the obligation, Egyptian Tax Authority, accessed 22 September 2026). Integration steps are in our Egyptian e-invoicing guide, and the Saudi counterpart in e-invoicing phase two.
The third boundary: when every user gets an account
Logging in is the easy part. The real work is in permissions: who sees what, who edits what, and what happens when someone changes a number in the URL to open another customer's record.
OWASP places broken access control first in its 2021 ranking with more than 318,000 occurrences, the most frequent item in the contributed dataset. Among the forms it lists: opening or altering another person's record simply by passing its identifier, API calls for POST, PUT and DELETE that carry no check at all, and an ordinary user acting with administrator rights.
The effect on the schedule is direct. Every new screen is tested once per role, not once. Three roles mean three times the test cases per feature, and that alone explains much of the price jump between "a site with an admin panel" and "a platform". The vulnerabilities that matter at this stage are covered in common website vulnerabilities, and the cases that break booking logic specifically in appointment booking systems.
There is a second effect that rarely reaches the plan: part of your site leaves search by your own decision. Google notes that pages unavailable without signing in are among those Googlebot does not crawl, and recommends they answer with status code 401 so the crawler understands they are not an error. In practice you now run two different jobs on one domain: public pages whose purpose is to be found, and private screens whose purpose is not to be.
When what you are building becomes a web application
The signal is not page count. It is that the visitor opens a screen to work in it for half an hour rather than read it for two minutes. A different family of requirements shows up: state that lives in the browser and is saved continuously, two people editing the same record at the same moment, jobs that keep running after the page closes (reports, notifications, integrations), and an audit trail that says who changed what and when.
Snaabble provides a tailored technical assessment to define the right stack & exact budget.
At this boundary, separating the front end from the back end becomes a real decision with a cost rather than a technical preference. When it is worth paying for, and what it adds to the invoice, is set out in React or Laravel? The real question is splitting the front end from the back end. If the broader question is web versus phone app in the first place, the criteria are in website or mobile app.
Rendering model: the difference that decides whether you get indexed
Google explains that Search works in three stages: crawling, then indexing, then serving results; some pages do not pass every stage, and there is no guarantee of crawling, indexing or appearing even when you follow the fundamentals. This is where an architectural decision usually taken without the owner in the room starts to matter.
On a site built on the server, the HTML response carries all the content, so a crawler reads it on the first request. In the app-shell model that draws the page in the browser, the initial HTML does not contain the actual content, and the search engine has to execute JavaScript to see it, as JavaScript SEO basics describes. Google does run JavaScript, using a recent version of Chrome, but the page enters a rendering queue that takes seconds and can take longer. That is why the same document recommends server-side rendering or prerendering, which is faster for users and crawlers alike.
Google adds a detail about other search engines: some may ignore JavaScript entirely and never see content generated by it. It describes dynamic rendering as a workaround it does not recommend, given the extra complexity and resources it demands.
Practical rules follow directly:
- Pages you rely on for marketing are delivered ready from the server. Screens behind a login can be built however suits your team.
- Links belong in an
aelement with anhrefattribute; Googlebot discovers nothing else. In-app navigation uses the History API rather than fragments after a#. - In single-page applications, a deleted product that returns an empty page with status 200 becomes a soft 404. The fix is either a redirect to a URL that answers 404 from the server, or injecting
noindexinto the page. - A store has structured data types of its own that Google names explicitly: BreadcrumbList, LocalBusiness, Organization, Product and ProductGroup.
As for the crawl-budget talk aimed at owners of small stores, it has a defined size. Google's crawl budget guide targets sites above one million unique pages whose content changes weekly, or above 10,000 unique pages changing daily; below that, keeping the sitemap current and watching the page indexing report is enough. What deserves attention in a mid-sized catalogue is something else: sorting and filtering pages that generate duplicate URLs for the same content, which the guide calls the factor you can most positively control. More on that side of the work in our SEO guide for companies in Egypt and the Gulf and website speed optimisation.
Hosting follows the function
A site serving pages prepared in advance needs file delivery, a TLS certificate and a distribution network. A site that receives data adds a database whose backups are actually test-restored rather than taken and forgotten. A site that sells or holds accounts adds a legal question: where your customers' data is stored geographically, and who may move it out of the country. That distinction is set out in detail in how to choose a hosting company.
The decision table
| What you want to do | The site you need, by function | What it brings with it |
|---|---|---|
| Be found and understood by people looking for you | Serves content | Pages delivered from the server, a content editor, no accounts; almost no compliance burden |
| Receive quote requests, bookings or job applications | Receives data | Durable storage, server-side validation, a review inbox for your team, a stated retention period, data protection obligations |
| Take payment online | Sells | Payment gateway, an integration where the card never touches your server, TLS 1.2 or above, order, stock and return state, e-invoicing |
| Let each customer sign in and see their own records | Accounts and permissions | Authentication and per-role authorisation, testing multiplied by the number of roles, part of the site deliberately outside the index (401) |
| Let your team do their daily work in the browser | Web application | Background jobs, audit trail, concurrent-edit handling, deployment and monitoring, and the front end/back end split decision |
Starting small and moving up later
Upgrading between these levels is possible, but it is not "adding a module". You are crossing a boundary, and new requirements arrive across the whole system. Three things asked for on day one make the crossing cheap: content held in a database rather than written into the pages, page addresses that survive the rebuild so you do not lose what Google has indexed, and your own ownership of the code, the data, the domain and the hosting.
Ask for the upgrade path in writing: what changes in the database when accounts are added, what happens to the existing URLs, and what gets rebuilt from scratch. A company that answers that clearly before the contract is less likely to surprise you later. The rest of the selection criteria are in how to choose a web design company in Egypt, and the line items behind the number in our website cost guide. If what you need is a single page for an ad campaign, its elements are in the landing page that converts.
The point worth keeping: do not buy the name of a type. Buy the function you need today, with a clear road to the next one.
If you are standing at one of these boundaries and cannot tell which side you belong on, write to us about what you want the site to do rather than how it should look. The Snaabble team comes back with an outline plan and a time and cost estimate inside 24 hours, at no charge and with nothing owed, from the web development services page.
Frequently asked questions
Does a site built with React or Vue show up in Google?
Usually yes, because Google executes JavaScript using a recent version of Chrome. The page does wait its turn in a rendering queue that takes seconds and can take longer, and some other search engines may ignore JavaScript and never see content generated by it. That is why Google recommends server-side rendering or prerendering for pages you rely on in search.
When do I actually need a database?
From the moment somebody writes something that has to persist: a form message, a booking, an order, an account. A site serving content prepared in advance needs a content editing tool, which is not the same thing as the database priced into a full system with related tables and test-restored backups.
I only have a contact form. Do data protection obligations apply to me?
A name, a phone number and an email address are personal data, and holding them requires a lawful basis for collection, a stated retention period, and a way to delete on request. The size of the obligation varies with your activity and the type and volume of data; the detail is in customer data protection in Egypt and Saudi Arabia.
How many pages make my site "large" in Google's eyes?
Google's crawl budget guide names two bands: more than one million unique pages whose content changes weekly, or more than 10,000 unique pages changing daily. Most company sites and mid-sized stores are far below that, and keeping the sitemap current while watching the page indexing report is enough.
Sources
- In-depth guide to how Google Search works, Google Search Central.
- Understand JavaScript SEO basics, Google Search Central.
- Dynamic rendering as a workaround, Google Search Central.
- Large site owner's guide to managing crawl budget, Google Search Central.
- Include structured data relevant to ecommerce, Google Search Central.
- Broken access control A01:2021 and injection A03:2021, OWASP Top 10 for 2021.
- Integration security guide, Stripe documentation.
- Conditions and scope of the e-invoicing and e-receipt obligation, Egyptian Tax Authority.
All links accessed on 22 September 2026.
