DEV Community: Emmanouil Vasigia

Debug the mobile menu as four separate interactions

Emmanouil Vasigia — Sun, 04 Oct 2026 16:32:27 +0000

A mobile menu can pass one check and fail the next. If you maintain an existing site, test the path from the menu control to a service page as four separate interactions: the control is visible, a tap opens the intended menu, the relevant link is available, and that link reaches the intended page.

That sequence is more useful than a single “mobile navigation works” verdict. It also keeps the first debugging step close to what you can observe, before you decide which code to inspect.

Start with the observable result

Use a phone and write down what happens at each step. Keep the observations separate from any proposed cause.

Visibility: Is the menu control present on the phone screen? Record the page and screen size you tested. A successful desktop check does not answer this question.
Tap behavior: If the control is visible, what appears after one tap? Record whether you see menu options, a different page, or no visible change.
Option availability: If the menu opens, can you see and select the link you need? If it is nested, test whether you can reach it rather than assuming the parent item is sufficient.
Destination: Tap the link and check the page that loads. A menu that opens is not, by itself, a completed path to the service page.

Run the sequence from the actual page a visitor might land on, not just the homepage. If you change anything while testing, note the change and run the same sequence again. That gives you a narrower comparison than trying several adjustments and then asking whether the menu feels better.

Keep three reported symptoms distinct

An individual Squarespace forum report described a menu that appeared on desktop but was absent on phones. A responder identified custom CSS as the cause in that discussion. For a comparable symptom on your own site, the first question is whether the control is rendered and visible at the phone size you are testing. There is no tap behavior to debug until you can see and use the control. The forum exchange is one case, not evidence that CSS is the cause whenever a mobile menu is missing.

A separate Squarespace report described a different result: tapping the mobile menu opened a Connect page instead of showing menu options. That site owner attributed the issue to custom code. In that case, the control was visible enough to tap, so treating the problem as a missing-menu issue would skip the most useful observation: where did the tap take the visitor? Record the destination before changing anything. The reported attribution to custom code belongs to that particular case; it is not a diagnosis for another site.

A WordPress support discussion adds a third distinction. The site owner reported that submenu items did not expand on a phone despite working on desktop. A responder said the items worked in their test. That disagreement matters. If you cannot reproduce a reported failure, document the phone, browser, page, and exact sequence used for each test rather than declaring either observation wrong. The report identifies a symptom to investigate, not a confirmed cause or a universal WordPress behavior.

These accounts come from individual site owners. They do not establish how often these problems occur, and they do not establish a pattern among service-business websites. Their practical value is narrower: they show why “the mobile menu is broken” is not a precise enough starting point.

Match the investigation to the failed step

When the control is absent, check the phone-sized view before examining link destinations. Compare the same page on phone and desktop, and note whether the absence occurs on every page you test or only one. If the site has custom CSS, consider it a candidate to inspect, not a confirmed explanation. Change one relevant rule at a time in a controlled test, then repeat the visibility check.

When a tap goes to a page instead of opening options, capture the destination and identify the element you tapped. Inspect the configured behavior and any custom code associated with that control before you start rearranging menu items. A link to the wrong page and a menu that never opens may look similar to a visitor, but they lead to different questions for the person debugging.

When a submenu does not expand, test the parent item and the submenu separately. Note whether a tap navigates, expands the submenu, or appears to do nothing. Try to reproduce the behavior under a documented set of conditions before assigning a cause, particularly if another tester gets a different result.

When the menu opens but the service link is not available, inspect the options actually shown on the phone. Finding a service page through desktop navigation does not establish that a phone visitor can find it through the mobile menu. If the link is present, complete the test by selecting it and checking its destination.

This is a diagnostic sequence, not a claim that any particular site has a navigation defect. The useful output is a small, reproducible description: the page tested, the device conditions, the interaction attempted, and the result at the first step that did not behave as intended. That description gives you a better basis for investigating your own implementation than a broad label such as “mobile menu issue.”

Test a contact form as three separate checkpoints

Emmanouil Vasigia — Sat, 03 Oct 2026 18:56:18 +0000

Before changing a contact form, run one traceable test through the path you expect an inquiry to take. Record three observations separately: what the sender sees, what the business receives, and what happens when the business responds. A success message answers the first question, not all three.

This distinction matters because the checkpoints can disagree. In one Shopify community report, contact-form submissions appeared to succeed but did not arrive by email. That is an individual report, not a measure of how often this happens or an explanation of its cause.

Set up a test you can recognize

