Launching Your App Blueprint
On The Marketplace

Looking to put your Backendless skills to use for some side cash? With the new Backendless Marketplace, you can create your own App Blueprints to list for sale to the Backendless community.

App Blueprints are fully-functional app or website templates in Backendless. Any Backendless user can build and list their own App Blueprint on the Marketplace. At this time, Blueprints can be listed for free. Listing for one-time fee is coming soon.

The following are examples of Blueprints that qualify*:

• Complete web app with frontend built in UI Builder and backend and database built in Backendless.
• Use-case-specific backend/database structure with backend automations. (A basic frontend is strongly recommended, or instructions for connecting one.)
• Simple, single-page landing page built in UI Builder. (Database-driven image & content delivery recommended; you can learn more about linking images to URLs in file storage here.)
• Complete web app frontend built in UI Builder and designed for integration with a coded backend/database. (Instructions should be provided for minimum backend setup.)

*All submissions are reviewed prior to publication. Backendless reserves the right to reject any submission for any reason; a reason will be provided for all rejections.

In this article, we will lay out the basic guidelines for listing an App Blueprint on the Backendless Marketplace. We will also provide formatting, style and content guidelines for the app’s Instructions document.

Minimum Requirements

Each App Blueprint submitted to the Marketplace will be reviewed by the Backendless team before publication. To give your submission the highest probability of acceptance, please follow the proceeding guidelines.

1. Provide a description and clear instructions for your blueprint
   The description to describe the app’s purpose, type, and general functionality. The instructions should adhere to the Instructions Guide below.
2. Remove any unnecessary data tables, folders and files
   All contents of the App Blueprint that are not standard with every Backendless app should have a specific purpose which should be described in the Instructions.
3. Make sure any left over data in the database is removed
   All data tables should be empty with the exception of 1-2 demo objects (only if absolutely necessary).
4. Make sure any image files referenced in the database and CSS extensions are referenced using relative paths
   For example, an image file URL should look like this /ui-builder/containers/default/styles/img/home/home-photo-bg.jpg. The URL should not include https://develop.backendless.com/[AppName].
5. Configure permissions
   If your application requires user registration and login, adjust permissions for the NotAuthenticatedUser security role. If any other permissions are adjusted from default or if other security roles are included in the Blueprint, include the purpose of such modifications in the Instructions.
6. Include push notification setup instructions (if applicable)
   If your application requires Android/Apple certificates for push notifications, make sure to describe it in the instructions and remove the certificates from your application.
7. Include Google Maps setup instructions (if applicable)
   If your application uses Google Maps API key, make sure to describe the setup process (described in this video) in the instructions and remove the API key from your application.
8. Clear custom domain(s)
   If your application uses a custom domain, make sure to remove it before publishing the app.
9. Clear and define custom SMTP server configuration (if applicable)
   If your application uses custom SMTP server configuration, make sure to clear it in your app and describe in the instructions the need for a custom SMTP server configuration.

App Blueprint Instructions

When publishing an App Blueprint to the Backendless Marketplace, you will create an instruction document for users that choose to use the template.

Follow the guide below to ensure that your Instructions’ format and structure matches that of other available Blueprints.

Formatting Guide

1. The file must be placed in the following path /instructions/instructions.md

2. The first line of the file must have the following format:

[//]: <> (/ui-builder/default/pages/home)

where home is the name of the “main page” of the Blueprint app. This line instructs Backendless Console to navigate to the main screen when the user opens the app in console. The name of the page is optional; if it is not specified, then the page marked as “home” will open.

3. Main title must be ### (H3). No HTML in titles (in any of them)

4. After the main title, add a description of the app:
– What it does
– Who it is for
– What functionality it contains
– What other tools it works with (if applicable)

5. After the description, include a “table of contents” using the following format:

The application consists of the following configurable sections:
- [Section 1](#section1)
- [Section 2](#section2)
- [Section 3](#section3)
- [Section 4](#section4)
- [Section 5](#section5)
- [Section 6](#section6)
- [Section 7](#section7)

where (#xxxxx) is a link to a section in the instructions doc

6. Every single section in the instructions should have the following formatting:

***
<a name="anchorName"></a>
#### Section Title

where:

• *** – adds a horizontal line <hr> at the end of the previous section
• <a name="anchorName"></a> – creates an anchor for linking from item 5 in this list
• #### Section Title – title of the section. Must be **** (H4)

7. Images used in the instructions should be placed into the /instructions/images/ directory.

8. When you reference an image in the instructions, use the following format:

<img width="100%" src="{{filesURL}}/instructions/images/topic.jpg" alt="Topics" />

where {{filesURL}} is an important element. It is needed for the “portability” of instructions – so that the instructions file can be opened in another app.

9. Do not use long text lines; wrap them at 130 characters (or less). For example:

10. Names of pages, database tables, database columns, IDs of components, anything that is identifiable, use the following formatting:

`someId`

This way, it will stand out to the reader that someId is something that they need to pay attention to.

11. The BACKEND and FRONTEND parts of the console are *sections*, not ~~tabs~~.