CodeCanyon ionWordPress - WordPress Plugin

CodeCanyon ionWordPress Setup and Testing Guide

CodeCanyon ionWordPress should not be treated like a typical WordPress plugin with a single settings page. It is better understood as a mobile template and source-code package that connects to a WordPress site and displays its content inside a hybrid app. That is why this guide focuses less on purchase flow or installation via the Upload Plugin button and more on the practical path: validate the site, prepare the API, configure the app, build a test version, and understand where to look when something goes wrong.

This article is intended for a content site owner, webmaster, or developer who already has the product archive and wants to evaluate safely whether it fits a real project. We will look at which ionWordPress capabilities are confirmed by public descriptions, which parts depend on the specific archive you received, why the old JSON API requires caution, how to validate WordPress output before building, and which alternatives are worth considering if you need a more modern approach.

One important piece of context: the public descriptions we found for ionWordPress and IonWordPress 3 describe a stack built around WordPress, Ionic, Cordova or PhoneGap, plus categories, pages, search, favorites, offline reading, push notifications, and appearance settings. At the same time, the official WordPress plugin directory shows that the old JSON API plugin was closed for security reasons. So the first decision before implementation is not "how do I build the APK faster," but whether the data source can be connected safely.

What this product actually does and where its responsibility ends

ionWordPress belongs to the class of "WordPress-to-app" solutions. A product like this does not magically turn a site into an app. It gives you a ready-made Ionic shell, a set of screens, navigation, styles, and integration points, while WordPress remains the content source. If the site publishes news, articles, tutorials, pages, or categorized posts, the app can display that content in a mobile interface. If the site depends on complex WooCommerce logic, private user areas, forms, bookings, or custom post types, you will need separate validation and possibly API customization.

Public descriptions of ionWordPress mention WordPress integration, HTML5, CSS and JavaScript, Ionic, AngularJS, Cordova or PhoneGap, appearance customization, menus, search, login and registration pages, detail screens, and ad integration. The IonWordPress 3 description also lists categories, pages, comments, favorites, offline reading, OneSignal push notifications, opening posts in the browser, fullscreen video, lazy loading, and Material Design. That information is useful, but it should not be automatically applied to every archive labeled ionWordPress: the product had multiple generations, and the actual project folder may differ.

The responsibility boundary looks like this: WordPress handles publishing and content structure, the API handles data delivery, and the mobile template handles presentation, navigation, and some user-facing features. If the API does not return posts, the app cannot display a feed. If WordPress returns empty image fields, the mobile interface will not fix that. If the project is built on an old stack, a newer Android SDK may break the build even when the site itself is fine.

For a site owner, that leads to one simple rule: validate the data and the security posture on the WordPress side first, then configure the template, and only after that spend time on the final build. That order saves hours because most serious problems are visible before you ever run the build command.

Who ionWordPress is a good fit for, and who should choose a different route

This product can be useful when the site already works as a content hub and the mobile app is meant to be a separate reading channel. Typical examples include a news project, blog, magazine, educational site, local media outlet, club site, article catalog, or niche knowledge base. In those cases, the logic is straightforward: the editor continues publishing content in WordPress, and the app pulls in posts, categories, pages, and images.

ionWordPress is especially relevant if you want source code you can control rather than a fully cloud-based builder. You can change colors, screen structure, icons, individual templates, and integration settings. That makes it useful for a developer or agency comfortable with Node.js, Ionic, Cordova, Android Studio, and mobile build debugging.

The product may be the wrong fit in several situations. If you need a modern no-code workflow with publishing that does not involve working with source files, an older Ionic template will be more cumbersome than a cloud app builder. If you need deep WooCommerce logic, user accounts, payments, role-based push segmentation, complex authentication, or two-way data updates back into WordPress, a template alone may not be enough. And if the site follows a modern security policy that does not allow old unsupported API plugins, you will need a safe replacement or a custom integration built on the native WordPress REST API.

Practical takeaway: ionWordPress is best tested as a content-reading app template, not as a universal mobile business builder. The closer your use case is to "show posts, categories, pages, and media," the better the odds of getting results quickly.

What to validate before installation and the first launch

Preparation matters more than installation itself. With a normal WordPress plugin, you can activate the extension, open the settings page, and see a result right away. With ionWordPress, the chain is longer: WordPress, API, build environment, mobile template, third-party notification services, and a device for testing. A failure in any one of those links looks the same to the user - the app does not show content or it crashes.

