Custom PHP applications built around how you actually work

What custom php applications actually means

Custom PHP development means building the application a business actually runs on, rather than bending an off-the-shelf product until it almost fits. Booking systems, client portals, quote calculators, admin dashboards, and integrations with whatever API the business already depends on.

The test for whether you need one is simple: if the process that makes you money currently lives in a spreadsheet that only one person understands, that spreadsheet is your application and it is a single point of failure.

Who this is for

• Businesses whose process does not fit any product they have tried
• Teams running critical operations from a spreadsheet nobody dares restructure
• Companies paying for several SaaS tools to approximate one workflow
• Anyone who needs customer logins, role-based access or an approval step
• Businesses with an existing system that needs extending rather than replacing

Who it is not for

Saying this out loud costs me some enquiries and saves both of us the ones that would have gone wrong. If you are on this list, I will tell you in the first reply rather than after a deposit.

• Native mobile applications — different platform, different skill set, and I will say so
• Anything needing real-time infrastructure at large scale
• Problems a well-configured off-the-shelf product already solves, where custom is an expensive way to be different
• Projects with no internal owner. Custom software needs someone who can decide

The problems it solves

A process living in one spreadsheet

Modelled into a documented schema with an interface built for whoever uses it daily.

Double entry between systems

API integration where one exists, scheduled import where it does not.

No visibility for the people who need it

Role-scoped views: the counter sees today, the owner sees the month.

Manual work that repeats every day

Automated where the rules can be written down, and left alone where judgement is genuinely required.

Data nobody can get out

Exports in formats your accountant and your next developer can both use.

What you get

• Database design and schema, documented rather than improvised
• Application build in PHP with a MySQL backend
• Admin interface built for the people who will use it daily
• Role-based access control where more than one person logs in
• Third-party REST API integrations
• Transactional email via PHPMailer with proper SPF/DKIM alignment
• Input validation, prepared statements and CSRF protection throughout
• Written handover documentation — you are not dependent on me to keep it running

What is included in the starting price

Everything below is in the $200 figure. Nothing here is quoted as an extra once the build is underway, which is the point of publishing it.

• Database design, documented rather than improvised
• Application build in PHP with MySQL
• Admin interface designed around the daily task, not the table structure
• Role-based access control where more than one person logs in
• Input validation, prepared statements and CSRF protection throughout
• Transactional email with proper authentication
• Written handover documentation aimed at whoever maintains it next
• 30 days of snag fixes after go-live

What costs extra, and why

A quote that omits these is not cheaper — it is less honest. Each one is real work that someone has to do, and pretending otherwise is how a fixed price becomes a negotiation in week two.

Data migration from an existing system

Depends entirely on the state of the current data, which is usually worse than remembered.

Third-party API integrations

Each is its own small project. Undocumented APIs cost more than documented ones.

Bulk historical data entry

If it cannot be imported, someone has to type it, and that time is real.

Ongoing feature development

Better handled as a small monthly block than as a series of one-off quotes.

How the work runs

1. Map the process. I sit with how the business actually works today, including the spreadsheet everyone pretends is not load-bearing.
2. Model the data. Schema first. Getting this wrong is what makes applications expensive to change later.
3. Build in slices. One working feature at a time on a staging URL, so you can correct course early rather than at handover.
4. Harden. Prepared statements, validation, access control and error handling — before launch, not after an incident.
5. Hand over. Documentation, credentials and a walkthrough. You own everything.

Day by day

10 days from the day scope is signed off. Published as a schedule rather than a promise of speed — you should be able to tell on day three whether a build is on track.

The technology

Deliberately boring, and that is the feature. A stack another developer can pick up is worth more to you than one that impresses other developers.

Language

PHP 8 — because it runs on hosting you already pay for and any developer can pick it up

Database

MySQL with a documented schema and real foreign keys

Front end

Tailwind CSS with Alpine.js. Server-rendered, so it works on a slow connection

Email

PHPMailer over authenticated SMTP

Deployment

Git-based where your host supports it, documented either way

What it integrates with

• Any documented REST API
• Payment providers, including Stripe for one-off and recurring charges
• Accounting exports your bookkeeper will accept
• Email and notification delivery from your own domain
• Scheduled imports and exports where a live API does not exist
• Single sign-on where your team already has an identity provider

What I need from you

Short list, and the first item matters most. Projects do not usually slip because the code was hard — they slip because a decision waited a week.

• Someone who knows how the process actually works, including the exceptions
• Access to the current system or spreadsheet, with real data rather than a tidied sample
• API documentation and credentials for anything to be integrated
• A decision-maker for scope questions — custom work generates more of them than a website does
• Time from the people who will use it daily, at the point where it is testable

Content and photography

The requirement nobody writes down is the exception. Every business has a "well, except when…" case, and it is usually the one that decides whether the software gets used or quietly abandoned.

So the mapping stage asks for exceptions explicitly, in writing, before the schema is designed. Discovering one in week two is a change request; discovering it after launch is a rebuild.

Performance standards

Targets, not aspirations — measured before handover on a throttled mobile connection rather than on a fast laptop.

Accessibility standards

This site is built to the same standard it sells, and the accessibility statement lists what is conformant and what is not — which is the part most statements leave out.

Security practices

The SEO included in every build

Not an upsell. A site that launches unindexed is a shop with the shutters down, and the work below is cheap during a build and expensive afterwards because the fixes are structural.

Ownership and handover

You own everything: the domain registered to you, hosting in your account, code in a repository you control, and the payment provider account in your business name. Credentials are handed over as they are created rather than at the end.

A supplier who resists this is protecting recurring revenue rather than your interests. If you want the reasoning in full, including how to check your current site, there is a guide on it.

Aftercare and what happens after launch

Thirty days of snag fixes are included. A snag is something that does not work as scoped — not a new feature, and the difference is written down before launch rather than argued about after it.

You also get written handover documentation aimed at whoever maintains the site next, which may well not be me. That is deliberate: the test of a good handover is whether another developer could take over without calling me, and on my projects they can.

Ongoing maintenance

Optional, monthly, cancellable. Nothing here is required to keep what you paid for.

Payment terms

How this compares to the alternatives

Including the routes that do not involve me, because a comparison that only flatters the author is not a comparison.

What could go wrong, and how it is handled

Scope grows once people see it working

Expected, and handled with a written change process rather than silent absorption or an argument.

The existing data is messy

It always is. Assessed before quoting migration, because clean-up is often larger than the build.

Key-person dependency on me

Managed structurally: your repository, documented schema, boring stack, written handover. Another developer can take it over.

Nobody uses it

The real risk with custom software. Mitigated by involving daily users at the testable stage rather than at launch.