Docalive: turn Google Docs into live websites
Turn Google Docs into live websites, where the familiar tool people already write in becomes a publishing engine, and the design challenge is staying invisible.
People already write. They just can't publish.
Every website builder asks the same thing: leave the tool you think in, learn ours, and rebuild your content inside it. For someone who writes in Google Docs every day, that is not a feature. It is a tax.
The people who need websites most, freelancers, small-business owners, writers building a presence, are not short of content. They have Google Docs full of it. What they lack is a way to make that content public without learning HTML, choosing a hosting provider, or wrestling a page builder into shape.
WordPress is powerful and overwhelming. Notion-to-site tools are opinionated about structure. Squarespace looks good but demands you author inside it. None of them start from the premise that the writing is already done and the writer should never have to move it.
Google Docs is the CMS. Docalive is the publisher.
The first instinct was to import content from Google Docs and let users edit it inside the app. That would have made Docalive another editor. The decision that shaped the product was to never store content at all, only render it.
Google Docs stays the single source of truth. Users never re-author. They never copy-paste. They never wonder which version is current. The doc is the page and the folder is the site. Every piece of complexity Docalive introduces has to justify itself against that simplicity.
A folder is a site, a doc is a page
The information architecture maps directly to something the user already understands: their Drive folder structure.
The ordering exception matters. Drive sorts alphabetically; websites do not. Page order is the one place where Docalive owns state that Drive does not. This is deliberate: sorting is a publishing decision, not a writing one, and it belongs in the publishing tool.
Content comes from Docs. Everything else comes from Docalive.
If Google Docs is the CMS for words, Docalive is the CMS for everything around the words: brand, navigation, domain, and access control.
Page content and formatting. Page titles. Embedded images and tables. Real-time edits and collaboration. The user's territory. Docalive reads, never writes.
Logo, favicon, Open Graph image. Navigation style and page order. Custom domain and subdomain. Password protection. SEO metadata per page. Theme and footer configuration. Publishing decisions. These have no place in a doc.
The split keeps both tools honest. A Google Doc never needs to know it is a web page. A Docalive dashboard never tries to be a text editor. When a user asks "where do I change this?", the answer is always obvious from the type of thing they are changing.
Four layouts, one page tree
A documentation site needs a sidebar. A portfolio needs a topbar. A landing page needs neither. The navigation system had to support all three without asking the user to restructure their content.
The page tree is the single data structure. Navigation type, sidebar, topbar, mega-menu, or mobile-only, is a rendering choice applied on top of it. Switching navigation style never moves, hides, or reorders a page.
Pages can be hidden from navigation without being unpublished. This handles the "thank you" page, the legal disclaimer, and the landing-page variant that should be reachable by URL but not visible in the menu.
Search is built into every layout. A generated JSON index makes every page searchable from the navigation bar. For documentation sites this is expected; for portfolios it is a surprise that earns trust.
A subdomain for free, your domain when you are ready
Custom domains are the clearest upgrade trigger in the product. The design challenge was making DNS verification feel simple to someone who has never touched a DNS record.
Every site gets a name.docalive.com subdomain immediately. It works, it is shareable, and it costs nothing. The free tier proves the product before anyone pays.
Custom domains use Cloudflare for DNS verification and SSL. The user adds one CNAME record; Docalive handles certificate provisioning and hostname validation behind the scenes. Status is tracked visibly so the user is never guessing.
Domains are a plan feature, not a per-site upsell. Lite and Premium unlock custom domains for all your sites. This avoids the nickel-and-dime feeling of charging per domain and makes the upgrade feel like a capability unlock, not a toll.
A password, not an auth system
Some sites need to be private: an internal knowledge base, a client deliverable, a draft for review. The question was how much access-control machinery to build.
The answer was: a single site-level password. Not per-page permissions, not user accounts, not invite links. One password, one hint, session-based access. The owner shares the password however they already share things, Slack, email, a text message.
The constraint is the feature. Per-page access control would have demanded a user management system, a login flow, and a permissions model. A site-level password delivers 90% of the value at 5% of the complexity. The people who need granular access control are not the people Docalive is for.
Constraints that make sense
A freemium product lives or dies by what the free tier can do and what the paid tier unlocks. The gates had to feel natural, not punitive.
Pages are never gated. A free user gets unlimited pages on their one site. This matters because the moment someone builds a ten-page site on the free tier, they have invested enough to care about a custom domain. The gate is on breadth (more sites), not depth (more pages). That aligns incentives: the more someone uses Docalive, the more likely they are to pay, but they are never punished for using it heavily.
The hardest feature is the one nobody sees
Sync has to be invisible. If a user edits a Google Doc and the website does not update, trust is broken. If it updates but breaks formatting, trust is broken worse.
Docalive uses the Google Drive API to detect changes and the Google Docs API to fetch content. Token refresh is handled silently. When a sync fails, expired permissions, API rate limits, network errors, it retries with backoff and logs the attempt so support can diagnose it.
Sync logs are visible to the user. Not because most users check them, but because the ones who do are the ones whose trust matters most. A visible sync history turns "is my site up to date?" from a worry into a glance.
Formatting fidelity is the product. Google Docs supports headings, bold, italic, links, images, tables, and lists. Each has to render correctly on the published site, in every navigation layout, on every screen size. This is not a feature. It is the contract.
Directions I killed
What I'd carry forward
The best CMS is the one people already use. Google Docs is not a CMS. But 1.8 billion people already know how to use it, and that adoption advantage outweighs every feature a purpose-built editor could offer. Meeting users where they are is not a compromise. It is the product.
Gates should align with ambition, not usage. Gating on website count means the free tier serves a single-project user indefinitely, and the paid tier unlocks a second project when they are ready. Nobody hits a wall mid-build. The paywall appears at the moment of expansion, which is also the moment of highest willingness to pay.
Invisible sync is harder than any visible feature. Token refresh, API rate limits, permission revocation, formatting edge cases, image hosting: none of these are features a user sees. All of them are reasons a user leaves. The engineering cost of reliability is the real cost of the product.
What's unfinished. Analytics on the published site. Collaborative publishing settings for teams. A faster CDN layer for high-traffic sites. Template starting points that create pre-structured Google Docs folders. Each of these is a real gap; none justifies adding complexity before the core loop is airtight.
Docalive · Google Docs to website publishing platform · docalive.com. Built with Laravel, Vite, Tailwind CSS, Google Drive API, Stripe, and Cloudflare.