Not every system allows a suitable connection. Sometimes there is a documented API and orderly permissions, sometimes there is only a file export or a manual process, and sometimes an alternative should be considered instead of promising a connection that cannot be maintained.This guide focuses on the business and technical questions to ask before development: who uses the app, which information is shown, what the reliable source is for each piece of data, and what happens when the existing system is unavailable.
1. When an app can sit on top of an existing system
An app is worth considering when the existing system already manages important information, but users need a more convenient way to view or update it: customers who see an order status, field employees who update completion, or managers who get a quick picture.The main condition is a way to receive and update information in an orderly way: an API, permissions, documentation, and a testing process. If there is no suitable interface, it may be possible to start with a limited export and import, a middle system, or a first version that is not connected to every action.
- Which information already lives in the existing system?
- Who needs to use the app: a customer, an employee, a manager, or several user types?
- Does the app only display information, or does it also change data?
- Is there an official way to connect to the system?
2. Checking the API, documentation, and vendor dependency
An API is an interface that lets systems talk to each other. Before committing to development, check these questions, including what happens if the vendor changes the interface or limits an action.
- Is there an official, documented API?
- Is there a test environment or a trial account?
- Which actions are allowed through the API, and which are not?
- Are there usage limits, call-rate limits, or vendor costs?
- Who is responsible for granting permissions and resolving failures with the vendor?
- What is the alternative if there is no suitable API?
3. Identifying users and permissions
An app connected to a business system needs to know who the user is and what they are allowed to see or do. A customer should not see another customer's information, an employee needs access by role, and a manager may need a wider picture.Plan sign-in, identification, and permissions at the start of the project. If the existing system already manages users, check whether that can be used. If not, a permission layer in the app or in a middle system may be needed.
- How do you identify a customer, an employee, and a manager?
- Which information is each user type allowed to see?
- Which actions is each user type allowed to perform?
- Do the app's users already exist in the admin system?
- How is access removed for an employee who left or a customer who is no longer active?
- Where are permissions and a record of actions stored?
4. Source of truth and sync directions
The source of truth is the place where a piece of data is treated as official. For example, an order status can be set in the admin system while the app only displays it. An address update, by contrast, can start in the app and move to approval in the system.Without deciding the source of truth for each kind of information, it is easy to create duplicates, conflicting statuses, or outdated information.
- What is the source of truth for orders, customers, statuses, and payments?
- Which information is only displayed in the app, and which information can be updated?
- Is the sync one-way or two-way?
- What happens when the same piece of data changed in two places?
- Is a record needed of who changed something and what changed?
- Which data can be stored temporarily in the app, and which cannot?
5. What happens when the existing system is unavailable
An existing system can be unavailable because of a failure, maintenance, an API change, or a permission problem. The app needs to know how to behave in that state without showing misleading information and without losing an important action.
- Which message does the user see when there is no connection?
- Is the last saved information shown, or is the action blocked?
- For important actions, such as a status update or sending a request, is a pending attempt saved and is someone alerted if it is not completed?
- How is a duplicate action prevented after a retry?
- Who receives a notification when the connection fails?
- How do you check that returning to normal operation does not create wrong data?
6. Notifications and status updates
An app connected to an existing system usually needs to show status changes and tell the user when something moved forward: an order was approved, work started, a document is missing, or an action is waiting for approval.Define which change actually needs a notification, which channel sends it, and what happens if the user does not open the app. Not every internal change should become a push notification, or users will stop paying attention to them.
- Which statuses exist in the system today?
- Which statuses should be shown to the customer, and which only to the team?
- When do you send push, email, or SMS, and when do you send nothing?
- Is a read receipt or an action from the user required?
- How are duplicate notifications prevented?
- Is an event log needed inside the app?
7. A first version and later extensions
Start with a first version that proves the core connection and does not try to replace the whole admin system. For example: showing orders and statuses to customers, with basic permissions and failure checks, without opening every edit and payment action yet.After the connection works and people actually use it, it can be extended: smarter notifications, updating details, uploading documents, actions for field employees, or sync with additional systems.
8. What affects scope and cost
Scope cannot be estimated from the sentence "an app that connects to an existing system" alone.The state of the existing system also matters: missing documentation, an unavailable vendor, a limited API, or a need for a middle system can increase the work. Start with a feasibility check before committing to a full plan.
- The number of screens and flows in the app.
- The quality of the existing system's API and documentation.
- The number of user types and the level of permissions.
- The number of integrations and third-party services.
- Requirements for notifications, sync, and failure handling.
- A need for a middle system, logs, or an additional admin interface.
9. Questions to send the existing-system vendor
Before a development conversation, contact the vendor of the existing system and get basic answers. Those answers show whether the connection is possible, what is limited, and what should be planned as an alternative.If the vendor does not provide an API or does not allow the required actions, partial options can still be checked: a data export, a limited manual process, replacing the system, or building a separate working layer that does not depend on actions that do not exist.
- Is there an official API, and what is the link to the documentation?
- Is there a test environment or a sandbox account?
- Which data can be read, and which data can be updated?
- How do the permission and identification mechanisms work?
- Are there usage limits, API costs, or special vendor terms?
- How is support provided when a connection fails?
- Are there webhooks, or another way to receive an update when a status changes?
- Is it allowed to keep a copy of certain information in the app or in a middle system?
Hypothetical example only
A customer views orders and statuses from the admin system
- A business manages orders in an internal system and wants a customer app to show each customer their own orders.
- The existing system is the source of truth for orders and statuses. The app reads the information through an API and shows only orders that belong to the signed-in user.
- In the first version the customer sees a list of orders, a current status, and contact details. They do not change the order from the app.
- When a status changes in the admin system, the app updates and sends a notification only for statuses that matter to the customer.
- If the system is unavailable, the app shows a message that the information is temporarily not updating and alerts the team if the failure continues.
A checklist before you start
You do not need to arrive with a complete technical solution, but it is worth collecting the following so the connection can be checked for feasibility.- The name of the existing system and the kind of information it manages.
- A link to API documentation, or a contact at the vendor.
- A list of users: customers, employees, managers, or other types.
- The actions the app needs to perform in the first version.
- The source of truth for each kind of information, and the desired sync directions.
- Sign-in, permission, and notification requirements.
- What happens today when the system is unavailable or the data is not up to date.
- Possible alternatives if there is no suitable interface.
Common questions
Can you connect to every existing system?
No. The connection depends on the API, permissions, documentation, and the vendor's terms. If there is no suitable interface, alternatives are checked, such as a data export, a partial manual process, a middle system, or a change in the existing system.
Does the app have to replace the admin system?
No. In most cases the app adds a layer of use for customers or employees, while the admin system remains the source of truth for some of the data.
What if the vendor does not provide API access?
Permissions are not bypassed. Check which official options exist, whether there is a data export, whether extra approval is needed, or whether a partial solution or an alternative system is the right plan.
Want to check whether an app can connect to your system?
Send the name of the system, what the app needs to display or do, and what is known about the API and permissions. We will check feasibility with you and a direction for a first version.Want to check whether an app can connect to your system?
Send the name of the system, what the app needs to display or do, and what is known about the API and permissions. We will check feasibility with you and a direction for a first version.