Use the public form as a visitor would. Before submitting it, write down:

The email address you will use as the test sender
The person or destination expected to receive the inquiry
A distinctive phrase to put in the message, such as contact-path-test-0414
Who will check for receipt and, if applicable, send a response

The phrase is a matching key for this test. Keep it in your notes and in the form message so the recipient can distinguish this submission from other inquiries. If several people might handle messages, choose a designated checker for the test rather than relying on an unconfirmed assumption that someone saw it.

Checkpoint 1: Observe the form response

Submit the test inquiry and record the time, the page you submitted it from, and the exact on-screen result. Did the form display a confirmation? Did it display something else?

Describe only what you observed. For example: “Test submitted at 2:10 p.m.; confirmation displayed.” Do not turn that into “message delivered.” The form response is useful evidence about the sender-facing step, but receipt needs its own check.

If the form does not show a confirmation, record that outcome too. It gives whoever investigates the site a different starting point than a test that displayed a confirmation but could not be matched to a received inquiry.

Checkpoint 2: Match the received inquiry

Ask the designated checker to look at the destination chosen before the test. Have them look for the distinctive phrase and compare the inquiry with the test you submitted. Record whether they found a matching message and when they checked.

Use a result label that preserves the distinction:

Form observation	Receipt observation	What you can conclude from this test
Confirmation displayed	Matching inquiry found	This test reached the checked destination
Confirmation displayed	No matching inquiry found during the check	Receipt at that destination was not verified
No confirmation displayed	Matching inquiry found	The sender-facing result and receipt need separate examination

These labels describe observations, not causes. In particular, “not found during the check” does not identify where the inquiry went or which part of the site needs changing. Keep the test phrase, submission time, checked destination, and check time together so a site maintainer can examine the discrepancy without reconstructing the test from memory.

If you run a second test, give it a different phrase and record it separately. That keeps a later result from being mistaken for the first submission. A successful second test also does not erase the first observation; it tells you that the two tests had different observed outcomes.

Checkpoint 3: Observe the response path, if you are testing it

Once a matching inquiry is found, you can extend the test through the normal reply process. Ask the person handling the inquiry to respond to the test sender, then check that sender address and record what arrived. If responding involves a handoff to another person or workspace, note who performed that step.

Keep this result separate from notification receipt. “Inquiry found” records what the business saw. “Response sent” records an action by the business. “Response found at the test sender address” records the sender-side observation. If the inquiry was not found, label the response step “not tested” rather than treating it as a failed reply.

This third checkpoint is a workflow check, not a claim that the form itself controls replies. It helps make the scope of a completed test explicit: did you stop when the business received the inquiry, or did you also observe a response at the sender address?

Keep the result narrow

A useful final note might read: “Confirmation displayed at 2:10 p.m.; designated checker did not find the matching inquiry at the expected destination by 2:25 p.m.; response not tested.” A different test might record all three observations as completed. Neither result establishes what will happen to every future inquiry.

For an existing website, this test is a more useful diagnostic than relying on the confirmation screen alone. It replaces a single “form works” checkbox with a record of where verification actually stopped.

I Tried to Make AI Build a Complete Website From One Sentence. Here’s What Broke

Emmanouil Vasigia — Mon, 28 Sep 2026 17:49:46 +0000

I Tried to Make AI Build a Complete Website From One Sentence. Here’s What Broke
The demo worked in minutes. Making it reliable enough for real users took much longer.
The first version looked almost too easy.
Give the AI one sentence:
“I run a roofing company in Austin.”

A few seconds later, you have a homepage.
Nice headline.
Services section.
CTA.
Decent copy.
At that point, it is very tempting to think:
“Okay. The hard part is done.”
It wasn’t.
The hard part started when I stopped asking AI to generate a page and started asking it to generate an entire website that a real business could actually use.
That changed everything.
A homepage is easy
LLMs are very good at producing something that looks convincing once.
Give them a prompt and they can generate:

a hero section
service descriptions
an About section
testimonials
FAQs
calls to action For a demo, this is enough. For a real website, it is nowhere near enough. A website needs consistency across multiple pages. The navigation has to make sense. The copy cannot contradict itself. The layout needs to survive mobile screens. Buttons need to point somewhere real. Sections cannot randomly disappear. The business name cannot change halfway through the site. And the AI should probably not invent a phone number. That last one happened more often than I expected. Problem #1: The AI had no idea what the website actually was My first approach was basically: Here is the business.

Generate the website.

