Kickstart Veda

Veda is the kickstart to look at when the smaller framework examples start feeling too minimal.

Where most kickstarts are designed to teach the narrow path from “framework app” to “Contentstack-connected page,” Veda goes a step further. It still keeps the integration understandable, but it does so inside a much more complete content template: multiple page types, a richer content model, product catalog browsing, reusable modular sections, metadata, filtering, and deployment-minded details that feel much closer to a real project.

That is what makes it special. Veda is not just a quick integration sample. It is a stronger reference implementation for teams who want to move beyond “hello world with Contentstack” and start from something that already feels site-shaped.

This page is a practical developer guide based on the repository itself, not a replacement for official docs. The goal is to explain why Veda is different, what architectural ideas it is teaching, and how you might use it as a serious starting point.

What kind of kickstart this is

The smaller kickstarts are great when you want to understand a framework integration in isolation. Veda is better thought of as a content template.

It still teaches the same fundamentals:

• Contentstack SDK setup
• content fetching
• Live Preview and Visual Builder support
• editable field bindings

But it teaches them inside a broader site model, which means you also get:

• multiple content types working together
• multiple route types
• reusable page-level and block-level rendering
• metadata generation
• product discovery and filtering
• deployment-minded optimizations

If the smaller kickstarts answer “how do I connect Contentstack to a frontend?”, Veda starts answering “what does a more complete Contentstack site structure look like?”

What Veda is, and what it is not

The repository positions Veda as a production-ready Next.js content template for a luxury jewelry brand called “The Revival Collection.” That framing matters, because the project is intentionally more real-world in shape than the simpler kickstarts.

At the same time, it is important to be clear about scope: Veda is not a full commerce engine.

It includes:

• product lines
• products
• categories
• rich landing pages
• navigation and merchandising patterns
• content-managed page composition

It does not include:

• shopping cart
• checkout
• payment flows
• customer accounts
• order management

That actually makes it more useful for many teams. It gives you the content and experience layer of a commerce-style site without pretending to solve the entire commerce stack.

Why it feels more production-ready

A lot of that feeling comes from breadth rather than raw complexity.

Veda is not “production-ready” because it is huge. It is “production-ready” because it has already started making the kinds of decisions a real project needs to make:

• how multiple content types relate to each other
• how the site should route and render different content models
• how metadata should be generated for dynamic pages
• how shared navigation and footer content should be fetched
• how modular content should be mapped into components
• how preview should work without turning the whole app into a special case
• how to think about caching and launch-time priming

That makes it a stronger starting point when you want to build a polished marketing or catalog site rather than just prove the integration works.

What you get out of the box

The current contentstack/kickstart-veda repository includes:

• Next.js App Router
• React 19
• Tailwind CSS 4
• a richer content model with pages, categories, products, product lines, and header content
• reusable modular blocks such as hero, list, media, two-column, and rich text
• a dynamic component renderer
• product listing and filtering
• dynamic metadata generation
• cached data-fetching helpers
• Live Preview and Visual Builder support
• a launch configuration generator for cache priming

This is a meaningful jump from the smaller kickstarts. You are not just getting one page and a query helper. You are getting a content architecture.

How this specific kickstart works

1. lib/contentstack.ts is the shared content layer

This file is the main Contentstack integration boundary.

It sets up the Delivery SDK, resolves the correct delivery and preview hosts for the configured region, initializes Live Preview, and exposes a family of focused fetchers:

• getPage
• getHeader
• getCategory
• getProduct
• getProductLine

That alone tells you something about the repo. Veda is already thinking in terms of site domains, not just “one page entry.”

Another detail worth noticing is that the page and catalog queries use include_all and deeper reference loading. That makes sense for a content template where entries are connected to other entries, media, and modular content in richer ways than a minimal starter.

2. lib/pageUtils.ts turns the fetchers into a real page system

This is one of the most useful files in the repo.

It wraps the content fetchers in React cache() calls, adds a shared buildPath() helper, centralizes metadata generation, and exposes typed wrappers like:

• fetchPageData
• fetchCategoryData
• fetchProductData
• fetchProductLineData

This is where Veda starts to feel less like a sample and more like an application skeleton.

Instead of every route inventing its own fetch logic, the app has a consistent way to:

• derive the path
• fetch the content
• fetch shared header data
• determine preview behavior
• generate metadata

That kind of normalization is one of the clearest signs that the project is trying to scale beyond a demo.

3. Routing is built around content types, not just pages

The route structure reflects the content model:

• app/[[...slug]]/page.tsx handles general pages
• product and product-line routes have their own route shapes
• /products has a dedicated catalog experience

That is an important shift from the smaller kickstarts. Veda is not teaching only one “page by URL” pattern. It is teaching how different content types can become different route behaviors while still sharing the same Contentstack foundation.

The catch-all route is especially useful as a pattern. It lets you support broad page composition without creating a file per page, while still keeping the rendering logic intentional.

4. components/ComponentsRenderer.tsx is the heart of the page builder model

