Forem: zhenqiang

Agent Skills

zhenqiang — Tue, 24 Feb 2026 04:58:05 +0000

From Folder to Public URL with One Command

zhenqiang ・ Feb 13

#cli #productivity #tooling #webdev

From Folder to Public URL with One Command

zhenqiang — Fri, 13 Feb 2026 03:20:22 +0000

This is the final post in a short series about shipping small, fast-moving web projects.

So far we covered:

Why speed matters in small demo scenarios
Why not every project needs a full pipeline

Now here’s the workflow.

The Goal

For small, static projects, publishing should:

Require no configuration
Produce a public HTTPS URL
Take less time than a context switch

From inside the project folder.

The Command

From the project root:

/myvibe-publish

What You Get

The command runs locally, packages your static output, uploads it to MyVibe, and returns a public URL.

Example:

🚀 Published successfully!
🌍 https://www.myvibe.so/zhenqiang-zhang/devlog-ai

(Actual time varies with project size and network conditions.)

The point isn’t magic — it’s removing ceremony for static projects.

When This Makes Sense

Best fit:

Hackathon submission pages
Temporary demo links
Landing pages
Static docs
Frontend-only experiments

Assumptions:

Static output
No server runtime
No complex environment requirements

What It’s Not

Not a replacement for CI/CD.

Long-lived systems still deserve full pipelines.

This is for the category where the “deliverable” is simply: a link.

Series: Shipping Small Projects

Not Every Project Needs a Deployment Pipeline

zhenqiang — Fri, 13 Feb 2026 02:56:15 +0000

This is the second post in a short series about shipping small, fast-moving web projects.

In the previous post, we used a hackathon-style scenario: a static submission page needed a public link under time pressure.

The point wasn’t a specific number of seconds.

It was context.

The Default Is “Treat Everything Like Production”

Modern development culture has normalized a default workflow:

Git repository
CI configuration
Automated deployment
Hosting + environment decisions

Even when the “project” is:

A temporary landing page
A frontend-only demo
A hackathon submission
A two-day experiment

That default isn’t wrong.

It’s just often unexamined.

A Simple Lens: Lifespan × Risk

Before reaching for a pipeline, it helps to ask two questions:

1) How long will this live?

2) How costly is failure?

The goal is proportionality: the smaller the project, the smaller the ceremony.

Three Categories of Projects

1) Long-Lived Systems (High Risk, High ROI)

Production SaaS. Team-owned services. Revenue paths.

You want CI/CD here because you need:

Repeatable builds
Rollbacks
Monitoring + alerts
Change control

This is the world pipelines were built for.

2) Medium-Term Projects (Moderate Risk)

Portfolios, docs sites, internal tools.

Automation helps — but the “pipeline” should stay proportional:

Minimal steps
Few moving parts
Low maintenance overhead

3) Short-Lived, Fast-Moving Static Projects (Low Risk)

Hackathon demos. Temporary pages. Frontend-only prototypes.

These projects often:

Live for days or weeks
Don’t have a backend
Don’t need environment variables
Mostly need one thing: a public URL

Example output page:

https://www.myvibe.so/zhenqiang-zhang/devlog-ai

This is what a published static demo page looks like on MyVibe.

And yet we often deploy them like production systems.

The Hidden Cost: Attention

For small projects, the cost of over-engineering isn’t money.

It’s attention.

It’s switching from:

Improve the demo

to:

Configure the pipeline

That context switch introduces friction.

And friction slows iteration.

Quick Rule of Thumb

If the project has users who depend on it, needs rollbacks, or has secrets/configuration, use CI/CD.

If it’s a static demo page with no backend and no env vars, optimize for “publish a link” instead.

A Category Worth Optimizing

There’s a category of work where publishing should feel lightweight:

Static
Self-contained
Short-lived

In that context, the best workflow is often:

run one command → get a link

In the final post, I’ll walk through the workflow behind that one-command publish — and the constraints that make it possible.

Series: Shipping Small Projects

We Built for 36 Hours. Publishing Took One Command
Not Every Project Needs a Deployment Pipeline
From Folder to Public URL with One Command

We Built for 36 Hours. Publishing Took One Command.

zhenqiang — Thu, 12 Feb 2026 06:51:13 +0000

This is the first post in a short series about shipping small, fast-moving web projects.

Over the next two posts, I’ll explore:

Why not every project needs a full deployment pipeline
And what a lightweight publish workflow can look like in practice

Let’s start with a simple (hypothetical) scenario.

Imagine This

You’re at a hackathon.

You’ve spent 36 hours building something that works perfectly on your machine.

There are 15 minutes left before submission.

And you don’t have a public link.

The Project

In this scenario, the project was DevLog AI — a small frontend tool that turns messy Git commit history into clean release notes.

It was:

Static
Self-contained
A single index.html
No backend
No environment variables

Just a submission page and a demo.

The Friction

Even for something this small, the typical path to publishing often looks like:

Push to GitHub
Trigger a build
Wait
Verify
Fix
Re-deploy

Nothing dramatic.

Just overhead.

And in the final minutes of a hackathon, overhead matters.

What Happened Instead

Inside the project folder:

/myvibe-publish

No configuration.

No dashboard.

No pipeline setup.

Seconds Later

🚀 Published successfully!
🌍 https://www.myvibe.so/zhenqiang-zhang/devlog-ai

You can see the live demo page here: https://www.myvibe.so/zhenqiang-zhang/devlog-ai

(Actual time varies with project size and network conditions.)

The link was live.

Submission done.

Time saved for improving the demo — not debugging deployment.

Why This Is the Starting Point

The project took:

36 hours to build.

Publishing took:

one command.

Not because deployment is trivial.

But because the project was simple — and the workflow matched the context.

In the next post, we’ll zoom out and ask:

Does every project really need a deployment pipeline?

Series: Shipping Small Projects

We Built for 36 Hours. Publishing Took One Command
Not Every Project Needs a Deployment Pipeline
From Folder to Public URL with One Command