Validate the WordPress data source

Start with a public API check. In modern WordPress, the basic entry point looks like /wp-json/, and the list of posts is often tested through /wp-json/wp/v2/posts. In a browser or terminal, you should get a JSON response, not an HTML error page, redirect, firewall block, or an empty array for no clear reason.

https://example.com/wp-json/wp/v2/posts?per_page=3&_embed=1

If the response includes posts, links, titles, categories, and embedded media data, the site is ready for a basic test. If the response is blocked, returns an access error, contains no images, or does not expose the post types you need, fix WordPress first. In the app, that kind of problem will show up as a blank screen, endless loading, cards with no images, or broken search.

What counts as a good API response

For the first test, it is enough to see an array of posts, real titles, links to content, category IDs, and thumbnail data. If the response is too large, limit it with the per_page parameter; if images are missing, add _embed=1 and check whether the site is blocking media files.

Assess the risk of the old JSON API

Public descriptions of IonWordPress 3 point to a required JSON API plugin, and the WordPress.org page for that plugin says it was closed and is no longer available for download for security reasons. That is a critical fact for any implementation decision. If your archive depends on that plugin specifically and cannot work with the native WordPress REST API, do not enable it immediately on the live site.

The safe order is this: create a copy of the site, enable the required stack only in a test environment, verify the routes, review the error log, and determine whether the old data source can be replaced with the modern REST API. If that is not possible without editing the source code, it is better to stop and assess alternatives than to carry the risk into the real site.

Check the build environment

For an Ionic/Cordova project, the versions of Node.js, npm, Ionic CLI, Cordova, Android SDK, Java, and Gradle matter. Older projects are often version-sensitive. The newest toolchain may not be compatible with an older template, while older tooling may fail to build an app that meets current Android requirements. Create a separate project folder, pin the versions, and do not mix it with other mobile development work.

Minimum practical checklist:

• The product archive is extracted into a dedicated folder with no Cyrillic characters or spaces in the path.
• The dependency installation command completes without critical errors.
• The project starts in the browser or dev mode before you build the APK.
• Android SDK is installed, and Cordova can see the required platform.
• The WordPress test site is available over HTTPS if authentication or notification features require a secure connection.

Installation: how not to confuse a WordPress plugin with a mobile project

In the task, the product is labeled as a "WordPress Plugin," but the sources we found describe ionWordPress as a mobile template and source package integrated with WordPress. That is an important practical correction. If the archive includes a WordPress plugin, it is likely there as part of the API link or as a helper bridge. The main work still happens in the mobile project, where you set the site address, enable app modules, and build the Android or iOS version.

Safe first-launch scenario

Start with a staging copy, not the live site. In WordPress, verify permalinks, post visibility, featured images, public categories, and API behavior. Then extract the mobile project and locate the configuration file. Depending on the generation of the Ionic project, that could be a dedicated settings file, an environment file, or a service that stores the base site URL, app name, color scheme, notification keys, and menu behavior.

1. Create a backup of the site and a separate test copy.
2. Make sure posts and pages open normally.
3. Check the API response in a browser or terminal.
4. Install the mobile project dependencies in a separate folder.
5. Set the test WordPress site URL in the app settings.
6. Run the project in dev mode and validate the feed before building the APK.
7. Only after that should you build a test APK or a project intended for further release.

This may look like a long process, but it separates data problems from mobile build problems. If the feed is already broken in the browser, there is no point looking for the issue in APK signing. If dev mode works but the APK crashes, the problem is more likely in the Cordova platform, plugins, permissions, or build environment.

Where to look for settings after extraction

Do not rely on a filename from someone else's tutorial. Open the documentation included in the archive and look for sections such as config, settings, app settings, api url, site url, theme color, OneSignal, and AdMob. If the documentation does not match the actual folder structure, search the project directly: the demo-site domain, the term wp-json, the word json, category names, or a test URL will often lead you to the right file quickly.

Do not change dozens of parameters right away. First replace only the site address and confirm that the app receives posts. Then change colors, menus, ad blocks, push notifications, and extra screens. When everything changes at once, it becomes hard to tell which edit broke the result.

How to track changes