This component takes modular block data from Contentstack and maps it into real React components.

Today that means blocks such as:

• hero
• list
• two column
• media
• rich text

This is one of the strongest parts of the repo, because it shows how to keep Contentstack’s modular flexibility without letting the frontend become messy.

Instead of scattering block-specific logic around the app, Veda keeps one clear renderer that:

• maps block names to React components
• preserves CSLP bindings in preview
• gracefully surfaces unknown block types
• keeps empty-state behavior preview-friendly

If you are trying to build a content-managed site with reusable page sections, this file is probably one of the first things you will want to borrow.

5. Preview is handled as a first-class editing mode

Even though Veda is broader than the other kickstarts, its preview story is still quite approachable.

components/Pages/Preview.tsx gives the app one dedicated client-side preview wrapper that:

• initializes Live Preview
• listens for onEntryChange(...)
• re-fetches the right content type based on the current page
• swaps in the correct page-level renderer

That is a smart design choice. Instead of making each page type solve preview independently, Veda centralizes the behavior while still respecting the differences between pages, products, categories, and product lines.

It also means the authoring experience stays smooth even though the application itself is broader.

6. The page-level components separate layout intent from content fetching

The components/Pages folder is another reason the repo feels mature.

You do not just get a single generic renderer. You get page-level renderers for the main content shapes:

• generic pages
• categories
• product lines
• products
• preview

That separation matters. It means Veda is not trying to force every content type through one abstraction. Generic pages still use modular composition, but product and category experiences can behave more like purpose-built destination pages.

That is often what a real project needs: a blend of flexible page-builder sections and stronger templates for important content types.

7. The catalog experience is treated like a real feature

The /products experience is not just a list of entries dumped onto the page.

The repo includes filter and search utilities in lib/filterSearch.ts, including:

• fetching product subsets
• count-aware filtering
• taxonomy-based filters
• derived facet calculations

That is a strong signal that Veda is aiming at actual user flows, not just content modeling. It is trying to help you build a browsable catalog experience, which is exactly the kind of thing many teams need when moving from a marketing site into product storytelling.

8. Deployment and caching have already been considered

One of the quieter but more valuable pieces of the repo is updateLaunchConfig.mjs.

Before each build, it generates a launch.json file by querying Contentstack for all relevant URLs and building a cache-priming list. That is a very practical, very production-minded optimization.

It shows that Veda is not just concerned with local development. It is already thinking about:

• how routes get discovered
• how deployments warm up
• how CDN and first-visit performance can improve

That is exactly the kind of polish that separates a solid template from a simple demo.

What you are really learning from this project

Veda is valuable because it teaches several layers at once.

At the Contentstack level, it shows:

• how to model multiple related content types
• how to use modular blocks for flexible page composition
• how to keep Visual Builder support intact across a bigger app

At the application level, it shows:

• how to organize a richer Next.js content site
• how to unify routing and metadata patterns
• how to separate page-level rendering from content fetching
• how to treat filtering and merchandising as product features, not afterthoughts

At the operational level, it shows:

• how to think about cacheable routes
• how to prime deployments
• how to build a template that already respects performance and maintainability

That is why Veda is worth more prose than the smaller kickstarts. It is teaching architecture, not just integration.

When to choose Veda

Choose Veda when:

• you want more than a single-page kickstart
• you need a content-rich product or catalog site starting point
• you want a stronger reference for structuring a larger Contentstack project
• you want modular pages and purpose-built product/category experiences in the same app
• you want a better bridge between “starter example” and “real implementation”

It is a particularly good fit for:

• product catalogs
• editorial commerce experiences
• brand sites with merch or product storytelling
• high-fidelity demos and prototypes
• teams learning how to organize a larger Contentstack frontend

When not to choose it

Veda is not the best starting point if your goal is only to learn the SDK basics.

In that case, one of the smaller framework kickstarts is easier to absorb. Veda makes more sense once you already understand the basics and want a stronger application reference.

It is also not a complete commerce solution. If you need carts, checkout, accounts, and orders, you would use Veda as the content and experience layer and integrate the commerce layer separately.

Fastest way to try it

The shortest path is:

1. Clone the repo.
2. Seed the kickstart-veda-seed stack.
3. Create a delivery token with preview enabled.
4. Add the Contentstack values to your local env file.
5. Enable Live Preview for the correct local URL.
6. Run npm install and npm run dev.

Once it is running, spend a little time clicking around instead of only opening the homepage. Veda makes the most sense when you experience the different content shapes:

• a flexible marketing page
• the products listing
• a product line
• a category
• an individual product

That is where the template’s structure really starts to show.

A good next step after the first run

The best next move is not redesigning it immediately. Start by extending the content model or one of the modular blocks.

Good ways to explore it further are:

• add a new modular block type and wire it into ComponentsRenderer
• add another merchandising section to a product line
• extend the filter model for the products page
• adapt the product detail experience to your own domain

That lets you learn the repo on its own terms before reshaping it into your own design system.