Example package
Bug-fix batch
A list of bugs in your existing application repaired in one pass.
You get
- Each bug reproduced and repaired
- Tests added for each fix
- Deployed to a staging copy for your review
- Released on your approval
Sound familiar?
What we hear from businesses before a project like this starts.
- The developer who built our system has gone, and nobody else understands it.
- We're stuck on an old PHP version and the host keeps warning us.
- There's a list of bugs in our portal that nobody has had time to fix.
- We need one new feature, but every agency wants to rebuild the whole thing.
- We have to move the app to a new server and we're afraid it won't come back up.
What buyers usually need
The requests that come up most often for this kind of work, and what each one takes to work properly.
01
Bug fixes in an existing portal or ERP
Each bug reproduced, repaired and tested, without rewriting the parts that work.
02
A new feature in a system that's already live
The feature added in the style of the existing code, with a migration plan for the database.
03
PHP and Laravel version upgrades
Upgraded step by step, with dependencies updated and the app tested at each step.
04
Deployment to a new server
The app, database, queues and scheduled jobs moved to a fresh Ubuntu server, with backups and HTTPS.
05
Multi-tenant launch
Tenant setup, domains and configuration finished so the platform can take its first customers.
06
CakePHP, CodeIgniter or plain PHP
Older frameworks maintained as they are, or moved to Laravel in stages when that makes sense.
Tools that come up most: Laravel, PHP 7 and 8, CakePHP, CodeIgniter, MySQL, MariaDB, Vue, React, Livewire, Ubuntu, Nginx, Docker.
What you get
Concrete pieces, each one something you can open and check when it's done.
Bug fixes
Bugs reproduced, repaired and covered by a test so they stay solved.
PHPUnit, Pest, logs and error trackingNew features
Features added in the style of the existing code, with database migrations and permissions.
Laravel, Eloquent, queues, Livewire, VueVersion upgrades
PHP and framework versions upgraded in steps, with deprecated code replaced.
Composer, Rector, Laravel Shift where usefulDeployment and hosting
Servers set up with HTTPS, backups, queue workers and scheduled jobs, in an account you own.
Ubuntu, Nginx, MySQL, Docker, Forge or plain serversPerformance
Slow pages traced to their queries and sped up with indexes, caching or eager loading.
Query logs, Telescope, DebugbarDocumentation
A written map of the application: how it is built, how to deploy it, and where things live.
README, run bookTypical projects
Example packages to show the shape of the work. These are examples, not past clients; yours gets its own written scope.
Example package
One new feature
A single feature added to a live Laravel or PHP application.
You get
- Written behaviour agreed before coding
- Database migration and permissions
- Tests for the new feature
- Released on your approval
Example package
Version upgrade
Your application moved from an old PHP or Laravel version to a supported one.
You get
- An audit of what will break, before work starts
- Upgrade done in steps on a staging copy
- Dependencies updated or replaced
- A tested release on the new version
Example package
Move to a new server
Your application moved to a fresh server in your own account.
You get
- Server set up with HTTPS, backups and monitoring
- Database and files migrated
- Queues and scheduled jobs running
- A run book for deploying future changes
Example projects
Laravel fixes and upgrade for a salon booking platform
A salon booking platform built on Laravel 8 was double-booking appointments, its booking page took nearly 7 seconds to load, and the original developer was gone. We found and repaired the race condition behind the double bookings, cut the booking page from 214 database queries to 9, moved emails onto a queue, and upgraded the app to Laravel 11 and PHP 8.3. Everything shipped as reviewed pull requests with tests, so the owner's team can maintain it.
- Race-condition fix: booking inside a locked database transaction, with a friendly error if a slot is taken
- Performance: N+1 queries removed, indexes added; p95 page time from 6.8 s to 0.4 s
- Queued email and notifications
- Laravel 8 → 11 and PHP 7.4 → 8.3 upgrade, deprecated packages replaced
PHP 8.3, Laravel 11, MySQL, Redis queues, PHPUnit, Larastan, GitHub Actions
Sample build
A working example we built to show this kind of work. It is a demonstration, not a client project.
Sample build
Laravel fix: month-end invoices missing from a report
An invoice report left out every invoice issued on the last day of the date range because the end date was compared as midnight. A feature test reproduces it, a small diff makes the range cover whole days, and the test passes afterwards. The before and after test runs and report pages are included.
Laravel 13, PHP 8.5, Eloquent, PHPUnit, SQLite, Docker
About the screenshots: The fix summary and the report before the fix, from a sample Laravel app with demo data.
How we approach it
The habits that keep this kind of project from going wrong.
1
Read before changing
We start by getting the app running on a staging copy and writing down how it works. Fixes come after we understand it.
2
Fix, don't rebuild
We change what needs changing. If we think a rewrite of some part is truly needed, we say so in the scope with the reason.
3
Staging first
Every change goes to a staging copy for you to check before it reaches your live system.
4
Leave it easier to maintain
Each change is committed with a clear message, and the handover includes the notes the next developer will need.
How we work
You describe it. We write it down, build it, and hand it over.
You describe it
Tell us what you need in your own words, and which tools you already use. A few lines is plenty to start.
A written scope
We reply with a short written scope: what gets built, what is out of scope, which accounts we need, and how we'll both know it works. You know what you're getting before work begins.
Milestones you review
The work is split into milestones. At each one you see it working in your own account and sign it off before we go on.
Handover and a 30-day fix window
You get the working system, its documentation and a walkthrough. If anything we built breaks in the next 30 days, we fix it at no charge.
What shapes the scope
- How large and old the codebase is
- Whether there is a working staging copy and tests
- The number of bugs or the size of the feature
- Hosting and deployment work involved
Always included
- A written scope before work starts
- Milestones you review and sign off
- Documentation and a walkthrough at handover
- A 30-day window for fixes, at no charge
Pushbuild has built software for businesses since 2010, for more than 40 clients. Every project is led by a former public-company CTO, from Groton, Massachusetts. See products we've built.
Questions people ask first
Can you work on code someone else wrote?
Yes, that is most of this work. We get it running on a staging copy first, then tell you what we found before quoting the changes.
What access do you need?
Access to the code repository, and either a copy of the database or access to a staging server. Production access only when deploying, and only if you want us to do the deploy.
Who owns the code?
You do, as before. All changes are committed to your repository.
How long does it take?
A batch of bug fixes or one feature usually takes one to two weeks from the signed scope; upgrades and server moves one to three weeks.
Will you rewrite it in something else?
Not unless you ask, and we would only recommend it with a clear reason. Most applications are better repaired than rewritten.
What happens after handover?
For 30 days we fix anything we changed that does not work as the scope describes, at no charge. After that, changes are written up and agreed with you before we begin.
Tell us what you need built.
Email a few lines about what you want and which tools you use, or call. We reply with questions or a written scope.
hello@pushbuild.com