EYThe LogEmre Yakut
← all entries
Field · Debugging

Press the button before you write the proposal

I was preparing a draft for a luxury car service. I opened their site, clicked “Book an appointment”, and PHP errors poured onto the screen. That became the subject of the whole proposal.

randevu.phpWarning: Undefined array key "tarih" in /home/.../randevu.php on line 84Warning: Undefined array key "saat" in /home/.../randevu.php on line 85Fatal error: Uncaught mysqli_sql_exception: Column 'appointment_at'cannot be null in /home/.../randevu.php:91RANDEVU AL → hiçbir şey olmazteklif yazmadan önce: müşterinin sitesini gerçekten aç, gerçekten tıkla

A supercar and luxury vehicle service. The business is serious — so are the expectations of the people who bring those cars in.

Before preparing a draft I did what I always do: I opened their current site. Then I did what most people skip — I pressed the button.

What was on the screen

Warning: Undefined array key "tarih" in /home/…/randevu.php on line 84
Warning: Undefined array key "saat" in /home/…/randevu.php on line 85
Fatal error: Uncaught mysqli_sql_exception: Column 'appointment_at'
cannot be null in /home/…/randevu.php:91

The booking form did not work. A customer tries to book their car in, sees this, and leaves.

There are two separate problems here

The visible one: the form is broken. Submitted fields do not arrive under the expected names, the database refuses a null date, the request dies. That is a bug; it gets fixed.

The more serious one: that the error is visible at all.

an error message is a map

Those four lines reveal the full server path, the script name, its length, the database column name and its constraint, and which driver is in use. Free reconnaissance for an attacker.

In production display_errors is off and log_errors is on — the error does not disappear, it moves.

How you put this in a proposal

The easy route: paste the screenshot and say “this is the state of your site”. It works, and it puts the reader on the defensive.

I wrote three sentences instead:

5 August 2026, 14:20 — submitting the booking form ends in an error page and no record is created. On the same screen, server file paths and database column names are visible. Both are reproducible.

The difference: the first is a criticism, the second is a record. A record is not arguable — it is either true or it is not, and you can go and check.

And it makes them ask the real question

Reading that finding, a service owner’s first question is not “how do we fix it?”

It is: “how long has it been like this?”

Nobody knows. A broken form is silent. It leaves one line in a server log, a disappointment in a user, and no trace at all in the business. When bookings do not come in, nobody says “is the form broken?”; they say “it was a quiet month”.

An unmeasured loss does not look like a loss. That was the real subject of the proposal.

On the draft side

A generic “car service” template did not suit this firm. The cars that arrive are dark, heavy and expensive; the site became the same — dark ground, generous space, few but large typographic elements.

I redesigned the booking flow too: vehicle first, then service, then date. One decision per step. And most importantly — if submission fails, the user knows. It does not swallow it silently and it does not throw an error trace at them; it says “we could not save this, please call this number”.

What I learned

Looking at a site and trying a site are not the same thing. The home page can be flawless; the part that does the work is the submit side of a form, and it can sit broken without ever being opened.

Now every audit includes actually filling in at least one form. It takes five minutes, and the strongest sentence in the proposal comes out of it.

FieldDebugging