Keep a short log: which file was changed, what the parameter value was before the edit, what it became after saving, and which screen you tested. This is especially helpful in older Ionic projects, where the same setting may appear in multiple files or environments.

How the WordPress, API, and app screens fit together

The core mechanic of ionWordPress works like a content storefront. WordPress stores posts, categories, pages, images, and comments. The API returns that data as JSON. The mobile template receives the response, maps the data onto screens, and shows the user a feed, post screen, category menu, search, favorites, or page view. If a given version supports offline reading, the app also stores some content locally so the user can keep reading without a stable connection.

The post feed and categories

For a blog or media site, the main screen is usually built around posts. Three things matter most here: the title, the image, and a short excerpt. In WordPress, that depends not only on the API but also on editorial discipline. If some posts do not have featured images, the mobile feed will look uneven. If categories are used inconsistently, the category menu will be useless. If posts contain complex blocks, shortcodes, or embedded forms, the mobile detail page may not render them the same way as the website theme.

Before launching the app, make the content predictable: important posts should have featured images, categories should reflect the navigation structure, titles should not be too long, and images should open through direct HTTPS links. This is not cosmetic work - it is technical data preparation for the mobile interface.

Pages, comments, and search

Public descriptions of IonWordPress 3 mention pages, comments, and instant search. In a real implementation, those features should be validated separately. Pages are often used for About, Contacts, Terms, Privacy Policy, and Help content. Comments may be enabled on the site but not always needed in the app. Search depends on how the API handles queries and how quickly the site responds.

If the site is large, do not expose every section in the mobile app automatically. It is better to start with a few categories and pages that mobile readers actually need. Then you can expand the structure later. That approach reduces the risk of blank screens, unnecessary menu items, and slow queries.

Images, video, and external links

Media matters more in a mobile app than it does on a standard website page. The user sees the feed on a small screen, and every missing image looks like a bug. Check featured images, file sizes, HTTPS, lazy loading, and how external videos behave. If the product version supports fullscreen video or opening a post in the browser, test that on a real device, not only in dev mode.

Detailed configuration after the first launch

Configuration is easiest when you handle it in layers. Start with the site address and API, then the content structure, then the visual style, then push notifications, and only after that ads or extra modules. That order makes it easier to roll back a questionable change and keeps the project from turning into a pile of random edits.

Base site address and API mode

The first parameter is the WordPress site address. It should be entered exactly as users actually reach the site: with the correct protocol, domain, and no unnecessary redirects. If the site forces HTTP to HTTPS, use HTTPS. If WordPress is installed in a subfolder, make sure the API lives in the correct subfolder as well. If the site uses bot protection, a firewall, or basic auth on staging, the mobile app may not be able to retrieve data.

If the archive uses the old JSON API plugin, do not move it to the live site without a separate security decision. If the project can be adapted to the native WordPress REST API, that is usually the more sensible route. But do not assume the replacement will be quick without checking the source code: an older template may expect a different response format, different field names, and different routes.

When to roll back an API setting

Roll the change back if, after changing the address, the app stops receiving even test posts while the direct API request still works in the browser. That usually means the problem is in the route format or the response handler inside the mobile project, not in WordPress itself.

Navigation and categories

The app menu should help a mobile reader, not mirror the entire site structure. Public descriptions mention a category menu, side menu, and post filtering by category. Use that as a reason to clean up your categories. If the site has technical categories, service sections, or old archive categories, do not expose them in the app unless they are actually needed.

For a typical content site, a good starting structure looks like this: a main feed, 3 to 6 key categories, an About page, Contacts or Feedback, a Privacy Policy, and Search. If the app supports bookmarks, add an obvious place for saved content. If offline reading is available, validate exactly what is stored: text only, text plus images, or partial data without embedded media.

Colors, splash screen, and visual consistency

The product description mentions simple appearance settings and style changes. The important thing here is not to get carried away with decorative edits. The app colors should match the site's brand, but a mobile interface needs stronger contrast and shorter labels. Check title readability, the active menu item state, button colors, the splash screen, and the app icon.

Adjust the style in iterations. First set the main color and app name, then the icon, then the splash screen, then smaller interface elements. After each group of changes, launch the app and validate the feed, post screen, and menu. If colors apply in the menu but not in the post details, look for a separate SCSS/CSS file or a component-level style.

Push notifications and OneSignal

