From Domain to Deployment: A JavaScript Productivity Story with AI
This blog post shares how I went from an empty domain to a live site using AI collaboration in Continue, and what I learned about building momentum when time is your scarcest resource.

It started like so many developer side projects: an impulsive domain purchase. I saw someone tweet on X about a GitHub organization name that was available that they snatched up, and then I (dangerously) started wondering about organization names that might be available. One thing led to another, and I had a new GitHub organization, a new domain (https://osscommunities.com/), and a co-maintainer.
In my mind, I had a general idea of what would go on the site. I had a couple of open source courses that needed a home, a ton of content that I had been meaning to repurpose, and an open source challenge idea that I needed a more permanent place to share. What I didn’t have was a design, a plan, and time. Then I did the thing you shouldn’t do if you don’t have those things: I told the world about it.
This blog post shares how I went from an empty domain to a live site using AI collaboration in Continue, and what I learned about building momentum when time is your scarcest resource.
I turned an impulsive domain purchase into a live site–osscommunities.com—with less than an hour a week to work on it.
Key wins
- 10-minute coming soon page built with Continue
- Mockup and design principles learned in the process
- Automated content collection
- Continue kept everything in my IDE and gave me a way to collaborate with AI without breaking flow.
Biggest insight:
Constraint drives clarity and AI amplifies it when used intentionally.
How to Build a Coming Soon Page in 10 Minutes with Astro (JavaScript + Continue.dev)
Without thinking about it, I shared the url to the new domain in a LinkedIn post about a month ago. Almost immediately, people were DMing me to let me know that all they were seeing when they clicked the link was a blank page.
Somehow, in my mind, it seemed easier to ship a coming soon page than to actually respond to the DMs, explain that I wasn’t ready to ship anything yet, and it was a mistake to link the url.
I needed the simplest possible coming soon page that:
- Looked professional (I’m not a designer)
- Deployed to Netlify
I had about ten minutes before my next appointment, so I decided to test how quickly I could get a page up and running. I had already decided with the other maintainer that we would use Astro, so I opened up Continue and started with my prompt:
I want a quick coming soon page for a new Astro (JavaScript/TypeScript) project. Help me create something simple. Step by step.
Nothing fancy. We just initialized an Astro project, removed some of the boilerplate content, and updated with Coming Soon! Continue’s autocomplete and chat features helped speed up my JavaScript productivity. In ten minutes, I was able to turn an idea into something real and build some momentum.
Can AI Help You Design an Accessible MVP with Tailwind in JavaScript?
A week later, I had a couple of hours to spare and access to my AI Coding Assistant. The coming soon page worked, but I wanted to make progress. The problem was that I’m not a designer. I needed to create a visually appealing and accessible design without spending hours on it. I started to leverage Continue as a collaborative design partner. Instead of asking for a full design upfront, I started by outlining what I wanted to see:
- Purpose & Content: Sections for open source tips, shoutouts, courses, and resources
- Tech Stack: Tailwind CSS for rapid styling
- Structure: Hardcoded data for the MVP
- Accessibility: Fonts and colors aligned with WCAG standards
- Design Goals: One-page layout, minimalist style with gradient accents and subtle motion for engagement
This level of context helped Continue chat provide relevant suggestions like navigation patterns, responsive component structures, and ways to keep visual hierarchy clear without overcomplicating the design.
Good design isn’t enough if it leaves users behind. When we caught text contrast issues in early iterations, Continue suggested alternative color combinations that both preserved the aesthetic and met WCAG guidelines:
<!-- Before: Low-contrast text -->
<h3 class="text-xl font-bold">Contributor Tip</h3>
<p class="text-gray-600 dark:text-gray-400 mb-4">{content}</p>
<!-- After: WCAG-compliant contrast -->
<h3 class="text-xl font-bold text-gray-900 dark:text-white">Contributor Tip</h3>
<p class="text-gray-800 dark:text-gray-200 mb-4">{content}</p>
I didn’t want to rely on chance to catch these issues later, so I added it as a rule for my Continue Assistant. Now, every suggestion checks against this constraint when I’m using my Continue Assistant.
Why This Matters Beyond Color Contrast
This isn’t just about making text readable. As Josh Collinsworth explains in his post, LLM-powered code assistants can unintentionally promote inaccessible patterns like replacing semantic HTML with JavaScript hacks or adding interactivity to non-interactive elements. These shortcuts can actively exclude users and introduce legal and ethical risks.
As Ty Dunn outlines in our post on improving AI code suggestions, Continue's configurability is important for preventing patterns that harm users. I’m looking forward to exploring more ways to ensure my site accessibility by adding more detailed rules. (Let me know if you have a good set of rules!)
Altogether, I was able to use Continue to put together a mockup of an MVP in a couple of hours. It decreased the challenges faced when trying to come up with a design, helped me make the site more accessible, and provided clearer ways to create a good user experience.
Automating Blog Post Collection with JavaScript
Last year, I was hosting an X space with John Papa, and he said something that stuck with me: you should exhaust every piece of content before moving onto the next one. In this case, I thought back to all the blog posts that I wrote last year on open source, and I wanted to repurpose those learnings as part of this project. The challenge wasn’t migrating the posts—I still want them in the Sanity CMS—but I needed an easy way to get all my past blog posts into one place for planning and repurposing. Manually copying 30+ articles wasn’t an option.
I used Continue to help me write a quick Node.js script that pulled all my posts from the Sanity API and converted them into Markdown files. This gave me a clean starting point for creating new resources without wasting hours manually copying and pasting each post, title, and metadescription.
Here’s what it looks like in practice:
import { createClient } from '@sanity/client'
import { writeFile, mkdir } from 'fs/promises'
import { join } from 'path'
// Initialize Sanity client
const client = createClient({
projectId: 'yourProjectId', // Replace with your Sanity project ID
dataset: 'yourDataset', // Replace with your dataset
useCdn: true,
apiVersion: '2023-01-01',
})
// GROQ query to get posts
const query = `*[_type == "blog" && author->name == "Your Name"] | order(published_date desc) {
_id, title, slug, published_date, summary, blogContent, author->{name}
}`
What’s Happening Here (and Why It Matters)
- Sanity Client Setup: The createClient function connects to your Sanity project. No tokens here because I only needed public data.
- GROQ Query: GROQ is Sanity’s query language. Here, I’m pulling the essentials:
- title for the blog post title
- slug for file naming and URLs
- published_date so I could prefix files with dates for static site generators
- summary and blogContent for metadata and actual content
- File Writing: For each post, the script generates a Markdown file with frontmatter (title, date, meta description) plus the content. This made the posts ready to drop into an Astro or Jekyll site instantly.
Why This Was a Productivity Win
This took minutes instead of hours. Instead of manually copying, formatting, and organizing 30 posts, I automated the entire process. Following a similar approach, Brian wrote about his Docusaurus → Mintlify docs migration, emphasizing planning, modular scripts, and automation.
Lessons Learned About AI Collaboration Under Constraint
- Small wins compound: The 10-minute coming soon page transformed the project from "someday" to "happening now." AI collaboration shines when you need to get something working quickly rather than perfectly.
- Use AI for understanding, not just output: The design conversation taught me principles I could apply beyond this project. The architecture discussions we had helped me think about user experience.
- Constraints force clarity: When you only have an hour, you have to be specific: "I need a coming soon page that uses astro and tailwind and can be deployed in 10 minutes." Constraints make your AI conversations more productive.
- Think programmatically: If manually is going to take hours, think about how you can do it programmatically in a fraction of the time and increase your productivity.
Could I have done this all without Continue? Sure. But using an AI Coding Assistant increased my productivity with this JavaScript project. Continue made my limited time count, kept everything in my IDE, let me share context easily, and helped me think through decisions rather than just generate code.
What Would You Build If You Had 10 Minutes?
A lot of developers I know have domains sitting unused, ideas never worked on, or public commitments creating gentle pressure. The tools for rapid development have never been better, and learning to work within your actual constraints, instead of waiting for ideal conditions, can be a game-changer.
What project is on your "someday" list? What would you build if you knew you could make real progress in 10-minute increments?
The next time you find yourself waiting for a prescription, sitting in a parking lot, or with a few minutes between meetings, think about opening up a conversation about that project you keep meaning to start. You might be surprised at what you can accomplish when constraint becomes your competitive advantage.