Questions we get asked before a project starts

A digital technology and growth agency builds the technology, automation, marketing, and data systems a business runs on, not just its marketing campaigns. Aditsy Orbit combines web and software development, AI and automation, business systems, analytics, digital marketing, and technology support under one roof.

Yes. Aditsy Orbit builds high-performance websites and web applications alongside CRM, business automation, and workflow integrations, so your site, your systems, and your data all work together instead of living in separate vendors.

Yes. We design and build AI chatbots, AI agents, and AI-powered workflow automation for customer support, lead qualification, and internal operations, integrated with your CRM and existing business systems.

A typical marketing agency stops at campaigns and content. Aditsy Orbit also builds the websites, applications, automation, CRM, and analytics that the marketing runs on: your business at the center, everything else in orbit.

Our eight-step framework: Build, Connect, Automate, Attract, Capture, Measure, Optimize, and Grow. It takes a business from foundational technology to a fully connected, automated, measurable growth engine, then cycles back to build better.

Yes. Many clients come to us with an existing website, CRM, or marketing setup. We audit what's there, integrate or rebuild what's holding you back, and connect it into a single, automated system.

Most retainers start at three months, since brand and performance work both need runway to show real results.

Yes, alongside established brands. We size the engagement to your stage and budget.

Brand sprints and web builds are available as fixed-scope projects. Tell us what you need in the form.

Two to three weeks from signed proposal, depending on our current capacity.

Custom work tends to make sense when your process is specific to your business, when you are stitching together several tools with manual copying, or when off-the-shelf options force workarounds your team resents. If a ready-made product already fits well, we will say so. Buying and configuring it is often cheaper and faster.

Business and operational systems (orders, inventory, bookings, approvals, documents), websites and web applications, online stores, CRM setups, and automation between tools. The services pages describe each area. We build around your workflow rather than from a fixed product.

No. Most clients start with a messy description of the problem. We help turn it into a written scope during the discovery stage. Examples of your current spreadsheets, forms or documents are more useful than a formal document.

Yes, and we usually recommend it. A first release that covers one workflow properly lets your team use it and tell us what matters. Later additions are scoped the same way. The design tries to leave room for growth, but we cannot promise that every future requirement will fit without rework.

Not usually, and we would be cautious of anyone promising that. We automate repeat steps and keep a person in the loop for anything involving money, customer communication or judgement calls. We define those review points with you during design.

It depends on scope, how many integrations are involved, how quickly feedback and data arrive, and how many people must approve decisions. We do not quote a timeline before we understand the work. After discovery you get a written plan with milestones and the assumptions behind them.

Slow feedback, missing data or access, requirements discovered mid-build, and waiting on third parties (for example approval of a messaging or payment account). Naming one decision maker and a contact for questions helps more than anything else.

We commit to plans and tell you early if they change, but a date depends on things on both sides, including third-party approvals we do not control. Any dates in the written plan are conditional on the stated assumptions.

In stages where possible. You see working increments on a test environment, which lets you correct direction early. The final go-live is planned with you, including data migration and training.

Changes happen. We discuss the effect on cost and timing, then agree it as a scope change in writing. Small clarifications within the agreed scope are not treated as extra work.

Two projects with the same label can differ widely in effort once integrations, data migration, roles and reporting are counted. Rather than show a number that misleads, we explain what drives cost and give a written estimate after discovery.

Number of workflows and user roles, amount of custom logic, integrations, data migration, reporting needs, design polish, testing depth, hosting requirements and the support level you choose. The pricing page explains each factor.

Third-party costs are separate from our fees unless the written scope says otherwise. These include hosting, domains, paid software subscriptions, payment gateway fees, SMS or WhatsApp message charges, and email services. We list the ones we expect in the estimate so there are no surprises.

No. The estimator produces a preliminary, non-binding brief to help you describe your project. A quotation comes only after a discovery conversation and a written scope.

Both are possible. A well-defined first release suits a fixed scope. Systems that will keep evolving often suit an ongoing arrangement with a regular review. We recommend the model during estimation and write it down.

Tools that offer an API, webhooks, file import/export or another reliable data route can be integrated, for example accounting software, payment gateways, messaging services, email and spreadsheets. We treat each as a potential integration target and check feasibility, limits and cost before agreeing to it.

No. We do not claim official partnerships or certifications with third-party platforms. We build integrations using their public interfaces and their terms.

