Laravel Development

Laravel when PHP is already how the firm ships.

Laravel when PHP is already how the firm ships

LavisTech is a small software shop in Chengannur, Kerala. We write .NET for a living, and we say so. We also write Laravel when that is the stack the firm already has people for. A factory, a trading house, a campus office, or a product team that hired PHP developers is not helped by a lecture about frameworks. They are helped by someone who will take the existing app, read the queues, and ship the next slice without pretending the last three years of work did not happen.

Laravel is a good answer when the clerks already log into a Laravel admin, the cron is already Supervisor or Horizon, and the person who will maintain the thing after we leave is comfortable in PHP. It is a poor answer when nobody on your side can open a Blade file and you were hoping a new stack would magically create that person. Stack choice is a staffing choice. We treat it that way on the first call.

This page is about application work: APIs, admin screens, jobs on a queue, takeover of a repo that already bills customers. It is not a brochure for “PHP websites.” If you need a marketing site, say so. If you need the system people work in on Tuesday, keep reading. The cost shape of that second job is the same as any other custom build — written scope, assumptions, a definition of done — and it lives on how much custom software costs, not in a weekend quote.

Takeover first, rewrite later if ever

Most Laravel enquiries we see are not greenfield. Someone left. A freelancer stopped answering. The original shop is in another city and bills by the hour to change a GST rate. The app still takes orders. Staff still know the screens. What you want is a team that will clone the repo, get it running locally, list the jobs that already exist, and tell you what is safe to touch.

A takeover week is not a rewrite. We list packages and their versions, the PHP runtime, the queue driver, how mail actually leaves the server, where files live, and who has the production keys. We write down what we will not change in the first slice. If the app is Laravel 8 on an old Ubuntu box, we say whether the next job is an upgrade or a feature. Mixing both in one fixed price is how you get a number that moves in week six.

Rewrites get proposed when the new vendor has not read the old code. We will propose a rewrite only when the current app cannot accept the next job without lying to staff — no tests, no way to add a column, a schema that treats every customer as a unique snowflake with three spellings. Even then, the first delivery is usually a strangler: one workflow moved, the rest still running. You keep taking orders while we work.

What we actually build

A Laravel job for us looks like a business system, not a tutorial. Typical first slices: an admin for orders and items your clerk can finish without us; a REST API that a mobile app or a dealer portal can call; a queue that sends WhatsApp templates or invoice PDFs after the request has already returned; a report that reads yesterday correctly after a migration. We use Eloquent when the schema is honest, query builders when it is not, and we do not hide a second database behind a “temporary” CSV.

We keep Tally in the picture when Tally is already the books. Laravel does not become your accountant. It posts the voucher or the export Tally already understands, or it stops at a file your accountant imports on Friday. GST fields belong in the order and the invoice, not in a speech about disruption. If the rate changes, a named person changes it in a screen. They do not wait for a deploy.

Excel still arrives. Imports are a feature with a mapping, a dry run, and a reject file — not a paste into production on Monday morning. That discipline is the same one we use on data migration when the spreadsheet is the system of record. If the spreadsheet is only a weekly upload into an app you already trust, we treat it as an import story, not a programme.

APIs, queues, and the job that must not run in the request

If a checkout, a registration, or a “generate invoice” button waits for a PDF, a mail server, and a WhatsApp vendor, you will get timeouts on the day you are busy. The request writes the record and enqueues the work. Horizon or a Supervisor-managed worker does the rest. Failed jobs retry with a reason you can read. That is ordinary Laravel. We still write it down in the definition of done, because many live apps skip it and then blame “the server.”

APIs get the same treatment as screens. Auth is a real user or a real client credential, not a shared token in a group chat. Pagination, idempotency on payments and order create, and a version you can keep for a year. If a React front end or a mobile app will sit on top, we agree the contract before anyone paints a button. A pretty UI on an unpublished API is a demo, not a handover.

File uploads go to a disk you can back up. They do not live only on the web node that happened to take the request. If you have two app servers and a local storage driver, you already have a support ticket you have not seen yet. We fix that in the first slice when the slice touches files.

Admin a clerk will use on Tuesday

Nova, Filament, or a Blade admin we write — the product name matters less than whether the person who invoices can finish the job without calling you. Search by the fields they already use: phone, GSTIN, bill number, the half-remembered item code. Bulk actions that are undoable. A permission model that matches how the office actually splits work: owner, accountant, counter, warehouse. Five roles that must not see each other’s records is a design problem, not a checkbox on a package.

We sit with the clerk for a morning if we can. We watch the WhatsApp group they still use as a workaround. The admin is done when they complete yesterday’s work in it, not when a theme looks modern. If they keep a parallel Excel after go-live, the admin is not done. That is a failed test, and we say so.

The same discipline as a .NET job

Laravel is not a casual cousin of “real” software. Staging that looks like production. Migrations that run forward and have a plan back. Tests on the money path. A backup you have restored once. Source you own. A way to change a rate without a deploy if the business changes rates. Those sentences are the same ones we use on .NET development. The runtime is different. The definition of done is not.

