The Original Friction
The HTML canvas could already generate forms, landing pages, and lightweight microsites. But there was one obvious problem:
the forms looked alive, yet for many users they were operationally dead.
If someone wanted submissions to land in Google Sheets, the old flow required them to deploy a Google Apps Script manually and then paste the URL back into the product. Technical users could survive that. Everyone else hit a wall.
The Actual Product Goal
We were not trying to build a generic website builder. We were trying to help a non-technical user go from:
"I have an idea for a small lead form or widget"
to:
"It is live, it collects responses, and I can see them in my sheet"
That means setup friction matters more than feature count.
The Architecture Choice
We chose a Google OAuth flow with server-stored tokens and a server-side submission proxy.
That gave us a cleaner user path:
- click Connect Google Sheet
- complete OAuth
- store the sheet connection on the canvas
- append submissions server-side through an edge function
We explicitly did not choose:
- manual Apps Script as the primary path
- client-side access tokens inside the rendered widget
- an n8n-style webhook dependency
Those options either added too much friction or created a worse security model.
What Changed in the Product
The canvas stopped being just a place to render HTML. It became a lightweight widget system.
Key shifts:
- mobile-first generated widgets
- Google Sheets connection stored as canvas metadata
- endpoint injection at render time so the model never needs the real backend URL
- template support so useful widgets can become community starting points
- backward compatibility for the older Apps Script path
That last point matters. Migration work is smoother when the new path is better without making the old path suddenly invalid.
Why the Submission Proxy Matters
The safest version of this product is the one where the browser never receives long-lived Google credentials.
So submissions go through a server-side edge function that:
- validates the canvas
- looks up the stored token
- refreshes it if needed
- appends the row to Google Sheets
This keeps the widget simple while keeping the sensitive token path off the public page.
What Would Have Made This a Bad Investment
The bad version would have optimized for demo polish instead of durable usability:
- flashy generated widgets with no real backend path
- tokens exposed in the browser
- no rate limiting
- no clear migration path for existing users
That would look exciting briefly and then create support pain immediately.
The Real Outcome
The canvas builder became more than a design toy. It became a way to publish small working tools:
- lead capture forms
- simple landing pages
- booking or campaign widgets
- reusable community templates
That is the pattern we care about at 6DuckLearn. Not AI for decoration. AI that shortens the distance between an idea and a working workflow.
Proof Level and Limitations
- Proof level: Product workflow case study.
- What this demonstrates: A generated HTML canvas can become more useful when it has Google Sheets connection metadata and a server-side submission path.
- What this does not claim: It does not replace a full form builder, CRM, or enterprise workflow automation platform.
- Source anchors: HTML Canvas, Google OAuth connection flow, server-side submission proxy, reusable templates, and backward-compatible Apps Script support.