The public description of IonWordPress 3 lists OneSignal push notifications. That feature requires more than just enabling a switch in the template. You need a service account, the correct App ID, keys, permissions in the mobile project, and a test device. OneSignal's documentation for WordPress also emphasizes the connection between HTTPS, app settings, and test notification delivery.

Configure push only after the feed is already working. Otherwise, you will be debugging content and notifications at the same time. For the first test, use one simple post and one test device. If the notification arrives but opens the wrong post, check the deep link or the payload handler in the mobile project. If the notification does not arrive at all, break the problem down: WordPress sends the event, OneSignal receives the message, the device is subscribed, and the app contains the correct keys.

Ads, external links, and the post screen

Some reviews of the original ionWordPress mention AdMob. If your archive includes ad placements, enable them only after the core content flow has been validated. Ads should not cover the menu, interfere with reading, or break the post screen. For a content project, it matters more that the user can open an article, follow a link, share the content, and return to the feed without losing context.

Practical example: building an app for a small news site

Imagine a site with news, analysis, and tutorials. The goal is to produce a test app where the user can see recent posts, open a category, find content, save an article, and receive a notification about a new publication if that feature exists in your archive. This example does not require complex authentication and does not touch the store, payments, or a user account area.

Goal and preparation

The goal of this example is to validate whether ionWordPress works as a mobile reader for the site. Before you begin, you should have: a WordPress test copy, several published posts with featured images, 3 or 4 clean categories, a working API response, the extracted mobile project, and a device or emulator for testing. If the site is password-protected, temporarily use a public test domain or configure access so the app can retrieve data.

Configuration steps

1. Open the posts API endpoint and make sure it returns the latest content.
2. Confirm that posts have featured images and that those images are available over HTTPS.
3. In the mobile project configuration, replace the demo domain with the WordPress test domain.
4. Keep only the key categories in the app menu.
5. Set the app name, primary color, and a basic icon.
6. Run the project in dev mode and open the feed, a category, search, and the post screen.
7. If the feed works, build a test APK and install it on a device.
8. If push notifications are part of your scenario, send one test notification after validating the feed.

How to validate the result

The result counts as working if the app opens without crashing, the feed shows current posts, categories filter content correctly, search returns understandable results, the post screen includes the title, text, and image, and external links do not break navigation. Validate the actual user journey, not just a successful build. If bookmarks or offline reading are enabled, save one article, disconnect the network, and make sure the behavior matches expectations.

Do not treat a successfully built APK as the only sign of success. The real test is the user path: open the app, find content, read a post, return to the feed, and never run into a blank screen.

A detail people often miss

A mobile feed exposes weak content quality faster than a website does. On the site, a long title may seem acceptable, but in the app it breaks the card layout. On the site, a missing featured image may disappear among theme blocks, but in the app it turns into an obvious empty space. So after the technical setup, do an editorial pass: the latest 10 to 20 pieces of content should all look consistently clean.

Practical use cases for different types of sites

ionWordPress makes sense only when the mobile app solves a specific problem. There is no point in building an app "just because you can." Below are the kinds of scenarios where the confirmed product logic and common WordPress practice genuinely come together into a useful result.

News site or city portal

Use the post feed, categories, search, and push notifications. The main value is getting new content in front of a regular audience quickly. The menu should usually keep only major categories: news, events, reference, opinions. Validating the result is straightforward: a new post appears in the feed, the category shows only its own content, and the notification opens the relevant screen or at least the app itself.

Educational blog or knowledge base

Here, search, favorites, and offline reading matter more, if your version includes them. A user may save a tutorial and return to it later. For that kind of scenario, you need to be especially careful with titles, featured images, and category structure. If articles contain a lot of code, tables, or complex blocks, validate the post screen on a real device: HTML from WordPress does not always look the same in the app as it does in the website theme.

Content project with video

If the archive supports fullscreen video or an external browser, test media behavior separately. Video should not open in an endless loop, break the back button, or leave the user outside the app with no clear way back. This scenario depends heavily on how WordPress stores embed code and how the mobile template sanitizes or renders HTML.

Agency project for a client

For an agency, ionWordPress may be useful as a starter base, but only if the client understands the boundaries: this is not a cloud service with guaranteed publishing, but source code that has to be maintained. In the contract or internal plan, document the API, build environment, test devices, Android/iOS updates, and responsibility for third-party notification services separately.

