Laravel development

We build on Laravel because it lets a small team ship a serious application without inventing the plumbing: queues, scheduling, authentication, migrations and testing come with the framework and behave the same way in every project we touch.

New projects start with the parts that decide the cost of the next two years — the database schema, the domain model, the deployment. You get a repository with migrations that describe the schema, a `.env.example` that is actually complete, tests around the money paths and a pipeline that puts a commit on the server without anyone typing on the production machine.

Existing applications are the other half of the work. We take over someone else's Laravel, get it running locally on day one, write down what is fragile and only then start changing things — in small commits, with a test around anything we touch.

What we do here regularly:
— REST and JSON APIs for mobile clients and partners, with versioning and rate limits;
— admin panels and back offices for people who work with the data all day;
— integrations with payment, delivery, CRM and accounting systems;
— queues and scheduled jobs for everything that must not happen inside a web request;
— upgrades between Laravel versions, package by package, without a rewrite.

You always get the code, the server access and a document describing how to deploy and where the logs are. Nothing here depends on us being around.