2026-07-25·Day 18 · building git-to-market in public

Landing page now shows CMS content with a graceful fallback

This week we shipped one focused improvement: the main public landing page now prefers content you write in the CMS and gracefully falls back to the autogenerated content we create from your commits. It’s a small change in code but a big change for how projects look and feel to visitors. You get the polish of hand-written messaging where it matters and the convenience of automatic updates everywhere else.

What shipped

We changed how the landing page decides what text and media to show. Before, the page used a single source of content that was either fully autogenerated or required full CMS coverage to look intentional. Now there are two prioritized sources.

–Primary: any editorial content you add in the admin CMS (headline, subhead, feature blurbs, CTA text, and optionally images).
–Secondary: the autogenerated content our system already builds from your recent commits and changelog entries.

We built a simple rule: prefer CMS content when present, otherwise use the generated content. If neither source has content for a specific section, the section is omitted so the page stays clean.

This covers all the key visible pieces on the landing page. The headline and subhead follow the CMS-first rule. Feature bullets and short descriptions also prefer CMS entries but will show generated copy measured from recent commit activity when absent. The featured image or hero graphic will display the CMS image if you upload one; otherwise it pulls the best available image from generated assets or hides the visual element if none exist.

We also ensured the CTA area respects the same precedence. If you want to direct visitors to a demo, a waitlist, or a purchase link, put the target URL and button text in the CMS. If you don’t, the button still appears with a sensible default—like joining the waitlist—based on your project’s status.

Finally, the page now omits empty sections rather than rendering placeholders. That keeps the layout tight and avoids the cognitive jolt of seeing half-populated content.

Why it matters to you

If you build in public, you’re juggling two objectives: ship code frequently and present a coherent story about what you’re building. Both matter. Frequent shipping creates the cadence that attracts attention. Clear, intentional messaging converts that attention into interest and action.

Before this change, many creators faced a hard trade-off. Keep the landing page fully autogenerated and you’d always have something live but sometimes awkward phrasing or mixed signals. Or keep a CMS-cooked page and maintain it actively. Both options cost time or created friction with the spontaneity of working in public.

This change removes that trade-off at the most visible spot—the landing page. You can focus your writing energy on the one or two lines that most influence conversions: the headline and the call to action. The rest of the page continues to update automatically from your commits, which keeps the page fresh and truthful to your recent work.

For early-stage makers and indie founders, this lowers the cost of keeping a decent public presence. You no longer need to contrive a full marketing update when you just shipped a small but meaningful change. For teams and developers balancing feature work and community, it reduces the risk of a landing page that looks abandoned or inconsistent with the activity in your repo.

Concretely, this means more discoverable, better-converting pages with less manual effort. When someone arrives from X, LinkedIn, or search results, they see a page that looks written on purpose and reflects your momentum.

How it works from your point of view

The experience is intentionally simple. You don’t need to understand how the precedence works; you just use the system the way you’d expect.

1. Keep pushing commits as usual. Each day the automation reads your recent commit messages, builds short posts for social, and synthesizes a summary that can serve as landing page content.

2. If you want to control a particular line on the landing page, open the small CMS in the admin panel and edit the field you care about. Typical high-impact edits are the headline, the one-sentence subhead, and the CTA text or link.

3. Save the CMS changes. The public page updates and starts showing your edited text in place of the autogenerated copy. Everything else on the page remains driven by the commit-derived content, so the page still reflects your day-to-day work.

4. If you remove CMS content later, the system automatically falls back to the most recent generated content. You never see blank fields. If both CMS and generated text are missing for a section, that section disappears from the landing page layout.

You can think of it as a lightweight override system. The CMS is not a full-blown website builder. It’s a few targeted fields for the lines that matter most. That makes edits quick and low-friction. You can update a headline from the admin in under 30 seconds and ship that change to your landing page immediately.

We also added simple guardrails to prevent awkward combinations. For example, if you add a very long headline in the CMS and the autogenerated subhead is extremely short or unrelated, the page still renders but we surface a suggestion in the admin: either write a CMS subhead or accept a suggested generated subhead that we synthesize from your recent commits to make the pair more cohesive.

