Skip to content
Deutsch Current language: English

Laravel agency in Stuttgart

Laravel applications you can still change in three years

We build line-of-business applications and API backends with Laravel. For companies that will still want to change something in three years without anyone holding their breath.

Start a project See our services

  • A direct line

    Three extensions, and behind them the people who know your project. No switchboard.

  • Built to hand over

    Versioned migrations, and tests where a mistake actually hurts. Another team can pick this up later.

  • Room to grow

    Backends that keep no state in the process. When load rises, you add instances.

  • No third-party scripts

    This site loads nothing from anyone else. That is why there is no cookie banner on it.

Services

What we do with Laravel

From the first line of code to the day-to-day running of it. A good part of our work, though, is projects that already have a history by the time we arrive.

Why Laravel

Structure you can still follow a year later

Laravel settles where each kind of code belongs. Input checks live in the request, long-running work in a job, the output of an interface in a resource. A team does not have to negotiate those questions again on every project.

Software is rarely expensive to build. It gets expensive two years later, when someone has to change one small thing and first spends a week working out why it was built that way. No technology fixes that. Only the discipline to keep tidying up as you go. We hold to it from the start, even when it looks like a detour in the first month.

More about how we work

app/Http/Controllers/RechnungController.php

public function store(
    InvoiceRequest $request
): JsonResponse {
    $invoice = Invoice::create(
        $request->validated()
    );

    SendInvoice::dispatch($invoice)
        ->onQueue('mail')
        ->afterCommit();

    return InvoiceResource::make($invoice)
        ->response()
        ->setStatusCode(201);
}

How it fits together

One path, and always the same one

Every request takes the same path. Middleware checks who is asking and what they may do, a request object validates the input, the controller does the actual work, a resource shapes the answer. Anything that takes longer moves into a queue and carries on in the background.

Painting by numbers, admittedly. But six months later, whoever has to change something knows straight away where to look.

Flow diagram: a request travels from browser or app through middleware, validation and controller to the response. A red arrow branches down from the controller into an area marked background, where a job in a queue is picked up by a worker.
The path of a request. The branch downwards is why an application still answers quickly when a lot is going on behind it.

How we work

How a project runs with us

  1. A conversation

    We listen, we ask, and we say so plainly if we are not the right people for what you have in mind.

  2. Concept and estimate

    We settle the subject matter and the data model. Out of that comes an estimate in which you can see which part causes which effort.

  3. Building in steps

    Short stretches, and something works at the end of each. You see early what is taking shape and can change course while that is still cheap.

  4. Handover and operation

    Deployment and monitoring are in place, the documentation is written. After that we take on maintenance, or hand over to your team.

Insights

From our work

What keeps us busy on projects, written for people who have to decide without writing the code themselves.

All articles

FAQ

Questions we get asked a lot

What does a Laravel application cost?
That depends on the subject matter, hardly at all on the technology. An internal administration tool with five forms is a different animal from a portal with roles and billing. So we do not publish package prices. After the first conversation you get an estimate broken down by which part causes which effort. Then you decide what belongs in the first release and what can wait.
Do you take on existing projects?
Yes, and it is a good part of what we do. Those start with a code audit. We look at the state the application is in, which dependencies have gone stale and where the risks sit. At the end there is a plan with an order and an effort attached to each item. What we almost never recommend is a wholesale rebuild.
Do you work on site or remotely?
Both, whichever helps the project. For the kick-off it is worth having a room with a wall you can draw on. Development then runs from Stuttgart, with fixed dates for showing where things stand. Clients in the region get a meeting on site without much planning ahead.
What happens after launch?
Going live is where the longer part starts. Dependencies need security updates, Laravel ships new major versions, and requirements change anyway. That is what maintenance and support is for, with named contacts. If you would rather keep it in house, you get the handover and the documentation with it.
Why Laravel rather than a website builder or a CMS?
For a site made of pages and posts, a CMS is usually the cheaper answer. As soon as your own rules come into it — roles, calculations, states — the balance tips. What a CMS ends up assembling out of plugins is, in Laravel, code of your own that can be tested. If what you have in mind falls into the first category, we will tell you so.

Tell us what you have in mind

A few sentences are enough to start with. The person who answers works with Laravel themselves.

Start a project 0711 21955388