The Credostar marketing site is twenty-something static pages plus a couple of form endpoints. That description sounds straightforward. The stack we picked has consequences that are not obvious until you have lived with the alternatives.

Here is what we picked and why.

The constraints

Before any tech choice, the constraints that shaped the decision:

Content-heavy, JavaScript-light. Most pages are prose. The home page has interactive bits (forms, pricing toggle, FAQ accordion) but no SPA-style state management. Shipping React for everything is wasteful.
Authoring needs to be markdown-friendly. The Learn articles, the blog, the changelog all live as Markdown/MDX so they can be edited without touching a CMS.
Form submissions need a backend, but only barely. Newsletter signup, design partner application, contact form. Three endpoints. None require persistent state beyond pushing to Zoho.
Build and deploy needs to be fast. Every commit should ship to production within a couple of minutes. No long CI.
The site needs to be cheap. This is a marketing site. Infrastructure should not cost meaningful money at the traffic levels a pre-launch site sees.

Astro 5

Astro is a static site framework that renders to HTML by default. React components run on the server unless explicitly marked as client islands. That is the right primitive for content sites that need bits of interactivity.

The specific things Astro 5 did for us:

Content collections. Three collections (learn, changelog, blog) with Zod schemas validated at build time. Authors write MDX. The build fails if frontmatter is wrong.
Island architecture. A page like /about ships zero JavaScript except the Header (mobile menu toggle) and the Footer (newsletter form). Most of the page is HTML.
View Transitions. Cross-page navigation feels SPA-fast without paying the SPA tax.
Image service abstraction. We use a no-op image service since we are not transforming images at build time. This avoids pulling in sharp and keeps builds fast. When we add image optimization later, switching the service is a one-line change.

Things that almost made us pick something else:

Astro 5 vs Astro 6. Astro 6 dropped in 2026 with some Tailwind v4 alignment work, but the @astrojs/tailwind integration pins Astro 5 for Tailwind v3 compatibility. We are on v3 because the design system was already built against it.
Vs Next.js. Next is great for apps. Marketing sites do not need React Server Components. Astro’s lower mental overhead won out.

React 18 islands

Where we need interactivity, we use React. The hydration directives let us control exactly when each island wakes up:

client:load for the header (mobile menu must work immediately).
client:visible for the form components in the footer (newsletter signup hydrates only when the user scrolls to it).
No directive at all for pure-render components like the FAQ accordion (we wrote ours without JS).

The result: the home page ships about 50KB gzipped of JavaScript total, most of which is React itself and the Header chunk. Adding more static content does not bloat the JS bundle.

Tailwind 3

Tailwind is the right design-system primitive for a site with a coherent visual vocabulary. We have custom design tokens for typography (Space Grotesk, Inter, IBM Plex Mono), colors (electric blue accent on a near-white background), and spacing. Tailwind compiles only the classes we actually use, so the final CSS is small.

One gotcha worth flagging: Astro projects need .astro in the Tailwind content paths or arbitrary classes in .astro files do not get generated. We discovered this when a grid-cols-[auto_1fr] layout silently fell back to stacked block flow. Fix is one line in tailwind.config.js.

Cloudflare Pages

For static hosting, Cloudflare Pages has the right trade-offs:

Edge-deployed globally. Static HTML served from the nearest POP, free.
Auto-deploy from GitHub. Push to main, build runs in CF’s infrastructure, deploys in 60-90 seconds.
Pages Functions for the backend. Same project, same deploy. The form endpoints live next to the static files.
Free SSL with custom domain. Setup is a single dashboard action.

The alternative for static hosting (Vercel, Netlify, S3+CloudFront) all work fine. Cloudflare Pages won because we already use Cloudflare for DNS and Turnstile.

Pages Functions for forms

This is the part most static-site stacks underestimate. You need a form backend somewhere. Most people end up with a separate service: a serverless function on a different platform, a hosted form tool, a microservice.

Pages Functions are Cloudflare Workers wired to your Pages project. Drop a .js file in functions/api/ and it becomes an endpoint. Same deploy. Same env vars. Same logs.

Our three endpoints (newsletter, request-access, contact) live in functions/api/. They share helpers from functions/api/_lib/ (Zoho OAuth, Turnstile verification, JSON response builder). Each endpoint is about 80 lines of code. There is no separate hosting bill.

We wrote a longer piece on this pattern: Cloudflare Pages Functions for static-site form backends.

What we did not pick, and why

A few choices we considered and rejected:

No CMS. Authoring in MDX through git commits is faster than any web-based CMS for a team of three. Editors who do not want to use git are not on this project yet.
No headless e-commerce. We do not sell from the marketing site. The credential issuance product runs on a different stack (FastAPI + Postgres + React SPA) and lives at app.credostar.com when we launch.
No analytics platform. Cloudflare’s built-in analytics covers our needs at this stage. We will add product analytics inside the application when it has users; we do not need marketing-site analytics that ship a 50KB JavaScript file to every visitor.
No A/B testing framework. We do not have enough traffic to test anything statistically. We will add this when we have a reason.

What we would change

If we were starting today, the only thing we might do differently is going straight to Astro 6. The Tailwind v4 migration would be more work than the v3 lock-in justifies, but the v4 Vite plugin is meaningfully faster than the PostCSS-based v3 pipeline. We will probably do this migration in Q4 2026 once the design system is more stable.

Everything else has held up. The site builds in under three seconds. Pages serve under 100ms anywhere in the world. Form submissions land in Zoho within two seconds. Authoring is a git commit.

This is what a marketing-site stack should feel like in 2026.

Why we built Credostar's marketing site on Astro 5 and Cloudflare Pages