Validating the result before real-world use

Final validation should follow both the user journey and the admin workflow. The user sees the app, opens content, and receives notifications. The administrator publishes posts in WordPress, changes categories, adds images, and expects the app to pick up those changes without a manual rebuild if the architecture is designed that way.

User journey

Open the app on a clean device. Check the first launch, splash screen, main feed, side menu, category, search, post screen, image, video, external link, back button, and reopening the app after closing it. If favorites are available, save a post and remove it from favorites. If offline mode exists, test it without network access.

Administrative workflow

Publish a test post in WordPress, add a featured image, assign a category, and see when it appears in the app. Change the title and image. Clear the site cache if one is in use. Make sure the API is not returning stale data. If the app caches data locally, add a clear refresh behavior such as pull-to-refresh, restart, or another mechanism included in your archive.

Technical path

Check the WordPress log, the browser console in dev mode, Android logcat for the test APK, and the API responses. Do not rely only on what you see visually. If the app sometimes shows an empty feed and sometimes works, the cause may be timeouts, caching, an unstable API, oversized images, or an HTTPS conflict.

A good final test looks like this: you can explain where each app screen gets its data, which API response fills it, what happens when a new post is published, where cache is cleared, and how to quickly roll back a problematic setting. If that is still unclear, the product is not ready for a live workflow yet.

Minimum proof set

Save a screenshot or log of a successful API response, a screenshot of the working feed in dev mode, a screenshot of the test APK on a device, and a note about the build environment versions. These materials will help you recover the project faster if a future toolchain update makes the build non-reproducible.

Also validate behavior after content updates. Publish a short test post, change its category, replace the featured image, and see how quickly the app reflects each change. If updates appear only after clearing cache or restarting the app, document that in the editor instructions; otherwise the team will assume the delay is a product bug.

Safe improvements without editing the product core

With ionWordPress, you should not invent internal hooks unless they are confirmed by the documentation for your specific archive. But there are safe improvements you can make on the WordPress side and in the implementation process. They do not require editing the WordPress core, do not bypass product limitations, and can help keep the API cleaner.

A validation request for the editor or developer

Save a short request that returns the latest posts with embedded media. You can use it after publishing, after a domain change, when enabling cache, or after a site migration.

curl "https://example.com/wp-json/wp/v2/posts?per_page=3&_embed=1"

If the response returns recent posts and an _embedded block with media, the app has a much better chance of displaying a feed with images. If you get HTML, a redirect, or an access error instead of JSON, it is too early to configure the mobile project.

Exposing a custom post type in the REST API

This snippet is needed only if your site uses a custom post type and you explicitly want an external app to read it through the native REST API. It relies on the standard WordPress show_in_rest practice, not on any internal ionWordPress API. Add the code through a child theme or the Code Snippets plugin, but first verify the post type name.

add_filter( 'register_post_type_args', function ( $args, $post_type ) {
    if ( 'news_item' === $post_type ) {
        $args['show_in_rest'] = true;
        $args['rest_base'] = 'news';
    }

    return $args;
}, 10, 2 );

After enabling it, open /wp-json/wp/v2/news and see whether the posts appear. If the app cannot read that route without source-code changes, roll the snippet back and stick with standard posts. Do not use this code as a way to expose private data: anything that becomes public in the REST API must be reviewed from a security and access-control standpoint.

An editorial checklist instead of complex customization

Sometimes the best "hack" is not code but publishing discipline. For the mobile feed, define a few mandatory rules: every post needs a featured image, titles should stay short, categories should be clear, the first paragraph should not rely on heavy shortcodes, and external videos should be validated on a device. That is faster and safer than trying to patch every edge case in the mobile template.

Troubleshooting: what to do if the app does not show content or keeps closing

ionWordPress issues are easiest to diagnose in sequence: WordPress -> API -> mobile dev mode -> build -> device -> third-party services. If you jump straight to rebuilding the APK, you can waste a lot of time fixing the wrong layer.

Empty feed or endless loading

Symptom: the app opens, but the post list is empty or the loading indicator never disappears. Possible causes include the wrong domain, a blocked API, a redirect, firewall filtering, an empty category, a JSON format the template does not expect, or an old JSON API that is no longer working.

