Yang's Kitchen
Custom ordering layer on top of Squarespace for a Los Angeles restaurant. Hand-written CSS and JS to bend the platform into a real menu and pickup flow.
About the project.
Yang's Kitchen is a Los Angeles restaurant whose owners had committed to Squarespace before realising it could not handle the menu and pickup flow they actually needed. Rather than migrate, I wrote a custom CSS and JavaScript layer on top that bent the platform into a real ordering experience. It was an early lesson in working with the constraints a client has chosen, not against them.
What we walked into.
A Los Angeles restaurant had committed to Squarespace before realising the platform could not handle the menu + pickup ordering flow they needed. Migration was off the table; the platform constraint was fixed.
What we did.
Custom CSS + JavaScript layer on top of Squarespace that bent the platform into a real ordering experience without abandoning the stack.
What it became.
Functional ordering flow on Squarespace, brand-consistent menu layout, no third-party plugin sprawl.
My role on this project.
Solo · 100% custom CSS + JavaScript layer on top of Squarespace. Client owned the platform decision and the content; I owned every line of custom code that made the chosen platform actually work for their use case.
Front-end developer
Custom CSS injected via Squarespace code blocks. Custom JavaScript for the menu + pickup-flow widgets.
UX problem-solver
Worked around Squarespace constraints (limited form fields, no native ordering, no payment hooks) by layering on top.
Analytics integrator
GA tracking on the custom ordering flow so the restaurant could see actual conversion data.
The numbers that matter.
- WorkedWithin platform constraintNo migration; client kept their existing CMS investment.
- Mobile-firstDesign targetDiners hit the site from phones the moment they decide where to eat.
- GA-trackedOrdering flowEvery step measurable; restaurant could see real conversion data.
What was actually broken.
The client had already paid for and learned Squarespace. Telling them to migrate was the easy technical answer and the wrong business answer — it would have meant abandoning their content, retraining their staff, and rebuilding the visual identity that was already shipped. The brief: make the platform do what it cannot natively do, by carefully extending it.
The hard surface area.
- 01Squarespace exposes limited customisation hooks — every workaround had to use documented injection points only.
- 02Custom ordering flow that integrates with their existing payment processor without violating Squarespace ToS.
- 03Mobile-first menu layout within Squarespace block constraints.
Engineering wins worth naming.
Working within platform limits
No backend code access; all logic lives in CSS + injected JS. State held in localStorage; cart submission routes to a Squarespace Form Block under the hood.
Brand-consistent menu without Squarespace blocks
Squarespace menu blocks are limited. Built a custom JSON-driven menu rendered by injected JS that respects brand spacing + typography.
How the system is wired.
Squarespace hosted
Custom CSS + JS layer (this is the work)
The decisions behind each choice.
Work with Squarespace, not against it
- Client investment in the platform was non-trivial. Migration cost would have exceeded the value of the new flow.
- Squarespace ToS allows custom CSS + JS via documented injection points — the bridge stays inside the rules.
Vanilla JS over framework
- Injected scripts compete with Squarespace's own framework. A second framework would double load weight.
- Vanilla code is auditable in a single file — easy for the next maintainer (likely Squarespace itself).
What the build taught us.
- The right technical answer is sometimes "respect the platform the client chose, and make it work" — not "rewrite on the stack you prefer."
- Early-career lesson in scoping engineering decisions to the actual business constraints, not to engineer preferences.