Often yes, through an official business messaging provider, but it requires an approved business account, message templates and per-message fees set by the provider. Approval timing is outside our control. We design flows so staff can step in.

It can happen, as third parties change their interfaces, pricing and limits. We design integrations to log failures visibly. Fixing breakage caused by external changes is typically covered under maintenance arrangements, not by default.

Options include file exports, scheduled imports, or sometimes replacing that part. Some routes are fragile or may breach the software's terms, so we explain the trade-offs before choosing.

We recommend a hosting setup based on traffic, data sensitivity and budget, and explain the options. Hosting is typically paid to the provider, and where possible the account is in your name. The specifics are written into the scope.

Hosting and infrastructure costs are a separate running cost paid to the provider. They vary with usage, so we give an expected range rather than a fixed promise. You will see the provider's real pricing.

That is our recommendation and usually the cleanest arrangement, but it is agreed in the written scope. Registering accounts in your name makes any future change of developer easier.

We cannot guarantee uptime beyond what the hosting provider commits to. We choose reliable providers, set up monitoring and backups where agreed, and explain the realistic limits.

Backups are part of a sound setup, but how often, how long they are kept and who restores them should be agreed in the scope. Many hosting providers charge for backup storage.

We do not claim security certifications. We follow sensible practices such as access control by role, encrypted connections, keeping secrets out of code, and limiting the data collected. If you need a specific compliance standard, tell us early so we can assess whether it is realistic.

Only people who need it to deliver and support the work, and only as agreed. Within the system, role-based permissions control what your own staff can see and change. We prefer to use test or sample data during development.

We aim to collect only what the system needs and to explain where data is stored. Applicable Indian data protection law should be reviewed for your specific business, and we recommend taking your own legal advice. We do not claim legal compliance on your behalf.

We avoid storing card numbers. Payments are normally handled by a payment gateway that processes card data itself, and our system holds only references and status.

We aim to detect problems through logging and alerts, and to tell you promptly if we find an issue affecting your data. Response expectations are agreed in the support terms. No system can be made risk-free.

Yes. Frameworks, hosting platforms, browsers and third-party services all change. Without upkeep, things eventually stop working or become insecure. Maintenance is a real ongoing consideration, and we show it in the estimate.

Typically security and dependency updates, monitoring, fixing defects, small adjustments, and support for hosting. New features are separate work. The exact inclusions are written down so both sides know.

It is not compulsory but it is strongly advisable for business-critical systems. If you decline it, you or another party must take responsibility for updates and fixes, and we can help with handover documentation.

You describe the need, we assess effort, and agree a small scope. Small changes can be quick. Bigger ones go through the same discovery, design and review approach.

No. Often the better answer is connecting existing tools or building a small layer on top. We recommend replacement only when the existing tool is the actual blocker.

Usually yes if the data can be exported. Data quality is the bigger issue: duplicates, inconsistent formats and missing fields need cleanup, which takes time on both sides. We scope migration separately and test it with samples first.

Sometimes. We would first review the code, hosting and documentation, and tell you honestly whether continuing, repairing or rebuilding is sensible. We cannot assess this without seeing it.

Involve them in mapping and testing, keep the first release focused, train by role, and consider a short period of running both. Adoption is a people problem as much as a software one.

A short period of close attention after launch, then support as described in the agreed terms. The level, hours and response expectations are written down, not assumed.

Through one agreed channel so issues are tracked in a single list. Screenshots, the steps you took and the time it happened help us find the cause quickly.

Response expectations depend on the support level you choose and are agreed in writing. We do not promise instant fixes, since causes can sit with third-party services.

Yes. We provide guidance for the roles involved at go-live, and can arrange more sessions for new staff as needed. The extent is agreed in the scope.

Ownership, licensing and any reuse of components are agreed in the written scope or contract before work starts. We do not assume one position for every project, so please raise this early. Take legal advice if the arrangement is important to your business.

Your business data is yours. The details, including how it is stored, exported and deleted, are set out in the written scope. Third-party services you connect have their own terms.

What is delivered, such as access credentials, source code, documentation and deployment details, is agreed in the written scope. We recommend deciding this at the start rather than at the end.

That depends on what was agreed about access, documentation and ownership. Accounts held in your name, clear documentation and standard technology all make a move easier. We will discuss how this works for your project upfront.