What to check: open the API URL in a browser, inspect network requests in dev mode, temporarily disable aggressive caching, and confirm that published posts actually exist. Start the fix with the site address and API. If the archive depends on the closed JSON API plugin, test only on a copy and evaluate replacing it with the native REST API.

Images do not appear in cards

Symptom: titles are visible, but image areas are empty. Possible causes include missing featured images, the API not returning embedded media, images blocked because of mixed protocol issues, a separate media domain restricted by security settings, or a template that expects a different field format.

Check the request with _embed=1, open the direct image URL, and compare several posts. If the problem affects only older content, fix the editorial data. If it affects every post, look for the point in the template where the image object is parsed.

Dev mode works, but the APK closes on the device

This symptom appears often in discussions around Ionic projects: everything works in the browser, but the installed app closes. The cause may have nothing to do with WordPress and instead come from the Cordova platform, Android SDK, an incompatible plugin, permissions, the webview, the release build, or an error introduced when removing and re-adding the platform.

Check in order: a debug build, device launch with logcat, Cordova plugin versions, presence of the Android platform, manifest permissions, and network requests to the HTTPS domain. If the issue appeared after a tool update, lock the old versions and try reproducing the build in a clean folder.

Push notifications are not arriving

Symptom: the app works, but notifications are not delivered. Possible causes include the wrong App ID, the device never subscribed, WordPress is not sending the event, OneSignal is not accepting the message, the app was built with the wrong package ID, or notifications are disabled on the device.

Do not mix push validation with feed validation. First send a test notification from the OneSignal panel or the built-in test scenario, then check post-publication delivery. If the test arrives but automatic delivery does not, the problem is on the WordPress integration side or in the publication event. If even the test does not arrive, check keys, permissions, and device registration.

Search or categories do not behave the same way as on the site

Mobile search usually depends on an API request, not on the theme's search page. So the results may differ. Check which parameters the app is using: text search, category, page, number of items, sort order. If the site uses a complex search plugin, the mobile template may ignore it unless you build a separate integration.

After enabling cache, the app shows old posts

Cache may speed up the site, but API responses for the app need to refresh predictably. Check whether /wp-json/ routes are being cached, how quickly the feed updates after publication, and whether the API should be excluded from some optimization rules. If everything works after clearing cache, configure exclusions carefully and do not disable all optimization without a reason.

Limitations and gray areas worth knowing in advance

The main limitation of ionWordPress is the age of the technology stack and its dependency on API format. If your product version was built for Ionic 1, Ionic 2, or Ionic 3, AngularJS, or an older Cordova environment, it should not be evaluated the way you would evaluate a modern Flutter or React Native template. That does not make the product useless, but it does change expectations: you will need a developer, carefully pinned dependencies, and a separate update plan.

The second limitation is data-source security. The old JSON API plugin was closed in the WordPress.org directory for security reasons. If your archive depends on it, that is not a minor detail but a hard stop for enabling it directly on a live site. You can test on a copy, review the code, and look for a replacement, but you cannot treat it like an ordinary dependency.

The third limitation is app-store publishing. Even if the APK builds locally, platform requirements, signing, target SDK, permissions, privacy policy, and push notifications all follow their own rules. An older template may need dependency, manifest, package, or architectural updates. A guide like this helps you prepare the app, but it does not replace full mobile support.

The fourth limitation is complex WordPress functionality. Shortcodes, forms, private posts, paid content, WooCommerce, user dashboards, custom blocks, and page-builder markup may not render correctly in the mobile app. Validate those elements as separate scenarios, not as part of the general feed.

When CodeCanyon ionWordPress is a sensible choice

CodeCanyon ionWordPress is worth considering if you understand its role: it is a mobile app template for WordPress content, not a universal "make an app" button. It can help a news site, blog, magazine, or knowledge base launch a separate mobile channel if the API works, the content is well structured, and the team is prepared to support an Ionic/Cordova project.

Before using it in production, validate three things: a safe data source, a working build environment, and the real user journey. If the old JSON API is mandatory and cannot be replaced, the risk may outweigh the benefit. If the API returns clean data, dev mode works, the test APK opens on a device, and the content looks solid, you can move on to deeper customization.

After reviewing the settings, limitations, and alternatives, you can download the installation file and test the archive on a site copy. Do not start with the live domain: first the API, then the mobile project, then the test build, and only after that the implementation decision.