ATPL

AI · Build with AI

Add intelligence to the systems you already run.

For companies with a working ERP, CRM, POS or custom app that want one AI feature inside it, done through the system’s own APIs and data, without replacing anything.

Describe the problemAll AI capabilities

Stuck in a tab

The model is stuck in a tab

AI added to the ERP, CRM, POS or app you already run, without a rebuild.

Describe the problem

  1. Paste

    Your software works; you do not want to replace it to get one clever feature.

  2. Model

    Vendors offer AI as a separate dashboard nobody opens, instead of inside the screen staff use.

  3. Permission

    You have no idea how a model call fits into a Laravel app or a Tally export.

Inside your stack

Model calls as a service layer

  1. 01

    Integration map

    Which screen gets the feature, which API or table feeds it, what it writes back, and what happens when the model is down.

  2. 02

    A service layer for model calls

    One module that handles prompts, retries, timeouts, caching and cost logging, so the rest of your code never talks to a model directly.

  3. 03

    Fallbacks

    If the model is slow, unavailable or over budget, the screen behaves as it did before; no feature is allowed to break the old path.

  4. 04

    Permission scoping

    The AI feature uses a dedicated account with read access to exactly the data it needs and write access only where agreed.

  5. 05

    Evaluation on your records

    Fifty real records from your system, run through the feature before launch and after every model change.

How it ships

Map, wrap, fallback

  1. wire/01

    Understand

    We read your schema and API before we talk about models, because the integration is decided by where the data is.

  2. wire/02

    Design

    We agree the one feature, the fields it reads and writes, and the fallback; the model is picked last from what fits the latency and budget.

  3. wire/03

    Build

    The feature ships behind a flag for a pilot group, runs in shadow mode where it writes nothing, then is switched on per user.

  4. wire/04

    Stay

    We track cost per call, latency and override rate, and pin model versions so an upstream change does not alter behaviour silently.

API or product

Where it fits, where it doesn’t

Saying when this is the wrong tool is the fastest way to be believed about when it is the right one.

Fits when

  • Systems with an API or a database you control: Laravel, Node, PHP, WordPress, Shopify, a well-known ERP.
  • One feature with a clear input and output: classify, extract, draft, recommend, flag.
  • Teams that want the feature where staff already work rather than in another tab.

Doesn’t fit when

  • Closed systems with no API and no database access; screen-scraping an old desktop app is fragile and we say so.
  • Adding AI to a system that is itself about to be replaced; put the budget into the new one.
  • Features that need data the system does not record. Integration cannot invent a field.

Your data

The feature reads from your system through a dedicated account with the narrowest access that works, and writes back only the agreed fields. Model calls carry only the record in hand, under provider terms that exclude training. Every call is logged in your infrastructure with its cost.

Wire the call

A product action becomes a model call

The brief is endpoints, auth and what happens when the model is down — integration, not a demo chat.

What a client typed

We have a Laravel CRM our sales team has used for six years and I want it to read the incoming enquiry emails, pull out the company, product and quantity, and create the lead automatically instead of someone typing it in.

Brief ready

What it becomes

Problem
Enquiry emails are re-typed into the CRM by hand.
Scale
A six-year-old Laravel CRM; enquiries arriving daily through a shared mailbox.
Systems
The Laravel CRM with its MySQL database, and the sales mailbox.
First step
A mailbox watcher that extracts the fields and creates a draft lead for a salesperson to confirm.

How we work

ATPL has connected Ethos to third-party ordering apps since 2016 and builds API integrations as a standing service; AI integration follows the same discipline. ATPL will confirm which AI integrations may be named.

    Chosen for the job

    Laravel · Node.js · Python · React

    Decide the shape

    Before you start

    Plain answers on scope, data and what a first proof usually takes.

    Yes, if the system has an API or a database you can read. ATPL adds AI as one feature inside an existing ERP, CRM, POS or custom app, through a separate service layer, so the original software is not rewritten and still works if the model is unavailable.

    Most accounting systems, including Tally, can export or expose data that an AI feature reads; ATPL builds the feature around that export rather than inside the accounting software itself. Typical uses are matching bank entries, flagging unusual invoices and drafting ledger narrations for a person to confirm.

    Much less, because the screens, users and data already exist. An AI integration is usually a three to six week project for one feature, with running costs tied to the number of model calls. ATPL caps daily spend and caches repeated context so the monthly bill is predictable.

    Not if the fallback is built first. ATPL puts every AI feature behind a flag, keeps the old path untouched, runs it in shadow mode before it writes anything, and pins the model version so an upstream change cannot alter behaviour without a test.

    Continue to