Building a company website and a product landing page
A company website explains who you are and what you do, while a product landing page leads the visitor to a single action: download the app, open the web version or submit a request. A good result rests on a few engineering decisions: a separate URL for every language, right-to-left layout for Arabic, fast loading, correct SEO markup, analytics set up for the laws of the audience’s country, and a layout that works equally well on a phone and a computer.
Company website vs. product landing page
A company website answers the questions "who are you, what do you do and how do I reach you". It holds service pages, legal details, documents, answers to common questions and articles. People use it in different ways: some look for contacts, some vet the company before a deal, some arrive from search on a specific article.
A product landing page works differently. It has one job: get the visitor to a specific action. For an app, that is usually downloading the installer, signing in to the web version, or sending a request when the product is sold through a conversation. Anything that does not support that action is noise on a landing page.
| Company website | Product landing page | |
|---|---|---|
| Main goal | Explain the company and what it does | Lead to one action |
| Who visits | Partners, clients, candidates, search traffic | People interested in a specific product |
| Structure | Many sections and internal links | One scenario from top to bottom |
| Main button | Contact us, send a request | Download, open the web version, send a request |
| How often it changes | Less often, as the company grows | Together with product releases |
Most businesses need both: the company site builds trust and search traffic, and product pages turn interest into installs or requests. If the product is still an idea, start with one scenario, as described in the guide MVP development: where to start.
The building blocks of a product page
An app landing page has a fairly stable order that helps visitors quickly decide whether the product fits them. You can adapt it to the task, but without these blocks a page usually stops making sense.
- Hero section: what the product is, who it is for, and the main call to action.
- A short value statement: which problem the product solves and how that differs from the usual way of doing it.
- The interface: screenshots or live examples of screens on a phone and a computer.
- Features: a handful of concrete capabilities, no vague claims.
- Platforms: macOS, Windows, the web version and mobile apps, with download and sign-in buttons.
- Security and privacy: how user data is handled.
- FAQ: short answers to whatever stops people from deciding.
- The main call to action repeated at the bottom, plus contact details for requests.
It is best to have the copy for these blocks ready before layout begins. A convenient way is to write it together with the page requirements, as explained in how to write a software requirements brief.
Multilingual sites: a separate URL for every language
If the site targets several markets, languages should be part of the architecture from day one. A translation bolted on just before a market launch almost always breaks the layout, confuses search engines and adds manual work to every update.
A few rules that save time over the whole life of the site:
- Copy is stored separately from code, one set per language. Developers change the layout, editors change the text, and they do not get in each other's way.
- Each language version has its own URL rather than swapping text on a single page. That way a search engine can see the right version and show it to people in the right country.
- Language versions are built from a single source by a generator. A change in the shared part reaches every language at once, so versions never drift apart.
- The visitor's choice is remembered: once they switch language, the next pages open in that language too.
- There is a clear fallback language for missing translations instead of blank spots on the page.
A translation should read like native copy, not a word-for-word rendering. Headlines, buttons and hints in Chinese or Arabic are often structured differently from English, and that has to be considered at the mockup stage: line length, wrapping and button sizes.
Arabic and right-to-left (RTL) layout
Arabic is read from right to left, so the interface is mirrored: the menu, column order, back and forward arrows, text alignment. Technically the page gets a right-to-left writing direction, and styles use logical properties such as the start and end of a line instead of left and right. The same layout then works correctly in both directions.
What usually needs separate attention:
- Directional icons such as arrows, next buttons and progress indicators must be flipped, while logos and photos stay as they are.
- Mixed text: Latin names, email addresses and numbers inside an Arabic sentence must display in the right order.
- Fonts: Arabic script has its own line height and weight requirements, and a Latin font will not do.
- Animations and sliders: the direction of scrolling and of elements appearing changes as well.
The Arabic version has to be checked by eye on real screens, not just by the absence of code errors: a reversed arrow or a jumbled phone number is visible at once.
Page speed
Visitors decide whether to stay within the first few seconds, and search engines take speed into account as well. On marketing sites most of the delay comes not from the server but from heavy images, fonts and third-party scripts.
- Images use modern formats and come in several sizes: a phone does not need an image made for a wide monitor.
- Everything below the first screen loads as the visitor scrolls.
- Only the font weights in use are loaded, and text is shown immediately without waiting for fonts.
- Scripts do not block rendering: the first screen appears before the interactive parts finish loading.
- Third-party resources are kept to a minimum, since each adds delay and risk.
- Static files are cached, and a version tag changes when files are updated so visitors get the fresh copy.
Measure speed on a phone over an average mobile connection, not only on the developer's workstation.
SEO markup: hreflang, Schema.org and the sitemap
For a search engine to show a multilingual site correctly, it has to be told explicitly what each page is. Visitors never see this part of the work, but it decides whether the site gets found at all.
| Element | What it does | What to check |
|---|---|---|
| title and description | The headline and snippet in search results | Unique for every page and language, main keyword first |
| hreflang | Links the language versions of a page | Links in every direction, including the page itself, plus a default version |
| canonical | Points to the primary URL of a page | Matches the real URL of the language version |
| Schema.org | Describes what is on the page: organization, product, questions and answers | Data in the markup matches the visible text |
| Sitemap | A list of pages to crawl | Only live URLs, no closed or draft pages |
| Closed pages | Keep unfinished pages out of the index | Coming-soon and service pages are marked noindex |
Plan clean URLs without unnecessary extensions, and redirects from old links if the site is moving. Schema.org markup is especially useful for a questions-and-answers section, because a search engine can show the answer right in the results.
Analytics and the laws of your audience’s country
Analytics is set up according to the laws of the countries where the site’s audience lives. Some jurisdictions, such as the EU, require explicit consent before any trackers or ad tags run. In others, a cookie notice and a clear privacy policy are enough. We make this decision together with you at the start of the project.
- The list of audience countries decides whether you need a consent banner or a notice.
- Where the law requires consent, trackers and ad tags are not loaded until the visitor agrees.
- Analytics scripts are loaded only from allowed sources.
- The privacy policy explains what is collected and why, in every language of the site.
This keeps analytics lawful in every market, and you can see which pages and buttons lead to downloads and enquiries.
Connecting the page to the app: download, sign-in and requests
An app landing page is the entrance to the product, so its buttons have to work flawlessly. There are three main scenarios.
Download buttons for macOS and Windows
The page can detect the visitor's operating system and offer the right installer straight away, with links to the other versions next to it. Installers should be signed so the system does not alarm users with warnings, and the app should be able to update itself.
Signing in to the web version
People who do not want to install anything need a clear button to open the web version. Sign-in and registration should lead into the app itself, not to a separate account area on the marketing site, otherwise users end up with two accounts and confusion.
Requests
If the product is sold through a conversation, the request form should be short, validate its fields on the server and deliver the request to the team right away. After submitting, the visitor sees what happens next and when they will be contacted.
Responsive design and the JEEKSSHIRE 24 example
Most visitors arrive on a phone, but the decision to buy or install a desktop app is often made at a computer. So the page is designed for both screens from the start: one column, large buttons and short blocks on a phone; more white space, live interface examples and tables on a computer.
Our own site is built this way. The JEEKSSHIRE 24 home page runs in Russian, English, Chinese and Arabic with right-to-left layout; language versions are generated from a single source, each has its own URL, hreflang, Schema.org markup and a sitemap, and analytics track enquiry goals. The Wallet and Legal landing pages with downloads for macOS and Windows and sign-in to the web version, the custom software development page, the guides section and Answers were built by the same team.
If you need a company website or a product page, see how we work on the custom software development page, and read how to accept a software project to know what to check at handover. Describe your task in the request form: what the product is, which markets it is entering and what action the visitor should take.
Pages for the App Store and Google Play: privacy, terms, support
If the product has a mobile app, the website is needed for more than marketing. App stores ask for links to pages that must be publicly available and always working.
- Privacy policy: what data the app collects, why, and how users can manage it. Both the App Store and Google Play require a link to it.
- Support page: how to contact the team and where to find answers to common questions. For the App Store, its address is provided at publishing.
- Account deletion: if users can sign up in the app, Google Play asks for a web page where they can request deletion of their account and data.
- Terms of use: the rules for using the service, especially if the app has payments or subscriptions.
These pages should be available in every language the app ships in, and their addresses should stay permanent: a link in the store must not lead to an error after a website redesign. Policy texts are best reviewed by a lawyer. Preparing for release is a normal part of mobile app development.
How to show the product: screenshots, video and demo
Visitors decide within seconds, so the product's interface should be visible right away rather than described in words.
- Screenshots of the real interface, not abstract illustrations. Each one carries one idea: what the user does here.
- Device frames: a phone and a laptop instantly show which platforms the product runs on.
- A short video of the core flow without a long intro.
- A live demo or web version where people can try the product without installing anything.
- Screenshots in the page's language: in the Arabic version, with a right-to-left interface.
Do not show what the product does not have: a gap between expectations and reality leads to disappointment right after installation. If the product runs in a browser, the best way to show it is to let people sign in to the web version. That is how the Wallet and Legal pages work, for example: next to the downloads for macOS and Windows there is a sign-in to the web version. Products like these are built through web app development.
Frequently asked questions
Do I need a separate website for every product?
Not necessarily. A company website plus a dedicated landing page for each product, with its own URL and call-to-action buttons, is often enough.
Can I start with one language and add the rest later?
Yes, as long as copy is separated from code from day one and each version has its own URL. Then a new language means translation and review, not a layout rebuild.
What makes an Arabic version of a site difficult?
The interface has to be mirrored right to left, directional icons flipped, mixed text displayed correctly and suitable fonts chosen. All of this is checked on real screens.
Is consent required for analytics?
It depends on where your audience is. Some jurisdictions, such as the EU, require explicit consent before trackers run; in others a cookie notice is enough. We decide this together with you at the start.
What is hreflang?
It is markup that tells search engines that several pages are language versions of the same content. It helps people from search land on the page in their own language.
Can you improve an existing website?
Yes. We first look at how it works today, then propose a plan: what to fix first and what to leave as it is.
Landing page or multi-page website for a product?
For one product with one main action, a landing page is usually enough. A multi-page website is needed when there are several products or the audience needs separate sections: documentation, support, guides.
When should a product website be built: before or after the MVP?
A simple page with a description and a request form is worth launching before the first version ships: it helps test interest. A full website is easier to build once the product's core flow is clear.
Which pages are needed to publish an app on the App Store and Google Play?
At a minimum, a privacy policy and a support page, and for apps with sign-up, a page for requesting account deletion. Terms of use are often added as well.