Choose a PHP development company by how it answers specific questions, not by its portfolio page. Ask which PHP and framework versions it will build on, who owns the code and accounts, how it handles security and dependencies, what checks run before each release, and what happens after launch. A good company answers each one plainly, with dates and examples from its own work; vague answers on versions, ownership or testing are the clearest warning signs. If you are still deciding whether PHP is the right fit, our PHP development services page explains what we build with it.
Key takeaways
- Ask for versions with dates. As of October 2026 the supported PHP branches are 8.2 (security fixes only, ending 31 December 2026), 8.3, 8.4 and 8.5. A new project on anything older is a red flag.
- Code, repository, hosting and payment accounts should be in your name from the first week, not handed over at the end.
- Security and dependency answers should name real practices: the OWASP Top 10, Composer's audit, framework protections, automated tests and static analysis.
- Ask what they built in similar projects, feature by feature. Logos and screenshots prove little.
- A company that suggests a paid code review before estimating work on an existing system is usually being careful, not slow.
A note on who is asking: we are a PHP development company ourselves (founded in 2005), and our published case studies include PHP projects going back to 2012. Read the questions below as the ones we would want a client to ask us.
Should you hire a freelancer, an agency or an in-house developer?
It depends on how long the system will live and how much of it there is. A single well-scoped task (a plugin fix, a version upgrade on a small site) suits a strong freelancer. A business application with several roles, payments and integrations needs more than one person: someone to review code, someone to test, and cover when a developer is away. That is what an agency or development company gives you. In-house makes sense once the software is central to the business and changes every week; many companies start with an agency and hire later. The questions below apply to all three.
Which PHP version and framework will they build on?
1. Which PHP version will the project run on, and when is the next upgrade?
A good answer names a supported branch and its end date. PHP gives each branch two years of active support and two more of security fixes only. As of October 2026, PHP 8.4 (released 21 November 2024) and 8.5 (20 November 2025) are in active support, 8.3 has security fixes until 31 December 2027, and 8.2 reaches end of life on 31 December 2026. Our PHP version support dates guide keeps the full table.
Red flag: "whatever the server has", or a quote for a new build on PHP 7 or 8.0. Unsupported versions get no security fixes.
2. Which framework or platform, and why this one for us?
A good answer ties the choice to your project. Laravel or Symfony for a custom application; Magento, WooCommerce or PrestaShop for a store; WordPress for a content site; and an existing framework such as Yii if that is what your system already runs on. If they propose Laravel, they should know its support policy: bug fixes for 18 months and security fixes for two years per major release. Laravel 13 came out on 17 March 2026 and requires PHP 8.3 or later; Laravel 12 gets security fixes until 24 February 2027.
Red flag: one framework for every project, or a custom in-house framework that only that company understands.
3. What exactly did you build in a project like ours?
A good answer lists features, not adjectives. As an example of the level of detail to expect, here is what our own published case studies say we built:
- For Scuela, an e-learning marketplace, Laravel REST APIs behind a Vue.js frontend, Stripe and PayPal payments with refunds and Strong Customer Authentication, membership plans on Stripe subscriptions, a multi-level affiliate system, and separate academies on their own subdomains over a single database.
- For AXENCIS, a brand protection company, a Laravel and Vue case management platform with role-based portals for investigators, reviewers, clients and law firms, evidence capture as merged PDFs with redaction and trusted timestamping, and accounting exports.
- For QCare, DEKRA's compliance platform, API endpoints in a Yii 2 PHP API for certifications, organisations and training programmes, and the APIs behind a headquarters dashboard.
Red flag: a page of client logos, with no one able to say which parts the company actually wrote.
Who owns the code, and what happens if you part ways?
4. Will the repository, hosting and third-party accounts be in our name?
A good answer: yes, from the start. The Git repository sits in your organisation's account with the company invited as collaborators; hosting, domain, email service and payment gateway accounts are yours; the contract assigns the code to you on payment.
Red flag: "we host everything for you" with no route to export, or payment keys registered to the agency.
5. If another team took over tomorrow, what would they receive?
A good answer: the repository with full history, a README that gets a new developer running locally, environment variables documented (values shared separately and securely), database migrations rather than hand-edited schemas, and a list of every external service the system calls.
Red flag: the setup lives in one developer's head.
How do they handle security and dependencies?
6. How do you protect against the common attacks?
A good answer refers to the OWASP Top 10 (the 2025 edition puts broken access control first, followed by security misconfiguration and software supply chain failures) and explains how the framework handles the basics: parameterised queries instead of building SQL from strings, output escaping, CSRF protection, password hashing, and access checks on every route, not only on the menu. Our older PHP security tips for developers cover the basics in more detail.
Red flag: "PHP is secure" or "we have never been hacked".
7. How do you manage third-party packages?
A good answer: Composer with the composer.lock file committed, so every environment installs the same versions; composer audit checks installed packages against security advisories and other dependency policies, and Composer's update and require commands run that audit by default. They should also say how often they apply updates and who watches advisories after launch.
Red flag: libraries copied into the project by hand, or no lock file.
How do they test and release?
8. What runs automatically before code reaches production?
A good answer names the checks: automated tests (PHPUnit or Pest) for the parts that handle money, permissions and data; static analysis such as PHPStan; a coding standard (PHP-FIG's PER Coding Style or the framework's own, enforced by a formatter); and a code review by a second developer.
Red flag: "our developers test everything manually before release".
9. How many environments are there, and how does a release happen?
A good answer: at least development, staging and production, with configuration kept separate for each, and releases from a pipeline rather than files copied over FTP. On QCare, for example, we set up a build and release pipeline on AWS CodeBuild and CodeDeploy with separate development, staging and production configurations.
Red flag: changes made directly on the live server.
How do they work with you day to day?
10. How will you estimate, and how are changes handled?
A good answer separates what is known from what is not. For an existing system, expect a short, paid code review first: on Scuela, the first task was recovering and redeploying a frontend before new features could be built. For new work, expect the scope written down as features, a stated way of handling change requests, and a clear line between fixed-scope and time-based work.
Red flag: a firm price for a large project after one call, with no written scope.
11. Who will we talk to, and how often?
A good answer: a named project lead, a regular update rhythm (weekly is common), a shared issue tracker you can see, and working-hours overlap agreed up front. Time zones matter less than a fixed overlap window and written updates. Our own teams work from Mohali in India and Ontario in Canada.
Red flag: you only ever speak to a salesperson.
12. What happens after launch?
A good answer: a maintenance arrangement that covers PHP and framework upgrades on a schedule (PHP 8.2 sites, for instance, need moving before 31 December 2026), security patches, dependency updates, backups and monitoring, with response times written down.
Red flag: "it will not need anything once it is live".
What are the red flags at a glance?
| Area | Red flag |
|---|---|
| Versions | New build on an unsupported PHP version; no upgrade plan |
| Proof | Logos without a list of what they built |
| Ownership | Repository, hosting or payment accounts in the agency's name |
| Security | No mention of OWASP, access control or dependency audits |
| Quality | No automated tests, no code review, edits on the live server |
| Estimates | Fixed price for a large project without written scope |
| After launch | No maintenance or upgrade plan |
FAQ
How many questions should I ask before choosing a PHP company?
Ask all twelve, but weight them. Ownership (questions 4 and 5), versions (1 and 2) and release practice (8 and 9) are the ones where a wrong answer is expensive to fix later. Ask two or three companies the same questions so you can compare the answers side by side.
Is PHP still a sensible choice for a new project in 2026?
Yes, for many web applications. PHP has a published release schedule with four years of support per branch, PHP 8.5 was released in November 2025, and Laravel 13 shipped in March 2026 with built-in AI and vector search features. The better question is whether the company you hire keeps its PHP work on supported versions.
Should I ask for a paid trial task?
For a large project, a small paid task (a code review of your existing system, or one well-defined feature) is a fair way to see how a company works before committing. It shows you their communication, code quality and estimating in practice.
What should a PHP development contract include?
Scope of work, code and IP ownership on payment, who holds which accounts, how changes are priced, warranty and maintenance terms, confidentiality and data handling, and how the relationship ends, including handover. This is general information, not legal advice; have a lawyer review the contract.
Can a PHP company take over a system another team built?
Usually, yes. Expect a code review first to check versions, dependencies, security and test coverage, then a written list of what needs fixing before new features. A company that agrees to add features without looking at the code first is taking a risk with your system.
Impinge Solutions, founded in 2005, builds and maintains PHP applications, stores and APIs on Laravel, Yii, Magento, WordPress and PrestaShop. See our PHP development services for how we work.
Sources (7 links)
- PHP, "Supported Versions" (checked 29 October 2026): https://www.php.net/supported-versions.php
- Laravel, "Release Notes" for Laravel 13.x, including the support policy table: https://laravel.com/docs/13.x/releases
- Composer, "Command-line interface / Commands" (audit, install, update, require): https://getcomposer.org/doc/03-cli.md
- OWASP, "OWASP Top 10:2025": https://top10.owasp.org/2025
- PHP-FIG, "PER Coding Style": https://www.php-fig.org/per/coding-style/
- PHPStan, PHP static analysis tool: https://phpstan.org/
- PHPUnit, testing framework for PHP: https://phpunit.de/
