What to decide before you build the API behind a Kuwait app

The job is a contract behind screens you already have. Auth, a data model, an API the front can trust. Not a new product. The wiring.

Founders ask for “a backend.” That is a repo. The job is who is allowed to call which route, and what you can restore when a write fails on a Friday in Kuwait City.

What we decide on a first call

Which client is live — a web app, a store listing, a partner. Which writes must be durable (an order, a wallet, a grade). Who authenticates: password, OTP, a company SSO. What must never leak between tenants or between roles. Where it runs, and who gets the keys.

If the screens are still a Figma file and the objects keep changing, an API will freeze the wrong nouns. Finish the nouns.

If the UI is real and the stall is the contract, backend development is that work: routes, storage, auth. We will not start from a boilerplate and reverse-fit your records into it.

This is not multi-tenant SaaS. Tenancy is a product decision about many companies in one deploy. An API can serve one company. It is also not a store-ready mobile app. That job is the client you ship to a store. This job is what that client calls. It is not Kitty Care’s remembered thread either — that was a product with a chat. Here the product already exists.

When we tell you to keep the current stack

If one spreadsheet and a form still match the volume, keep them. If a vendor API already does the writes you need, we will wrap it, not replace it for sport.

Kuwait desks often need Arabic on the client and English in the logs. That is a field rule. It does not pick the database.

AI consultancy writes the nouns, the auth, and the fail case first. A rebuild comes after you can name the write you cannot afford to lose.

Bring the live screens and the last error your users actually hit. Book thirty minutes or write hello@jamilglobal.com.