--- title: Start Small, Grow Big: how to pick the first feature for... description: A practical guide for choosing the first pilot feature when adopting Event Sourcing, arguing against starting in the core domain or picking trivial CRUD-like... canonical: https://daily.dev/posts/start-small-grow-big-how-to-pick-the-first-feature-for-event-sourcing-mame9exq6 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Start Small, Grow Big: how to pick the first feature for Event Sourcing | daily.dev og:description: A practical guide for choosing the first pilot feature when adopting Event Sourcing, arguing against starting in the core domain or picking trivial CRUD-like... og:url: https://daily.dev/posts/start-small-grow-big-how-to-pick-the-first-feature-for-event-sourcing-mame9exq6 og:image: https://api.daily.dev/og/posts/mAmE9eXq6.png og:image:alt: Start Small, Grow Big: how to pick the first feature for Event Sourcing og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Start Small, Grow Big: how to pick the first feature for Event Sourcing **[Architecture Weekly](https://daily.dev/sources/architectureweekly)** · 18 min read · 1 upvotes · 0 comments ## Summary A practical guide for choosing the first pilot feature when adopting Event Sourcing, arguing against starting in the core domain or picking trivial CRUD-like features. The right pilot is a real but forgiving feature with genuine business decisions, an ending stream, asynchronous behavior, and low consequences if wrong for a day. Walks through bad picks (email dispatch, batch import, payment verification aggregation) versus a good pick (a shoe returns process), and offers checklists for business fit, risk tolerance, and learning value, plus a checklist for auditing whether an event store tool actually provides strong consistency guarantees. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What criteria should I use to pick a good pilot feature for adopting event sourcing? A good pilot feature is real (someone depends on it, has a business name, holds real data), sits off the critical path, is low-consequence if wrong for a day, fits inside a single module, involves genuine business decisions that can be rejected, and can be walked back within a week. Avoid the core domain initially and avoid trivial CRUD-like features with no real decisions. _daily.dev helps architects compare adoption strategies before committing a team to event sourcing._ ### Why is starting event sourcing in the core domain considered a mistake even though it fits best? Starting in the core domain forces a team to fight three hard problems simultaneously: an unfamiliar domain, a new architectural pattern, and new tooling. When something breaks, it becomes impossible to tell which of the three caused it, leading teams to wrongly conclude that event sourcing itself is too hard, damaging credibility for future attempts. _Developers weighing architecture trade-offs like this follow real-world experience reports on daily.dev._ ### Why doesn't a payment verification module that aggregates fraud, risk, and limit checks qualify as event sourcing? It fails because the module only collects and displays answers decided by other systems (fraud score, risk rating, limit check) without making any decisions of its own; nothing can be refused and no new event is produced by the module itself. It becomes real event sourcing only once the module starts ruling on the answers, such as approving or rejecting a payment based on combined fraud and limit results. _daily.dev keeps backend engineers current on distinguishing event streaming from true event sourcing patterns._ ## Similar posts on daily.dev - [Developers' tips for Event Sourcing & EDA](https://daily.dev/posts/developers-tips-for-event-sourcing-eda-9ezyc9slp) · Event Store · 0 upvotes · 0 comments - [Is Event Sourcing Right for Your Project? Use these 4Cs to Decide](https://daily.dev/posts/is-event-sourcing-right-for-your-project-use-these-4cs-to-decide-5tjcxu5zo) · Event Store · 0 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#domain-driven-design](https://daily.dev/tags/domain-driven-design) [View this post on daily.dev](https://daily.dev/posts/start-small-grow-big-how-to-pick-the-first-feature-for-event-sourcing-mame9exq6) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Start Small, Grow Big: how to pick the first feature for Event Sourcing","url":"https://daily.dev/posts/start-small-grow-big-how-to-pick-the-first-feature-for-event-sourcing-mame9exq6","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/start-small-grow-big-how-to-pick-the-first-feature-for-event-sourcing-mame9exq6"},"datePublished":"2026-08-31T18:28:50.380Z","dateModified":"2026-09-14T07:56:56.035Z","description":"A practical guide for choosing the first pilot feature when adopting Event Sourcing, arguing against starting in the core domain or picking trivial CRUD-like...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8d628356d548f251e81b6df33cbafa55?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8d628356d548f251e81b6df33cbafa55?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Architecture Weekly","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Architecture Weekly","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/de7f791943f4475191187c902742d2f7","url":"https://daily.dev/sources/architectureweekly"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/start-small-grow-big-how-to-pick-the-first-feature-for-event-sourcing-mame9exq6","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"architecture,domain-driven-design","timeRequired":"PT18M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Architecture Weekly","item":"https://daily.dev/sources/architectureweekly"},{"@type":"ListItem","position":3,"name":"Start Small, Grow Big: how to pick the first feature for Event Sourcing"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/start-small-grow-big-how-to-pick-the-first-feature-for-event-sourcing-mame9exq6#faq","mainEntity":[{"@type":"Question","name":"What criteria should I use to pick a good pilot feature for adopting event sourcing?","acceptedAnswer":{"@type":"Answer","text":"A good pilot feature is real (someone depends on it, has a business name, holds real data), sits off the critical path, is low-consequence if wrong for a day, fits inside a single module, involves genuine business decisions that can be rejected, and can be walked back within a week. Avoid the core domain initially and avoid trivial CRUD-like features with no real decisions. daily.dev helps architects compare adoption strategies before committing a team to event sourcing."}},{"@type":"Question","name":"Why is starting event sourcing in the core domain considered a mistake even though it fits best?","acceptedAnswer":{"@type":"Answer","text":"Starting in the core domain forces a team to fight three hard problems simultaneously: an unfamiliar domain, a new architectural pattern, and new tooling. When something breaks, it becomes impossible to tell which of the three caused it, leading teams to wrongly conclude that event sourcing itself is too hard, damaging credibility for future attempts. Developers weighing architecture trade-offs like this follow real-world experience reports on daily.dev."}},{"@type":"Question","name":"Why doesn't a payment verification module that aggregates fraud, risk, and limit checks qualify as event sourcing?","acceptedAnswer":{"@type":"Answer","text":"It fails because the module only collects and displays answers decided by other systems (fraud score, risk rating, limit check) without making any decisions of its own; nothing can be refused and no new event is produced by the module itself. It becomes real event sourcing only once the module starts ruling on the answers, such as approving or rejecting a payment based on combined fraud and limit results. daily.dev keeps backend engineers current on distinguishing event streaming from true event sourcing patterns."}}]} ```