When Sergey Baranenko first started publishing 3D assets, the process seemed straightforward: finish a model, export it, create a listing, and move on.
That approach works when a creator has a handful of products.
But as the catalog grew, something became clear: publishing assets at scale was becoming less about individual models and more about building a reliable production system.
After creating roughly 80 public Fab listings for his project, Knit of Shadows, Sergey began looking at marketplace publishing differently.
The listing was no longer an administrative task that happened after the model was finished.
It had become part of the production pipeline.
For a solo creator, the model, technical information, preview images, naming, package structure, pricing, and buyer-facing description all need to describe the same product.
The biggest lesson wasn't simply about working faster.
It was about removing repeated confusion.
A Finished Model Isn't Necessarily a Finished Product
A source file can look complete in Blender while still being far from ready for a buyer.
Sergey eventually began separating his workflow into three layers.
The first is the source layer — the editable production file and the actual object.
The second is the delivery layer — exported formats, naming conventions, folder structure, and the files a buyer receives.
The third is the listing layer — previews, technical information, categories, tags, descriptions, pricing, and the promise made on the marketplace page.
When those layers don't match, problems appear.
A listing might claim that a pack contains six assets while the final archive contains five. A screenshot could show a variant that isn't included. Technical information might describe an earlier version of an export.
Each mistake is relatively small.
But across dozens of products, small inconsistencies become much easier to repeat.
That's why Sergey began treating listing QA as product QA.
An example of a filled Fab listing for a stylized fantasy tree, showing the asset preview, formats, category, tags, price, and buyer-facing description together.
Deciding Between a Single Asset and a Pack
Another challenge emerged as the catalog grew: not every finished model needed to become its own product.
Sergey started using a simple test.
A standalone asset should have a clear role by itself. It should be understandable without several neighboring props, visually distinct enough to justify its own product page, and useful beyond one very specific arrangement.
A pack can be more valuable when the combination is what solves the problem.
A blacksmith workspace, modular building set, weapon family, or themed interior collection may contain many individual models, but together they can provide a more complete solution for a game developer.
This changed how Sergey approached new work.
Instead of asking only, "What model should I make next?", he began asking:
- What gameplay or scene role does this solve?
- Does it extend an existing visual family?
- Would a developer naturally search for this asset alone?
- Could it make an existing pack more complete?
- Is it genuinely a new product, or simply another SKU?
The objective wasn't necessarily to create fewer products.
It was to avoid creating products simply because a file happened to be finished.
Technical Fields Became Part of the Production Process
Marketplace forms can feel like paperwork until you have to fill out similar information dozens of times.
Then they become something else: a way of checking whether the asset is actually understood.
Geometry counts, meshes, formats, materials, textures, LODs, collision, scale, and other technical details force a creator to verify what is actually being shipped rather than relying on memory.
The publishing workflow used to record geometry and pack metadata for a multi-asset product.
For Sergey, one rule became particularly important:
If a technical fact isn't known, it shouldn't be guessed just to make a listing look complete.
Repeated publishing creates an easy temptation to reuse old descriptions or fill out fields from habit.
A consistent checklist makes uncertainty visible before it becomes a customer-facing claim.
Turning Art Direction Into Something That Can Be Checked
Knit of Shadows has developed a recognizable stylized fantasy, gothic, and arcane direction.
Dark metals, wood, violet accents, readable silhouettes, and game-oriented construction appear repeatedly throughout the catalog.
But "keep the same style" isn't enough of a production rule when you're building dozens of assets.
Sergey began translating the visual direction into concrete rules:
- Large silhouettes come before micro-detail.
- Wood forms should remain broad and readable.
- Dark iron and gunmetal provide a recurring material language.
- Strong magical accents are reserved for important or ritual objects.
- Supports, joints, handles, and thickness should make physical sense.
- Decorative details shouldn't make an object difficult to understand at gameplay distance.
These rules don't replace artistic decisions.
They make those decisions easier to review.
They also help determine whether a new asset actually belongs in an existing pack or looks like it came from another project.
Working review criteria used to evaluate silhouette, proportion, materials, construction, accent hierarchy, and duplicate assets.
The Preview Is Part of the Product
For a marketplace asset, the preview has two jobs.
It needs to make the product attractive, but it also needs to make it understandable.
Those aren't always the same thing.
Sergey prefers previews that make the silhouette, materials, object count, and intended use easy to understand.
A dramatic scene render can sell atmosphere, but it shouldn't replace clear evidence of what the buyer will actually receive.
That means the preview, technical information, package, and description all need to agree.
If a buyer has to study the listing just to figure out what's included, the product is already creating unnecessary friction.
Building Tools From Repeated Problems
Some of the free planning utilities Sergey created for Knit of Shadows came from an unexpected place: repetitive questions inside his own workflow.
How much production time can a pack justify?
What should an outsourcing brief contain?
How should assets be named?
What needs to be checked before a Unity import?
What does a basic asset budget look like?
After encountering the same questions repeatedly, Sergey began turning some of the answers into calculators, checklists, and reusable workbooks.
His approach to automation is relatively simple:
Automate repeated structure, not artistic judgment.
Calculations, checklists, naming helpers, packaging checks, and administrative tasks are good candidates for automation.
Decisions about visual identity, product cohesion, truthful screenshots, and whether a listing accurately represents its files are much harder to reduce to a formula.
Those still require human judgment.
What He Would Do Differently
If Sergey were starting the catalog again today, he would establish five things from the beginning:
- A stable naming convention for source and exported files.
- A clear single-asset-versus-pack decision before modeling too far ahead.
- A technical fact sheet for every product.
- A fixed preview and buyer-package QA checklist.
- A written art-direction rule set concrete enough to review.
None of these systems makes modeling more exciting.
But they make a growing catalog considerably easier to maintain.
For a solo creator, that matters.
Every time a creator has to rediscover a file, rewrite the same technical explanation, fix an inconsistent name, or remember why two variants were packaged differently, valuable attention is being spent on maintenance instead of creation.
From a Collection of Assets to a System
Reaching 80 listings is a useful milestone for Sergey, but the number itself isn't the most interesting part of the story.
What matters is what producing those 80 listings revealed.
Publishing forced better naming.
Packaging forced clearer scope.
Technical forms forced better verification.
Buyer questions forced clearer previews and descriptions.
Repeated planning questions eventually became reusable tools.
The catalog gradually became more than a collection of finished models.
It became a system.
That's perhaps the most useful lesson from Sergey Baranenko's experience with Knit of Shadows.
For an indie creator, scaling a catalog isn't simply about producing more assets.
It's about creating a workflow where those assets can be understood, verified, delivered, updated, and integrated with everything else without creating new confusion.
And sometimes, building that system is what makes the next 80 assets possible.
Explore Sergey’s Work
Sergey Baranenko is the solo creator behind Knit of Shadows, a stylized fantasy 3D asset catalog and a collection of practical game-development planning tools.
Fab catalog: https://www.fab.com/sellers/Knit%20of%20Shadows
Knit of Shadows: https://knit-of-shadows-cloud.vercel.app/
Free Game-Dev Tools: https://knit-of-shadows-cloud.vercel.app/free-game-dev-tools/
itch.io: https://knit-of-shadows.itch.io/
