Custom PHP

Custom PHP development without the framework weight

Small, fast tools written in plain PHP or a micro-framework. Structured like a real application, light enough for shared hosting, and simple enough for the next developer to read in an afternoon.

  • Runs on basic hosting
  • Few dependencies to patch
  • Readable by the next developer
What is included
  • Front controller and routing
  • PDO data layer
  • Templates that escape by default
  • Sessions and sign-in
  • Security basics, done properly
  • Small footprint
Get a free quote Reply within one business day. NDA on request.
The problem

When a framework feels like too much

Some software does not need a framework. A quote calculator on a marketing site. A form that takes a payment and writes a PDF. A small portal where a few dozen dealers download price lists. A script that receives webhooks from a courier and updates order status. Wrapping tools like these in a large framework adds hundreds of files to keep patched for a job that needs a dozen.

Custom PHP development, as we mean it, is writing exactly the application you need on a thin base: a front controller, a router, a database layer, templates and a few audited libraries. It still has structure and tests. It simply carries less. When a project outgrows that approach we say so, and point you to Laravel application development or CodeIgniter development.

  • A small tool was quoted like a platform

    You asked for a calculator, an intake form or a dealer login and received proposals for a full framework build with an admin panel you will never open. The job is smaller than the quote.

  • Your hosting cannot run a modern framework

    The site lives on shared hosting with no shell access, no queue workers and a fixed PHP setup. Moving servers for one small feature is not worth it.

  • Old procedural scripts keep growing

    A folder of PHP files that each open their own database connection and print their own HTML. It works, but adding one field means editing nine files and hoping.

  • Framework upgrades cost more than the tool earns

    A simple internal tool sits on a framework that needs a major upgrade every couple of years. Each upgrade is paid work with no visible benefit to the people using it.

What we do

What a lean PHP build contains

A plain PHP application from us is small, but it is not a pile of scripts. Each build has the same six parts.

Front controller and routing

One public index.php receives every request and a router maps URLs to controller methods. Clean URLs, no stray scripts reachable from the browser, and one place to add middleware.

PDO data layer

A single PDO connection, prepared statements for every query and a small repository class per table. No SQL in templates, and no string-built queries anywhere.

Templates that escape by default

Twig or native PHP templates with a helper that escapes every value on output. Layouts and partials keep markup in one place and logic out of it.

Sessions and sign-in

Passwords stored with password_hash, session IDs regenerated at login, cookies flagged HttpOnly, Secure and SameSite, login throttling, and password reset by expiring single-use token.

Security basics, done properly

CSRF tokens on every state-changing form, output escaping against XSS, bound parameters against SQL injection, validated uploads stored outside the web root, and security headers set once.

Small footprint

A handful of Composer packages we can name and justify, OPcache-friendly code and pages that render in a few database queries. Easy to host and quick to audit.

Typical projects

Things we write in plain PHP

01

Calculators and configurators

Price, loan, shipping or product configurators that sit inside an existing website, save each quote to a database and email a PDF to the visitor and your sales team.

02

Small portals with logins

Dealer, member or client areas with a few roles, document downloads, a profile page and an admin screen to manage accounts. Sized for hundreds of users, not for a platform.

03

Webhook receivers and scheduled scripts

Endpoints that accept events from payment, courier or form services, verify the signature and update your records. Cron scripts that sync, export or send reminders overnight.

04

Structured rewrites of old scripts

A procedural PHP tool rebuilt screen by screen into controllers, repositories and templates, keeping the same database and URLs so users notice only that it is faster.

In depth

Inside a framework-free application

The skeleton we start from

The web server points at a public folder that holds one PHP file and your assets. Everything else, including configuration, templates and classes, sits above the web root where a browser cannot request it. That single entry file loads the Composer autoloader, reads settings from an environment file, starts the session and hands the request to a router. Controllers stay thin: read input, call a service, return a response. Business rules live in plain classes with no knowledge of HTTP, which is what makes them testable with PHPUnit.

Micro-framework or hand-rolled

We rarely write a router or a template engine ourselves. Slim, or a few Symfony components wired together, gives you routing, request and response objects and middleware in a small, well-maintained package. We go fully dependency-free only when the brief demands it, for example a single-file tool that must be dropped onto servers we do not control. Either way the rule is the same: every package in composer.json has to earn its place, because each one is something to update later.

