Laravel
Emyrix builds, upgrades, and maintains Laravel applications. New builds where the framework is the right fit, inherited codebases that need reading before anyone changes them, version upgrades done one major at a time, and the performance and security work that comes up once an application has been in production for a few years.
Laravel development from Massachusetts, working with businesses across the United States.
Overview
Laravel is what we build most custom applications on, and the site you're reading is one of them. It gives a project accounts, permissions, queues, scheduled jobs, mail, validation, and database migrations on the first day, which on a custom build are weeks you would otherwise pay for. What it doesn't give you is structure. A Laravel application still has to be organized by somebody, and five years in, the difference between one that was and one that wasn't is most of what we get asked to fix.
The work splits fairly evenly between new and inherited. A new application starts with the process it has to support and a written scope, and gets the unglamorous parts built in from the start: an audit trail, background jobs that retry, error reporting that tells somebody a nightly job failed. An inherited one starts with reading it. What version it's on, whether that version still gets fixes, how it's structured, what has tests, and how much of it is actually used. Then you get a plain account of its condition, and options that include keeping it.
Laravel releases a new major version every year, and each one gets bug fixes for eighteen months and security fixes for two. That's a generous window, but an application left alone for three years is out of support and several versions behind, and the hops compound. We upgrade one major version at a time — PHP first when it's the thing blocking the framework, then Laravel, then the packages that were pinning it — with tests around the parts that matter before anything moves. The application stays in production throughout.
We also say when Laravel is the wrong answer. It's almost never the right place to build a store: carts, tax, shipping, and payment flows are enormous to build and never finished, and a commerce platform will beat a custom build on both cost and completeness. Laravel is the right tool for the systems around the store — the integration layer, the customer portal, the internal tool — and a good share of our Laravel work sits exactly there, next to a Magento or Shopware store we also look after.
If the framework isn't decided yet, our web development and custom software pages describe the work by what it's for. This page is for when it is: because the application already exists, or because your team already knows Laravel.
Emyrix LLC is registered in Massachusetts and works remotely with clients across the country, across Eastern, Central, and Pacific hours, with US contracts and invoicing in dollars.
Services
Customer portals, internal tools, admin panels, and the applications a business runs on, built from a written scope. Accounts, roles, queues, an audit trail, and error reporting are in the first version, not added to the second.
The developer who built it has moved on and nobody is sure what state it's in. We read the codebase, deal with what's urgent, and give you a plan you can put a budget against. A rebuild is not a condition of us getting involved.
From whatever version you're on to a supported one, in the right order: the PHP version, then the framework, then the packages that were pinning it. Scoped up front, so you know how many hops there are before the first one.
Bringing a legacy PHP application under Laravel a piece at a time: new features in Laravel beside the old code, routes moved across as they're touched, one database shared until the old side is empty.
Slow pages, slow queries, N+1 problems, missing indexes, caching that isn't caching, and queues that back up. We measure before changing anything.
Authentication and two-factor, authorization gaps, how submitted input is handled on its way into the admin, security headers and a Content Security Policy, dependency audits, encrypted backups. The same work we've done on our own site and written up on the blog.
REST and GraphQL APIs, and the integration layer between an ERP, a CRM, a warehouse system, or a store. Built with retries, logging, and alerts, so a feed that stops working says so.
A retainer for security updates, dependency and framework upgrades, monitoring, and a queue of improvements, so the application keeps up with the framework instead of falling three versions behind.
Why Emyrix
The person who reads your codebase and writes up its condition is the person who then does the work, so the plan and the code come from the same understanding of the application.
Each major version is its own step with its own deploy. An upgrade can pause for a busy month without leaving the application half-moved.
Emyrix LLC is a Massachusetts company. Contracts, invoicing, and working hours are all domestic, with overlap across US time zones.
FAQ
Yes, and a large share of our Laravel work starts that way. We read the codebase, check the framework and PHP versions and whether they still get fixes, look at the structure and the tests, and deal with what is urgent first. Then you get an honest account of where it stands and a plan you can budget for. Sometimes that plan is a rebuild. Usually it is not.
One major version at a time. PHP goes first when it is the thing blocking the framework, then Laravel, then the packages that were pinning it, with tests around the parts that matter before anything moves. It stays live throughout, and the work can pause between versions. Going straight from two versions back to the current one is possible, but the breaking changes from every version in between still apply, so it is the same work with less of a map.
Each major release gets 18 months of bug fixes and two years of security fixes from its release date, and a new major arrives every year. In practice that means the current version and the one before it are the only ones receiving fixes at any given time, and anything older gets nothing. Run php artisan --version, or read the laravel/framework line in composer.lock, to see where you stand.
For a custom application — a portal, an internal tool, an integration layer, an API — usually yes. It comes with the parts every application needs, and a lot of developers know it, so finding somebody to work on it later is a normal hiring problem. For an online store, almost certainly not: a commerce platform will do a better job at lower cost, and we would tell you so. For a brochure site, a CMS is usually the better fit.
Usually one of a short list: queries running in a loop (the N+1 problem), a missing database index, caching that is configured but not actually caching, work done during the request that belongs in a queue, or a server with less room than the traffic needs. We measure before changing anything, because the slow part is often not the part somebody suspects.
Yes. We check authentication and session handling, whether two-factor is available for the accounts that need it, authorization on every route that should have it, how submitted input is handled on the way into the admin, security headers, dependencies with known vulnerabilities, and what happens to backups. You get a written list, ordered by what to fix first.
Often, and in stages. New features get built in Laravel beside the old code, routes move across as they are touched, and the two share one database until the old side is empty. The business keeps running on the application the whole time. Whether it is worth doing depends on what the old application does and how it is built, which is the first thing we look at.
Yes, and it is a common pairing. The store stays on Magento, and Laravel handles what the platform was never meant to do: a customer portal with its own rules, the integration layer between the store and an ERP or warehouse system, a reporting tool, an internal admin. We work on both sides, so the two get designed together.
Where the interface calls for it. Plenty of applications are better served by Blade and Livewire, which keep everything in one codebase and one language. When a screen needs to behave like an application — live filtering, a lot of state, an editor — we build it in React against a Laravel API. This site is Laravel with React pages prerendered to static HTML.
With a conversation about what the application has to do and where it currently breaks down, then a written scope covering what is included, what is not, and what we would build or fix first. We scope the work before asking you to commit to it, and if we think the work does not need us, we will say so.
Yes. Some clients keep us on a retainer for security updates, dependency and framework upgrades, monitoring, and a queue of improvements. Others take the application in-house, which is what the documentation and the tests are for.
Yes. Emyrix is based in Massachusetts and works remotely with businesses across the United States. We work on US time, use US contracts, and invoice in US dollars.
Related
Work with Emyrix
A new build, a codebase you inherited, or an upgrade that keeps getting postponed — describe what it does and where it stands. We'll come back with what we'd do first.