The output looked fine.
Until I generated another page.
Then another.
Suddenly the website had three different personalities.
The homepage sounded premium.
The services page sounded like a discount contractor.
The About page sounded like a Fortune 500 company.
The model was generating pages independently.
That was the mistake.
A website is not a collection of unrelated prompts.
It needs a shared source of truth.
So instead of generating pages immediately, I started generating a structured representation of the business first.
Something closer to:
{
"business": "Austin Roofing Co",
"industry": "Roofing",
"location": "Austin, Texas",
"audience": "Homeowners",
"tone": "Professional and local",
"services": [
"Roof repair",
"Roof replacement",
"Storm damage repair"
],
"primaryGoal": "Request a quote"
}

Every page then uses the same context.
This sounds obvious now.
It was not obvious in version one.
Problem #2: AI loves inventing things
Ask an AI to create a business website and it wants to be helpful.
Sometimes a little too helpful.
It may invent:

customer testimonials
awards
years of experience
certifications
addresses
statistics
phone numbers A sentence like: “Trusted by 2,000 homeowners since 1998”

looks fantastic on a landing page.
There is only one problem.
Nobody told the AI that.
For a fictional demo, this is harmless.
For a real business, it is a serious problem.
So I had to start treating certain information differently.
There are facts the model can rewrite.
There are facts it can infer carefully.
And there are facts it should never create.
That distinction became one of the most important parts of the system.
Problem #3: Good-looking HTML can still be broken
This one surprised me.
A generated page could look great at 1440px.
Then I opened it on mobile.
Chaos.
Headings wrapping into five lines.
Buttons leaving their containers.
Images becoming enormous.
Two-column layouts refusing to become one column.
Text becoming unreadable over backgrounds.
The AI had created something that was technically valid and visually broken.

This is where I realized something important:
Generating the site and verifying the site are two completely different problems.
So I added a separate visual QA step.
Instead of trusting the generated result, the system has to inspect what actually rendered.
Things like:
Does content overflow?
Are sections missing?
Is text readable?
Does the navigation work?
Are elements overlapping?
Does the page still make sense on mobile?

The AI can say the website is correct.
The browser is the final judge.
Problem #4: “Regenerate” is not a solution
A lot of AI products solve bad output with one button:
Generate again.
That works surprisingly well in demos.
It is also expensive.
If generation fails 10% of the time, simply running the whole thing again means:

more model calls
more latency
more compute
more money
another chance for something else to break So instead of regenerating everything, I started trying to identify the exact thing that failed. Bad section? Fix the section. Broken page? Rebuild the page. Bad content? Regenerate the content. The goal became: detect -> isolate -> repair

instead of:
fail -> regenerate everything -> hope

That one change made the system feel much less like a slot machine.
Problem #5: The AI kept being creative when I needed it to be boring
This was probably the funniest problem.
Creativity sounds great when building with AI.
Until you are generating production UI.
Sometimes you do not want creativity.
You want:
Header
Hero
Services
About
CTA
Footer

That is it.
No floating glassmorphism card.
No randomly rotated image.
No giant quote taking up the whole viewport.
No mysterious “Our Philosophy” section for a plumbing company.
The model kept trying to impress me.
I kept trying to make it behave.
Eventually I realized the system needs both freedom and constraints.
Too many constraints and every site looks identical.
Too much freedom and every generation becomes unpredictable.
Finding that middle ground was much harder than writing the prompt.
The architecture slowly changed
The original idea was basically:

Business description
↓
AI
↓
Website

The real system started looking more like:

Business description
↓
Business understanding
↓
Website structure
↓
Page planning
↓
Content generation
↓
Design generation
↓
Rendering
↓
Visual validation
↓
Repair
↓
Final website

The interesting part is that AI is only one piece of that pipeline.
Most of the work is actually about controlling it.
The biggest lesson
Before building this, I thought the main challenge would be:
“Can AI generate a good website?”

It can.
That is not the interesting question anymore.
The real question is:
Can AI generate a good website repeatedly, predictably, and without a human fixing it afterward?

That is a completely different engineering problem.
The first impressive result took very little time.
The reliable system took much longer.
And I suspect this is true for a lot of AI products right now.
The demo is easy.
The last 20% is the product.
I’m still working on this problem while building Instantsite, where the goal is to turn a short business description into a complete editable website.
But the thing I find most interesting is not the website generation itself.
It is everything required to make unpredictable AI output behave like predictable software.
That part is much harder than the demo makes it look.
One question
If you’re building with generative AI, what was the first thing that worked perfectly in the demo and completely fell apart in production?