Proposal lists 'API development' as a separate line item — what is this, and is it actually necessary?

The API is the backbone of your software. The interface will look outdated and get redesigned in three years, but the API you build stays. If you rebuild your website tomorrow or connect your accounting software later, you'll use this exact same API. Don't worry about the line item existing; worry about whether you get full ownership and technical documentation.

Letting a tablet app connect straight to your database is a massive security risk. Mobile devices run on untrusted networks by default. An API keeps business logic and database queries on the server side with authentication in between. From a purely technical standpoint, the app literally cannot work without it.

Ask the agency in writing right now: 'How many endpoints are included in this scope, and will we receive Swagger or Postman documentation?' If they waffle and just say 'we're hooking up the app,' push back on price; if they provide a concrete endpoint list, pay it.

We paid 8,000 USD for API development on a similar B2B ordering setup last year. That covered 24 custom endpoints, role-based permissions, and a staging environment. 9,500 USD is fairly standard for the US market, but make sure the exact list of endpoints is written into the contract.

What platform is your current website running on? If you're on a standard CMS or a well-known e-commerce platform, they usually already have built-in APIs. Is the agency building an architecture from the ground up, or just layering on top of an existing setup?

listing it as a separate item is actually more transparent. most agencies wold just roll it into the mobile app and quote a flat 30k usd, at least here u see where the money goes but definitely insist on documentation.

i got a similar quote once and asked what would happen if we cut the API agency told me 'then the tablet would just send orders via email.' Guess it really is mandatory for live inventory tracking.

Bottom line, the tablet can't talk to headquarters without an API, so the item itself isn't bogus. But before paying 9,500 USD, make sure you know whether it's built from scratch, how many functions are covered, and if documentation will be handed over.

Correct.

We need to make a distinction here. The biggest time-waster for us was not knowing who had the final say.

Good luck with that.

how did you solve this? in leagcy systems, the most expensive thing is unknown dependencies.

Quick summary for newcomers: Ask who prepared the quote and who will actually do the work.

This is my opinion, I'm not claiming it's absolute truth.

I don't think this advice fits everyone. When making a decision, first look at what data you have on hand.

If you have questions, write them; I'll answer as best I can.

Good call starting this thread.

Same here. If scope grows, either time or budget must grow. There is no third option.

Payment schedules should be tied to project phases, not calendar dates. Just leaving this note, it might be useful.

I'd appreciate it if you shared the outcome.

Let me share what happened to me; it might be useful. Any unwritten clause becomes a point of disagreement later, as both sides remember it differently.

If you post the result here, it will help others too.

Three different views emerged, they all complement each other. If it's your first time, start small; scaling comes later.

That's all, sorry if I went on too long.