Why a Fourteen-Day AI App Stops at One API

You can have an AI app in fourteen days. You can have it talking to Salesforce, or to HubSpot, or to some other system with an API. You cannot have all of that, plus a data migration, inside one fixed price. That is the whole article. Fourteen days at CloudAlta is a fixed scope: a product people can sign in to, and one connection we have already reviewed. Salesforce is usually that connection, because we implement it. HubSpot can be that connection after we have seen the portal. A second system is a second project. If a proposal will not name which of those it is selling, it is selling a slide.

The fourteen days are boring on purpose

The calendar only works because day one is not a blank repo. Sign-in, payments, hosting, and analytics are already standing. The scope call is ninety minutes. You leave it with a written feature list and a live preview link the same day. Days two to four make every screen clickable, on realistic data, so the argument is about the product and not about a wireframe. The feedback call on day four locks the list. A bright idea on day five is a change order, with its own price and its own date. Read that twice before you invite the whole leadership team to "just add HubSpot while you're in there."

Days five to eleven are the product: sign-up, payments, the path a user actually walks, the AI feature, notifications, and an admin dashboard. Days twelve to fourteen are the part demos skip. Security and performance checks, launch on your domain, and the keys handed over.

Those keys were never ours to keep. The domain, the payment account, the hosting account, and any app store listing are created in your name on day one. CloudAlta is invited in. The repository is yours at launch. If a phone app is in the locked scope, it is Expo for iOS and Android, on the same foundation.

Pick a job a skeptical admin would allow

The model is Anthropic's Claude, called through a provider-agnostic SDK. When the price or the quality moves, the model can move without a rewrite. The rows the product has to keep live in a Postgres database you own. Search over your own documents uses pgvector in that database, not a mystery index in someone else's tenant.

A first version does one of these, and it does it in a way you can check:

• An assistant answers from your policies or manuals and shows the source.
• Intake reads an invoice, a form, or a grant attachment, fills the fields, and parks anything uncertain with a person. The original file stays on the record.
• A draft waits. A follow-up, a case summary, a paragraph of a grant report. A person still hits send.
• Routing reads a new inquiry, names a queue, and writes that suggestion back only after the checks pass.

Each of those has an input you can hold and a field you can point at. That is what a short build can be graded on. "It will also clean up five years of files, redesign the brand, and get us through SOC 2" is a portfolio, not a version one. Custom illustration and a HIPAA program sit outside the fixed price for the same reason. They are real. They are not this.

One API. Name it.

The app does not become the system of record. Salesforce stays Salesforce. HubSpot stays HubSpot. The new product does the step your team currently does by copying, summarizing, or retyping, and it does that step through an API, with a credential you control and can revoke.

On Salesforce, the shape is familiar to anyone who has lived in the org. Read the account, the case, or the lead. Draft the summary or the follow-up. Write the fields the process already uses, not a new object invented for the demo. CloudAlta is a registered Salesforce partner, so this is the API we can usually judge against a real org without turning the review into a research project. If you do not need a separate product at all, and the win is AI sitting on the CRM your team already has open, say so. That is an integration, and it should be sold as one.

HubSpot is the same shape when the API allows it. Read the contact or the deal. Update a property. Log the activity. It joins the fixed price after we have looked at that portal: scopes, required fields, and what a failed call leaves behind. The same look covers a billing tool, a form tool, or the internal database someone swears has an API. We say whether it does, on a technical review, before the date is promised.

The review is four questions, and they are dull, which is how you know they matter. Can we authenticate as an integration user you control? Which records can that user see? Which writes are allowed to happen alone, and which must wait for a person? If the call fails, does the record stay as it was?

Then the write stays narrow, because models are confident and occasionally wrong. Output has to match a schema before it touches the other system. Anything under the confidence line goes to a review queue. Every action is logged. Each user has a spend limit. The provider terms we use exclude training on your data. The other system receives the fields the scope named. It does not receive a copy of your database "just in case."

What to do when someone adds a second logo

This is the meeting. Someone shares the screen, the scope looks sane, and then a stakeholder says the app should also update HubSpot, the billing tool, and the support inbox, since "they all have APIs." They do. The constraint is a locked list on day four, and a fixed price that already excludes software we have not reviewed.

Hold the line as one reviewed connection. Salesforce is the one we can usually clear fastest. HubSpot on a portal we have not seen is the excluded line, until the review is done. Two unfamiliar APIs plus a new product will not survive contact with the day-four call, and it should not. The call exists so the list stops growing.

A fourteen-day product build is the right box when people need somewhere to sign in, and one system to read and write. An integration is the right box when the work lives entirely inside Salesforce or whatever you already run. Both start with a pre-discovery call. Bring one process, the system that holds the record today, and a sample: an invoice, a lead email, a grant question. That is enough to tell the boxes apart.

After it is live, the API will move

You run it from the admin dashboard. An optional monthly care plan covers hosting oversight, dependency updates, and a small block of change hours. You will want that block. Vendors rename fields and rotate auth, and they do it on a Tuesday. The next change should be the one usage asked for, not the logo that lost the argument in week one.

Frequently asked questions

Can Salesforce and HubSpot both fit in fourteen days?

One reviewed connection fits. Salesforce is the review we can usually finish fastest, because we implement it. HubSpot joins the fixed price after that portal has been reviewed. Both, on day one, with neither API examined, is how a two-week plan becomes a quarter.

What if the other tool's API is one you have never seen?

We look at the real API and a sample of the data before that connection is quoted. The product foundation can still start. The unreviewed write waits until the review says what it is allowed to change. That pause is the difference between a date and a hope.

Who owns the app?

You do, from day one. Code, domain, payments, hosting, app stores. API credentials for Salesforce, HubSpot, or anything else are created in your account. You can pull our access without asking us first.

Will it write garbage into the CRM?

It will try, eventually. The design assumes that. The payload has to match a schema, low-confidence results stop in a queue, and the log shows what was sent. Outbound email and money fields stay behind a person until you have watched it be boring for a while and decide otherwise.

What should we bring to the first call?

The process you want shortened, the system that holds the record, and one real sample of the input. If the sample and the system fit one scope, we will say so. If they need two, we will say that too.

Bring the process and the system it has to touch. We'll tell you whether it fits fourteen days.