Not a sales-training script. A fast reference for Appstus-specific questions, pains and edge cases that can appear inside a real prospect meeting.
No. Appstus does not sell a fixed pre-built product. We understand your business, current workflow, users, tools and operational problems, then shape the application around those requirements.
Do not position Appstus as ready-made SaaS.
A custom business application around the workflows that matter to your operation. Depending on requirements, that may include bookings, jobs, customer management, staff workflows, reporting, communications, payments or other recurring processes.
Examples are possibilities, not automatic project commitments.
It depends on how the team will use it. Some businesses may only need a responsive web application; others may benefit from mobile, web, or a combination. We recommend the format after understanding the workflow.
Do not make mobile mandatory.
First understand what the current system does well and where it fails. If it is mostly working, extending or integrating it may make sense. If important workflows remain fragmented or limited, explore consolidating the useful workflows plus missing requirements into one custom system.
Do not automatically recommend replacement.
Potentially, yes. We can map the useful workflows you already rely on, identify what is missing, and scope a unified custom application. The exact replacement plan is confirmed after requirements and technical review.
Never promise feature-for-feature replacement immediately.
Potentially. We need the platform, required data/actions and available integration access. Production then confirms the practical approach.
Never guarantee an API/integration before validation.
Data migration is something we can explore. The method depends on how the current system stores/exports data, available API or export access, data quality and the new structure. Production reviews this and recommends the practical migration approach.
Do not say all data will definitely transfer.
We inspect what access is actually available. That may change the migration method; production will recommend the most practical option after review.
Do not invent scraping/database access/workarounds on the call.
WhatsApp can remain the communication channel while the custom application becomes the management layer. Even without promising automation, the team can manually record each new inquiry in the CRM/workflow so it becomes trackable instead of disappearing inside chats.
Do not imply automatic sync unless validated.
Example: WhatsApp inquiry arrives → assigned employee creates the inquiry/customer record → the system records ownership → status and next follow-up are added → follow-up activity is updated → owner/manager can see what is pending, who handled it and what happened next.
Workflow example only; not a promise of final UI/features.
WhatsApp can stay where conversations happen; the application gives the team an organized operational record: inquiry ownership, status, follow-up dates, notes, history and management visibility.
Do not guarantee productivity, conversion or revenue gains.
The workflow can be designed so inquiries are assigned to responsible employees and activity is recorded against the relevant customer/inquiry, giving management clearer ownership and follow-up history.
Exact audit logs/permissions/assignment rules require scope.
Yes, follow-up management can be part of the workflow: next follow-up date, status, responsible employee and pending-work visibility can be scoped into the system.
Exact reminders/automation depend on approved scope.
That may be possible depending on the exact use case, WhatsApp setup, provider access and permitted messaging workflow. I’ll capture the requirement, then production can validate what is technically and operationally appropriate before we commit.
Never guarantee integration, unrestricted messaging or restriction bypass.
We document the requirement, production reviews the practical system approach, and we return with a proposed solution direction. We review it with you, clear remaining questions and commercials, then move toward project kickoff once agreed.
Do not present an unreviewed idea as final architecture.
A transactional/event-triggered SMS workflow may be an alternative. A staff member could trigger a delivery/status update from the system and an approved SMS provider could send it. Provider, sender setup, country requirements and recurring usage cost must be validated.
Never promise SMS approval/delivery/sender ID or a WhatsApp bypass.
It can have recurring costs because messages and provider services are often usage/subscription based. There can also be a one-time implementation/setup cost. Exact charges depend on provider, usage and scope.
Do not invent provider prices or Appstus fees.
It depends on the project. Custom design/development/setup can have a one-time project cost, while some components may create recurring costs. We separate these clearly when the solution and quotation are prepared.
Do not say every project is purely one-time or always monthly.
Examples: cloud hosting/infrastructure, SMS or communication usage, third-party APIs, licensed services, external software subscriptions, and an agreed maintenance/support service if applicable.
Only applicable items belong in the final quotation.
Price depends on agreed requirements, scope, integrations and delivery approach. First define what the system needs to do, then prepare the commercial proposal.
Never invent a rough number.
You do not need to design the software yourself. Explain how the business works today, where the friction is, who uses the process and what outcome you need. We use that to shape the solution direction.
Closer is not the final system architect.
Potentially, yes. Identify likely future needs early so the system can be planned sensibly; the impact of a future feature depends on architecture and scope at that time.
Do not promise unlimited changes.
Potentially. A coherent first phase can focus on the highest-priority workflow and expand later. Production should confirm that the first phase creates a sensible foundation.
Do not cut critical foundations just to hit a number.
Booking/scheduling workflows can be part of a custom application. We map availability, booking rules, staff/resource assignment and exceptions, then scope the appropriate workflow.
Do not guarantee zero conflicts under unknown conditions.
Yes, that can be explored—for example jobs, responsible staff, status updates and operational visibility. Exact assignment logic and field functionality depend on requirements.
GPS, routing, offline mode and live tracking require validation.
Role-based access can be included. We map what owners, managers and staff should view/change, then production defines the permission structure.
Do not invent security architecture.
That can be explored. We need to understand shared data, management visibility, branch permissions and reporting requirements.
Exact multi-branch architecture is scope-dependent.
Potentially. Tell us the exact platform and what needs to exchange or trigger. Production checks provider access and confirms what is practical.
An API does not guarantee every requested workflow.
Where we have relevant approved material, our team can share suitable examples after the call through the agreed channel. Because our applications are customized, examples are references to our work—not a claim that your final system will be identical.
Only share approved material; never invent a matching project/client.
Yes. Tell me which channel you prefer, and our team can use that channel for relevant approved material.
Only say it has been sent after it is actually sent.
Appstus operates as a remote team. Developers and representatives work collaboratively across different locations, allowing us to work with clients across markets without depending on one physical office.
Do not imply a physical headquarters that does not exist.
We are remote-first and work with people across different countries. Team locations can vary as the company grows, so Appstus is not positioned as limited to one fixed country.
Only name specific countries when current and useful.
The owner is Osama Khan, based in Oman.
Provide only if asked.
Be direct: “Appstus currently operates as a remote business/team and is not presently represented to you as a registered legal entity. Before any engagement, we can be clear about the contracting and payment arrangement that will apply to your project.”
Do not evade or imply registration. If registration is a procurement requirement, capture it rather than misleading the prospect.
Our website is appstus.com.
Use the exact official website.
Our official email is info@appstus.com.
Use the exact official email.
Use verifiable information: official website/email, approved relevant work where available, and a clear project process, scope and commercial terms.
Never invent registration, offices, clients, certifications or guarantees.
Timeline depends on final scope, features, integrations and complexity. Once requirements are mapped, the team can estimate the delivery plan responsibly.
Do not invent a timeline.
Clarify what absolutely needs to be live first. A smaller first phase may be possible, but production must confirm feasibility before a deadline is committed.
Never accept an unrealistic deadline just to close.
Post-launch support, maintenance and future changes should be clear in the commercial scope. Bug support, ongoing maintenance and new feature development are different items.
Do not invent support periods/fees until policy is locked.
This must be answered from the final Appstus contract/commercial policy for the project. The closer should not improvise ownership or IP terms.
Company policy must be locked before commitment.
That depends on approved architecture and any security/compliance requirements. Capture those requirements so production can propose the appropriate hosting, access and backup approach.
Do not claim unverified certifications/encryption/compliance.
If off-the-shelf software genuinely fits, it may be sensible. Custom becomes more relevant when important workflows remain fragmented, the business keeps adapting itself to several tools, or required operational flow is not served properly.
Do not claim custom is always better.
First identify whether the issue is unnecessary scope, cash flow or value. If scope is too large, explore a smaller coherent phase or different delivery format rather than promising the same project for less.
Discount/payment exceptions require approved authority.
We capture requirements and open questions, the relevant team reviews the solution direction, and where needed we return with a clearer proposed system/scope. We resolve remaining questions and commercials before project kickoff.
Do not call an early concept a final technical solution.
Make sure there is enough clarity on workflow, desired outcome, important requirements and technical dependencies so the proposal reflects the real project rather than a generic package.
Do not use a proposal to hide unresolved discovery.
We can explore a wide range of custom requirements, but we do not promise implementation before checking feasibility, third-party restrictions, scope and budget. We map it, validate it, then commit.
Never say “anything is possible” or “100% yes” without validation.