# Customizing Veda for your own project - **Authors:** Tim Benniks - **Published:** 2026-04-07T10:58:05.856Z - **Updated:** 2026-04-07T10:58:55.928Z --- By now, you should understand enough to avoid the two common bad outcomes: either treating Veda as untouchable, or tearing it apart so quickly that you destroy the patterns that made it useful in the first place. This chapter is about customizing with intent. ## What you'll learn - Which changes are safe to make first - How to replace brand-specific content without destabilizing the architecture - How to extend content types and modular blocks deliberately - How to adapt route behavior while keeping content contracts clear - How to preserve preview and editorial workflows while evolving the starter ## Start with the lowest-risk customizations Veda implementation: The safest first wave of changes is usually content and branding, not architecture. That includes: - replacing copy - replacing images and visual branding - renaming product lines and categories - updating navigation content - adjusting seeded entries to fit your domain This lets your team get comfortable with the content model and editorial workflow before changing the app's structural assumptions. ## Then decide what should stay generic and what should become project-specific Contentstack concept: Not every content type should remain as it is in the starter. Ask: - Are your "products" really products, or are they case studies, destinations, or services? - Do you need product_line, or would another grouping concept make more sense? - Should the current page type remain your flexible page-builder type? - Which block types are truly reusable in your domain? The goal is not to preserve Veda terminology forever. The goal is to preserve the quality of the modeling decisions. ## Add new modular blocks carefully Veda implementation: When you add a new modular block, there are usually at least three responsibilities to update: - the content model definition in Contentstack - the frontend component that renders the block - the central component mapping layer If you only do one of these, the system becomes inconsistent. Production note: The central renderer is your friend here. It gives you one obvious place to wire in new block types and one obvious place to fail loudly if the frontend does not yet support a newly modeled block. ## Evolve routes only after content assumptions are clear Contentstack concept: Routes are a contract between the frontend and the content model. If you change URL strategy, revisit: - which content type owns the URL - how routes derive paths - which fetchers query by that URL - how metadata is generated - how preview identifies the correct content type for the current page This is why route changes should usually happen after, not before, you understand the current model. ## Keep preview support intact while you customize Veda implementation: It is easy to break preview accidentally by focusing only on visible UI changes. Watch these areas closely: - editable bindings on rendered fields - empty-state wrappers for modular regions - preview-aware fetchers - the preview wrapper's content-type routing logic If you rename content types or add new previewable page types, update the preview orchestration layer deliberately. ## Recommended customization sequence If you want to change Veda without losing its strengths, use this order: - update content and branding - validate the content model against your real domain - rename or reshape content types if needed - add or remove block types - adjust route strategy - revisit preview and metadata behavior - optimize performance and deployment details That order keeps the risk lower because each stage builds on a stable earlier stage. ## What to keep even if your domain changes completely Even if your project is not remotely commerce-shaped, these are still worth preserving: - centralized SDK setup - focused content fetchers - a page utility layer - an explicit modular block renderer - preview as a dedicated runtime mode - route-aware metadata generation Those are architectural strengths, not jewelry-store-specific decisions. ## What to throw away without guilt You do not need to keep: - the brand story - the exact content type names - the category and product semantics - the visual design - any route pattern that no longer matches your domain The rule is simple: keep the good abstractions, not the accidental branding. ## Key takeaways - Start by changing content and branding before you change architecture - Preserve the quality of the modeling decisions even if you rename the domain concepts - Add new modular blocks by updating both the content model and the frontend renderer - Treat route changes as content contract changes, not only page file changes - Review preview support explicitly whenever content types, blocks, or routes evolve --- ## Frequently asked questions ### What are the lowest-risk changes to make first when customizing Veda? Start with content and branding updates: copy, images, navigation content, and seeded entries. Avoid architectural changes until the team understands the model and workflow. ### How do you add a new modular block without breaking consistency? Update three places together: the Contentstack content model, the frontend rendering component, and the central component mapping layer. Missing any one creates mismatches between authored content and rendering. ### Why should route changes happen after content assumptions are clear? Routes are a contract between the frontend and the content model. Changing URL strategy affects which type owns the URL, how fetchers query, metadata generation, and how preview resolves the current page. ### What commonly breaks Contentstack preview during customization? Preview often breaks when editable bindings, empty-state wrappers, preview-aware fetchers, or preview routing logic are not updated after renaming content types or adding new page types. ### What parts of Veda are worth keeping even if the domain changes completely? Keep the architectural abstractions: centralized SDK setup, focused fetchers, page utilities, an explicit block renderer, preview as a dedicated runtime mode, and route-aware metadata generation. --- ## Chapter Navigation **← Previous:** [Live Preview and Visual Builder](https://developers.contentstack.com/guides/contentstack-0-to-100-for-developers/live-preview-and-visual-builder) **Next →:** [Production readiness, troubleshooting, and next steps](https://developers.contentstack.com/guides/contentstack-0-to-100-for-developers/production-readiness-troubleshooting-and-next-steps)