On the visual side, images behave the same way. Upload a hero image to the CMS and it shows up front. If you don’t, we pick a generated image based on your repo assets or hide the hero area to keep the layout clean. That keeps the brand consistent without forcing you to design anything.

What we learned building this

We took a measured approach to this feature because the landing page is where impressions form fast. The first lesson was to keep the CMS minimal. Users don’t want a big content menu or lots of fields to manage. In testing, the edits people made repeatedly were the headline, the one-line description, and the CTA link. Everything else could safely be auto-filled.

The second lesson was to make absence look intentional. We experimented with showing default placeholder phrases like "Coming soon" or "Auto-generated" and found they reduced trust. A cleaner layout that simply omitted empty sections tested better in early user studies. It felt more deliberate and less like a half-finished site.

The third learning was about the handoff between human and machine writing. Generated copy can be blunt and literal, often pulling commit messages or issue titles that are terse. If that text sat next to a polished CMS headline, the mismatch could feel jarring. We addressed that by generating short, more readable summaries for use as fallbacks and by surfacing simple suggestions in the admin so you can write a one-line subhead when it matters.

We also learned that creators often prefer to edit one line frequently rather than edit many lines rarely. That shaped the interface: big, prominent fields for the headline and CTA, less prominent fields for optional extras. The aim was to encourage small, high-impact edits.

Finally, this work surfaced adjacent opportunities. For example, we noticed people wanted to pin a specific changelog entry or featured post to the top of the landing page. That’s a small extension of the same precedence concept: a CMS selection that overrides what’s shown in the feature area.

What this unlocks next

The precedence pattern we implemented here is useful beyond the landing page. We’re planning to roll the same approach into other customer-facing surfaces:

–Waitlist and onboarding messaging: let you hand-edit the short messages people see when they sign up or receive an urgent link, while still using autogenerated content for the rest.
–Pinned changelog entries: allow a single hand-picked update to sit above the autogenerated feed so you can highlight the release you want everyone to see.
–Pinned social posts and featured blog items: give you the ability to override the daily autopost for one high-priority update.

These are small, focused extensions that reuse the same CMS-first, generated-fallback model. Each one reduces the maintenance burden while letting you target the small edits that most influence signups and conversions.

We’re also exploring lightweight copy suggestions. Because we already synthesize summaries from commit history, we can surface a suggested headline and subhead in the admin that you can accept with one click. Our goal is a workflow where you can land on the admin page, accept a suggested headline and CTA, and have a polished landing page in under a minute.

Longer term, the pattern supports simple A/B testing between CMS content and generated content, which would let you learn which style of messaging performs better for your audience without much setup.

What we plan to monitor and tweak

After shipping, we’re focusing on a few concrete metrics and qualitative signals. First, we’ll monitor how often people edit the CMS and which fields they touch. That tells us whether the fields we made prominent are the right ones, and whether we should expose or hide additional fields.

Second, we’ll track conversion behavior for pages showing CMS content versus those using generated copy. If CMS-edited pages perform notably better, we’ll add subtle nudges encouraging a one-line edit to the headline or CTA. If there’s no measurable difference, we’ll avoid over-promoting manual edits.

Third, we’ll scan for awkward copy pairings where a polished CMS headline sits with a blunt generated subhead. If that happens often, we’ll expand our suggestion engine to propose better-fitted subheads or block certain combinations until you reconcile them.

We’ll also watch for edge cases around images. The current fallback picks the best available asset, but some projects use abstract visuals in the repo that don’t translate well as hero images. If we see frequent image mismatches, we’ll add a simple image-quality check and suggest alternatives.

Finally, we’ll keep an eye on how this affects search and social link previews. A clearer headline and consistent hero image can improve click-through rates from social platforms and search results. If we detect measurable gains there, we’ll prioritize surfacing the few edits that produce the biggest lift.

What's next

Next up is applying the same CMS-plus-fallback approach to the waitlist admin and the urgent link-sent state so you can control onboarding text without losing automation. We’ll also prototype single-click headline suggestions based on recent commits to make those small edits even faster. If you’re using git-to-market, try editing one headline this week and watch how it changes your public page.