REST APIs.
Nineteen of the thirty projects I've shipped are, at heart, a Laravel API with something else on the other end — Android, iOS, React Native, or all three at once. A REST API is the contract between your business logic and every client that will ever consume it. Get it right and a new client is cheap to add. Get it wrong and every client inherits the same bug, on their own release schedule, which is not yours. Most of what I know about APIs I learned from the second case.
One API, every client
A live video streaming platform I built on Twilio serves Android and iOS from a single API — one set of endpoints, one set of rules, two clients that cannot drift apart. Adding a client should be a client-side job, not a back-end rewrite.
Idempotent writes
A retry storm once double-charged real customers on a payment path I was responsible for. Mobile networks drop, clients retry, and a POST that isn't idempotent will eventually run twice. Every write that costs money or creates an obligation now carries an idempotency key. I don't treat this as optional.
Versioning from the first endpoint
You cannot force anyone to update their app. An old client will still be calling your API months after you've moved on, so the version goes in at the start — retrofitting it later means breaking the people who trusted you enough to install the thing.
Reconciliation, not assumption
When an external system is the source of truth, your database is a cache, and caches go stale. If a call fails halfway, the other side's state is the one that counts. I reconcile against it rather than assume my write landed.
The usual shape: iOS and Android need one API that behaves identically for both. Most of my API work starts here.
Web, mobile, and a partner integration reading the same data — the API is the only place the rules should live.
Payments, bookings, anything that creates an obligation. This is where idempotency stops being theory.
Third-party services fail in ways you can't fix. The job is designing for their failure modes, not hoping they stay away.
The API is a boundary, not glue. Laravel owns the domain logic and the database; the API exposes exactly what a client needs and nothing more. Everything past that boundary — the app, the partner, the client nobody has asked for yet — talks to the same contract.
No. If you have one web client and no mobile app, a REST API in front of your own frontend is an extra boundary to maintain for no benefit — Livewire or Inertia will serve you better. Build the API when something genuinely lives on the other side of the network.
Yes, and it should. The live video streaming platform I built on Twilio does exactly that. Two APIs for two clients means two places for the rules to drift, and they always do.
Usually. The existing clients are the constraint that matters — they can't be updated on your schedule, so the first job is finding out what they depend on before anything changes.
In my work
Nineteen of my thirty projects run on an API I built — live video streaming on Twilio serving Android and iOS from one contract, a social platform with an iOS client, and a long line of mobile apps behind them.