We will not skip logging because PHP feels informal. We will not skip roles because the first user is the owner. We will not skip a handover because “it is only Laravel.” If a vendor treated your PHP app as disposable, that is why you are here. We will not repeat it.

When we would tell you to use .NET instead

If your other systems are already ASP.NET, your only in-house developer writes C#, and the Laravel app is a leftover from a student project, we will say so. One stack a small firm can hire for is worth more than a fashionable split. If you are starting a greenfield internal system and you have no PHP people, we will usually point you at .NET and leave Laravel for the team that already lives in it.

If you are choosing a product versus a build, read custom software versus off-the-shelf before you pick a framework. A package that already does eighty percent of a common process beats a Laravel rewrite of that process. Laravel wins when the process is yours and you need to change it without a vendor roadmap.

Cost and calendar, said plainly

A takeover with a written report — repo running, risks, a recommended first slice — is often two to four weeks. A focused feature on a healthy app (one workflow, tests on the money path, hosted, handed over) is often eight to sixteen weeks. An upgrade across major Laravel versions, plus PHP, plus a queue you never ran properly, is its own phase; do not hide it inside a feature quote. A programme that replaces several spreadsheets and talks to Tally and a website is months, usually phased.

We will not print a rupee total that will be wrong for your payment gateway, your WhatsApp vendor, or your GST exceptions. If two vendors differ by a wide multiple on the same one-page brief, one of them has not priced the queue, the migration, or the handover. Ask them to show which. Time and materials with a cap, or a fixed first slice with a change log, both work. A fixed price on an unread repo does not.

A first week on an existing app

Day one we need the repo, the env shape (secrets stay with you until we have a channel), and a database dump that is not production salaries if it does not have to be. We get it running. We hit the main screens as a clerk would. We list the scheduled commands and the failed jobs table. We write a one-page picture: what we understood, what we could not start, what we will not touch in slice one.

If we cannot start the app in week one, that is the finding. Missing keys, a licence server, a package that only exists on one laptop — those are the project until they are not. Building features on a machine only the old vendor can boot is how you buy a second hostage.

By the end of the first week you should have a written first slice: one sentence the staff would recognise, an in-list, an out-list, and the integrations named. “Improve the system” is not a slice. “Counter can create a GST invoice, print it, and enqueue the WhatsApp copy without waiting on the vendor” is a slice.

Integrations we see from shops like yours

Tally for books. A payment gateway that already has a reconciliation file you ignore. WhatsApp for OTPs and “your order is ready.” SMS when WhatsApp fails. A shipping API that changes its payload without an email. Excel for the purchase team that will not type into a form. None of these are exotic in Kerala. All of them are longer than the screen that displays the result.

We name them in the estimate. “Integrations TBC” is how a cheap quote becomes the real project. If Tally must receive a sales voucher the same day, that is a story with a mapping and a failure queue. If Tally can wait for a Friday export, say so — that is cheaper and often honest enough.

Blade, Inertia, or a React front

If the users are internal and the screens are forms and tables, Blade or a maintained admin kit is usually enough. If you already have a React team and a public product UI, Laravel can be the API and stay that way. We will not add Inertia or Livewire because a conference talk said so. We will add them when the team who remains can edit them.

A public marketing site in Laravel is possible and often the wrong spend. Use the stack your content people can publish in. Keep Laravel for the logged-in work. Mixing a brochure and a billing system in one deploy is how a copy change becomes a regression on checkout.

What we will not do

• Nuke a live app and “rebuild in two months” without a parallel path for orders.
• Leave you on a shared token in a WhatsApp group and call it an API.
• Hide a data migration inside a feature quote as “import existing Excel.”
• Claim a certification we do not hold, or a partner badge we bought for a landing page.
• Staff your company with a model that deploys to production without a person.

We are also not a twenty-person PHP factory. If you need a bench of fifteen Laravel developers next quarter, say that early. We will tell you when the job is bigger than a shop our size should carry alone.

How to brief the job

Send the URL the clerks use, the PHP and Laravel versions if you know them, whether Horizon or cron is sending mail, and the one job that hurts this month. Name Tally, WhatsApp, payments, and any other system that must stay. Name who will sit with us one day a week. If you do not have that person, the quote is not low enough to save you.

If the repo is a surprise even to you, start with the takeover week. Do not ask for a twelve-module rebuild from a screenshot. Screenshots hide the queue, the GST exceptions, and the item codes that are only unique on Tuesdays.

Write the expensive assumption as a sentence. “Counter staff will raise the GST invoice here instead of Excel.” Then we build only what that sentence requires. Reports can wait. The dealer portal can wait. The second branch can wait. That is how an MVP stays a test you can fail cheaply, even when the stack is Laravel.

After handover

You get the source, the hosting shape, a backup you have seen restore, and a named window of support. A rate change should not require us. A new payment field might. Budget a small change allowance after go-live; staff will find the story you cannot see from Chengannur until they click it for a week.

If you want to talk through a repo or a first slice, contact us with the versions and the one job that matters. We will tell you whether Laravel is the honest stack, or whether you should stop paying two ecosystems to do one firm’s work.