Dev recommends PHP and MySQL for a web app — is it outdated or totally fine?

Your friends are probably thinking of the spaghetti code from legacy PHP versions 15 years ago. Modern PHP versions are strictly typed, extremely fast, and built for enterprise-grade testing. Just make sure he isn't writing raw PHP without any libraries and that he uses a well-known MVC architecture.

When drafting the contract with the developer, get these in writing: 1) The code must be hosted in an enterprise Git repo with ownership belonging to you, 2) The database tables must be set up relationally, 3) Handover of setup and data structure documentation. It's the absence of these items that paralyzes a system, not the language.

PHP isn't bad, but the developer's habits matter. If the dev tries to sell you on a 10-year-old custom framework he wrote himself that's a massive risk. No modern programmer will want to take that code over, and you'll end up paying 80 GBP/hr for consulting down the road.

We had a similar warehouse management portal built 4 years ago with PHP and MySQL... Our server cost isn't even 15 quid a month. anyway runs like clockwork hasn't crashed once. Don't blow your budget chasing tech trends imo.

Correction: I misremembered the figure, it was a bit lower.

devs always love hyping up whatever is shiny and new. if it does the job loads fast, and has low server bills, the tech stack is secondary. what matters is that the dev doesn't ghost you after finishing the job.

While freelance developer rates in the UK average between 60-90 GBP for more niche languages, a competent PHP dev can be found around 40-65 GBP. That will save your business budget considerably whenever you want to add new modules down the line.

The success of the project depends on the accuracy of the business analysis processes rather than the programming language. Provided your required workflows are thoroughly defined, data security protocols are implemented, and a regular backup infrastructure is established, PHP and MySQL will fulfill your requirements completely.

what if we want to hook this system up to a mobile app later on? tbh will PHP get in the way, or would it have to be rewitten from scratch?

edit: fixed a few typos.

Correct. When you try to change everything at once, nothing settles.

Proven by experience.

Same here.

I didn't know that.

Let me summarize what's been said so far. If you don't write this down from the start, it leads to arguments later.

Just leaving this note, it might be useful.

I agree, and I'd like to emphasize that. If acceptance criteria aren't written, when the work is done is open to debate.

Payment schedules should be tied to project phases, not calendar dates. Good luck with that.

We need to take it step by step. The harder it is to reverse a decision, the slower you should make it.

Of course, it varies if your situation is different.

You're right. Implementing a change request process doesn't slow things down, it speeds them up.

This is my opinion, I'm not claiming it's absolute truth.

We experienced almost the exact same thing last year. In legacy systems, the most expensive thing is unknown dependencies.

Correct me if I'm wrong.

You're right, I've been down that road too. When we decide without measuring, we always end up in the same place.

If you post the result here, it will help others too.

My questions are cleared up thanks.