Security is where plain PHP projects fail

A framework gives you CSRF protection, escaping and query binding without asking. Without one, they exist only if someone builds them. So we build them first, before any feature. Every POST, PUT and DELETE route checks a per-session token. Every template value passes through an escaping helper unless it is explicitly marked as safe HTML. Every query uses bound parameters, including the ones on admin screens that only staff will see. File uploads are checked by content type and size, renamed, and stored where they cannot be executed. Then we test it the unfriendly way, by submitting forms without tokens, pasting script tags into every field and tampering with IDs in URLs.

When no framework is the right call

Choose this route when the tool is small and well defined, when it has to run on shared hosting, when it should keep working for years with little attention, or when it must sit inside another PHP site without clashing with it. Fewer moving parts means fewer forced upgrades and a codebase one developer can hold in their head.

When it is the wrong call

The moment a brief includes queues, complex permissions, a public API, multi-step workflows and a growing team, plain PHP stops being the economical choice. You would end up paying us to rebuild what a framework already ships. We would rather tell you that on the first call. For work in that range, see PHP web application development, where a framework is usually the starting point.

Process

Steps from brief to a running tool

  1. 1

    Scoping call

    You describe the tool, the users and where it will be hosted. We confirm that a lean build fits, or recommend a framework if it does not.

  2. 2

    Screens and schema

    A short specification lists each screen, each table and each rule. You approve it before any code is written, so the quote covers a known scope.

  3. 3

    Skeleton and security layer

    Routing, database access, sessions, CSRF and escaping go in first. Features are then added on a base that is already safe.

  4. 4

    Features on staging

    Each screen is delivered to a staging URL for you to try. Feedback is handled in small rounds while the work is fresh.

  5. 5

    Release to your hosting

    We deploy to your server or hosting plan, set up cron jobs and backups, and hand over a README covering setup, configuration and how to add a page.

Deliverables

What lands in your repository

  • A small codebase a new developer can read quickly
  • CSRF, XSS and SQL injection defenses built in and tested
  • Composer dependencies you can count on two hands
  • Works on shared hosting, a VPS or a container
  • Repository, database and credentials in your name
FAQ

Plain PHP questions answered straight

Is plain PHP less secure than a framework?
It does not have to be, but the protections are not automatic. In a framework-free build we add CSRF tokens, output escaping, prepared statements and hardened session settings ourselves, then test them deliberately. Written with that discipline, a plain PHP application holds up as well as a framework one.
What happens if the tool grows beyond a small build?
Because the code is organized into controllers, services and repositories, it can be moved into a framework without starting again. The database stays, the business classes move across largely unchanged, and routes are declared again. We flag the point where that move makes sense before the small base is stretched too far.
Can you add a custom PHP tool to our existing website?
Yes. A calculator or portal can live in a subfolder or subdomain of a WordPress, static or older PHP site, sharing the design and, where needed, the login. We keep its code and database tables separate so updates to the main site do not disturb it.
Do you write tests for small projects?
Yes, in proportion to the risk. Price calculations, permission checks and anything that moves money get PHPUnit tests. Simple display pages are covered by a manual test script. Static analysis runs on the whole codebase regardless of size.
Will it run on our shared hosting plan?
In most cases, yes. We need a supported PHP version, a MySQL or MariaDB database, and the ability to point the domain at a subfolder. If shell access is missing we deploy over SFTP with dependencies bundled, and use the cron panel your host provides for scheduled jobs.
How is this different from your Laravel or CodeIgniter work?
The engineering standards are the same and the starting point differs. Framework projects begin with a large toolkit already in place. Custom PHP projects begin almost empty and add only what the brief needs. For small tools the second approach means less to host, less to patch and less to learn.
Start a project

Have a small tool that needs building properly?

Describe the tool and where it has to run. We reply within one business day, tell you honestly whether plain PHP fits, and follow up with a free quote.

  • Free consultation and quote
  • NDA on request
  • You own the source code
  • Reply within one business day
Add budget and timeline optional, helps us quote faster

This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.