DEV Community: Igor Shadurin

I got tired of paying $50/mo for AI video tools so I built and open-sourced my own

Igor Shadurin — Fri, 07 Aug 2026 16:03:44 +0000

Honestly? I just got frustrated. I was paying for like 3 different AI video subscriptions, burning through credits, and still not getting what I wanted. So I did what any reasonable developer would do - I spent way more time building my own thing than I would've ever spent on subscriptions.

But hey, I learned a ton about shipping a SaaS-like product, and some of it might actually be useful to you.

The market gap that got me started

So faceless video is huge right now. If you haven't seen it - it's those short vertical videos on TikTok/YouTube Shorts where nobody appears on camera. Horror stories, news digests, fact videos, that kind of stuff.

The demand is insane. One video I generated hit *90K views* on TikTok. And I'm not even a content creator - it was just a test video.

But every tool in this space is a subscription SaaS. $20–50/mo minimum. And they all have the same problem: you're locked into their pipeline, their models, their templates. Want to change the image provider? Too bad. Want to run it locally? Nope. Want to generate in 7 languages at once? Pay 7x.

I looked at the competitive landscape - RevidAI, Faceless video, AutoShortsAI, Fliki, InVideo, Pictory, etc. - and noticed something interesting: *not a single one is open-source, and not a single one lets you self-host.* Every single player is a closed SaaS.

That felt like a gap worth filling. So I built YumCut and open-sourced it.

Architecture decisions

This was the single most important decision. Instead of building a monolith where everything is tightly coupled, I made every processing step a separate utility. Image generation, doodling effects, video assembly - each one is a standalone script that takes input and returns output.

Why this matters:

*Swappable providers* - user wants a different image API? They write a small script. Done.
*AI-agent friendly* - when I switched to using Codex for development, this architecture meant the AI could work on one utility without breaking others
*Language agnostic* - core utils are TypeScript, but you could plug in Python, Go, whatever

I'm not sure what to call this pattern exactly - pipeline-based? Plugin architecture? Whatever it is, it saved the project.

All video assembly happens through dynamically generated FFmpeg commands. Transitions, effects, overlays - everything. No proprietary video processing, no heavy dependencies. Just FFmpeg.

This sounds straightforward until you hit edge cases. Like transparent video overlays.

The rabbit holes nobody warns you about

I wanted overlays - transparent videos layered on top of the main video to make it feel alive. Simple concept, right?

Turns out most codecs that support alpha channels store video in absurdly large formats. *One minute of overlay = 1GB+.* That's not gonna work when you're generating hundreds of videos.

I ended up using WebM with VP9 - modern, open, supports transparency. But getting FFmpeg to encode it properly took way longer than I'd like to admit. One of those things where you think it'll take an afternoon and it takes a week.

The doodling effect

I built this effect that simulates an image being drawn - extract contours, convert to SVG, animate the paths appearing. The video with this effect got 90K views, so clearly it resonates.

But here's the thing - existing services charge per-image for this effect, roughly the same price as generating the image itself. Making it work with open-source tools only, with no paid APIs, was a significant chunk of work. Contour extraction, SVG conversion, animation timing - lots of fiddling.

Multi-language TTS is harder than you think

English TTS? Solved problem. Plenty of good local models.

But I needed 7 languages (English, Russian, Spanish, French, German, Portuguese, Italian). And a voice that sounds great in English will sound robotic in Spanish. Every language needs its own voice configuration.

I started with ElevenLabs (subscription, use-it-or-lose-it monthly quota - annoying model btw). Tried local models (quality issues with non-English). Eventually landed on budget cloud options like Minimax and InWorld that support voice cloning across languages.

The lesson: *multilingual anything adds 3-5x complexity.* If you're building a SaaS and thinking "we'll add more languages later" - budget way more time than you think.

How AI agents built most of this

I started building in Cursor with Claude. It worked, but it was like pair programming with someone who drank 10 cups of coffee. I'd ask for one feature and get three - two of which were broken. Constant cleanup.

The tight coupling problem was real. "Fix this function" and suddenly three other files are modified with unnecessary refactors.

Codex: the focused senior dev

Switching to OpenAI Codex was a game changer. It does what you ask, nothing more. Changing one part of the project stopped being scary because Codex wouldn't randomly touch other parts.

The lesson for SaaS builders

If you're using AI agents for development, architecture matters more than ever. The pluggable utility pattern I chose wasn't just good engineering - it was essential for AI-assisted development. Isolated components = AI agents that don't break your stuff.

Competitive landscape and positioning

Here's the thing about this market: *every competitor is a closed SaaS with no self-hosting option.*

I'm not saying open-source is always the right play. But in a market where every single player is a $30/mo subscription doing roughly the same thing - being the open-source alternative is a real differentiator.

The online version offers 3 free video generations. Locally, it's unlimited.

Licensing: the middle ground

Current license: free for personal use, contact me for commercial deployment as a service. I'm considering relaxing this to fully open depending on community demand.

Honestly still figuring out the right approach here. If you've navigated open-source licensing for a product like this, I'd love to hear what worked.

Fin

If you're building in the AI content space or thinking about open-sourcing a SaaS alternative - happy to chat in the comments.

*GitHub:* https://github.com/IgorShadurin/app.yumcut.com
*YumCut:* https://yumcut.com/?utm_source=devto

How I Cut AI Video Generation Costs by 8x

Igor Shadurin — Fri, 07 Aug 2026 16:03:28 +0000

A few months ago, I was working on a pet project. YumCut is an end-to-end service for creating short vertical videos, from writing the text and generating images to editing and adding subtitles.

A critical problem surfaced quickly: cost. One minute of video required around twenty generated images, or about $0.80 per minute. Beyond visuals, audio generation added another $0.20 per minute, along with minor additional costs for editing and subtitle generation.

I started looking for a way out. This article explores the unconventional techniques that helped reduce those costs several times over, as well as an open-source solution that makes it possible to generate images up to eight times cheaper than commercial APIs.

Full code and instructions are available on GitHub.

First approach: multiple scenes in one frame

The logical solution seemed obvious: generate several images in a single request by placing scenes next to each other. In theory, this should reduce costs proportionally to the number of images.

The first attempt was to put all eight scenes into the prompt at once. The result was disastrous: the model simply mixed all elements into one blurry composition, unusable for video editing.

By reducing the number of scenes to two per image, I got an acceptable result. That already cut the cost in half, but it was still far from the target.

Key insight: borders must be literally visible

It turned out that AI models struggle to determine logical boundaries between separate areas. The solution was simple: use colored zones (red and blue).

Instead of an abstract description, I started sending a PNG template with clear borders and a matching instruction: “The first idea is in the red area, the second idea is in the blue area. Fill each area completely.”

This technique did not require additional costs, but it dramatically improved the quality of scene separation. The model now understood the structure and rarely mixed elements.

However, this was only a partial solution. I needed a drastic reduction. I had to cut the price by another order of magnitude.

Second approach: migrating to open-source alternatives

The idea was to find open-source/open-weight image-generation models, run them in the cloud, and reduce costs that way.

First, I had to identify which models were freely available. There are many: Qwen-Image, FLUX, HunyuanImage, Stable Diffusion, and others. For my use case, I had one extra requirement - the ability to reuse characters across many generated images. That is why I chose Qwen-Image-Edit.

I audited the market of commercial generators:

Major APIs (OpenAI/Google Gemini/Stability AI): similar prices or higher
Alibaba cloud services: about $0.04 per image - roughly the same
Self-hosted options like RunPod: you need a large number of images per run to reach meaningful savings

The picture was disappointing - even the creators of Qwen-Image, Alibaba, were offering the model at inflated prices. But then I found runware.ai and together.ai, where generating images with Qwen-Image-Edit and Qwen-Image was almost eight times cheaper than Nano Banana - ~$0.005 vs. $0.04.

Third approach: improving image detail

As it turned out, with low image-generation prices, the model started producing more uniform images - all scenes looked too similar to each other.

Here is an example of generated images with different prompts about a happy cat on the beach:

Even though the images look good, there is a missing layer for improving the story prompts. The obvious solution is to add a layer between the story prompt and the image generator. But we have to do so with an LLM that doesn't increase the cost significantly. So I knew I needed to test many LLMs before settling on one that worked best for me.

To do so, I used openrouter.ai. Once you write the wrapper code, you can switch to any available model. After testing a dozen models, I settled on openai/gpt-oss-120b with low reasoning effort. The improved image-generation prompt costs about ~$0.0003, and the images above turn into results like these.

The images became more diverse, even with an almost identical prompt. GPT OSS improved the description for Qwen-Image, and it also offered a lever that let me control the style and mood of the images.

Results: numbers that speak for themselves

Metric	Before	After	Savings
Cost per image	$0.04	$0.0053	7.54
1-minute video (20 images)	$0.8	$0.106	7.54
Full minute of video	$1	$0.306	3.26

By combining the two approaches, the price drops by another factor of two, but sometimes you will see artifacts in the images because the original image is being split.

This price was good enough for me, so I stopped at this result.

How to generate AI images 8x cheaper?

Igor Shadurin — Wed, 28 Jan 2026 08:02:56 +0000

A few months ago, I was working on a pet project.

YumCut is an end-to-end service for creating short vertical videos: from writing the text and generating images to editing and adding subtitles.

A critical problem showed up quickly: cost. One minute of video required about twenty generated images, or $0.8/min. Besides the visuals, you also need to generate audio - $0.2/min - plus minor additional costs for editing and subtitle generation.

I started looking for a way out. This article is about the unconventional techniques that helped reduce the cost by several times, and about an open-source solution that makes it possible to generate images eight times cheaper than commercial APIs. Full code and instructions are available on GitHub.

First approach: multiple scenes in one frame

The logical solution seemed obvious: generate several images in a single request by placing scenes next to each other. In theory, this should reduce costs proportionally to the number of images.

The first attempt was to put all eight scenes into the prompt at once. The result was disastrous: the model simply mixed all elements into one blurry composition, unusable for video editing.

By reducing the number of scenes to two per image, I got an acceptable result. That already cut the cost in half, but it was still far from the target.

Key insight: borders must be literally visible

It turned out that AI models struggle to determine logical boundaries between separate areas. The solution was simple: use colored zones (red and blue).

Instead of an abstract description, I started sending a PNG template with clear borders and a matching instruction: "The first idea is in the red area, the second idea is in the blue area. Fill each area completely."

This technique did not require additional costs, but it dramatically improved the quality of scene separation. The model now understood the structure and rarely mixed elements.

However, this was only a partial solution. I needed a drastic reduction. I had to cut the price by another order of magnitude.

Second approach: migrating to open-source alternatives

The idea was to find open-source/open-weight image-generation models, run them in the cloud, and reduce costs that way.

I audited the market of commercial generators:

Major APIs (OpenAI/Google Gemini/Stability AI): similar prices or higher
Alibaba cloud services: about $0.04 per image - roughly the same
Self-hosted options like RunPod: you need a large number of images per run to reach meaningful savings

Third approach: improving image detail

As it turned out, with low image-generation prices the model started producing more uniform images - all scenes looked too similar to each other.

Here is an example of generated images with different prompts about a happy cat on the beach:

Even though the images look good, there is a missing layer for improving the story prompts. The obvious solution is to add a layer between the story prompt and the image generator. But it has to be an LLM that does not increase the cost significantly.

To test many LLMs, I used openrouter.ai. Once you write the wrapper code, you can switch to any available model. After testing a dozen models, I settled on openai/gpt-oss-120b with low reasoning effort. The improved image-generation prompt costs about ~$0.0003, and the images above turn into results like these.

The images became more diverse even with nearly the same prompt. GPT OSS improved the description for Qwen-Image, and you now have a lever that lets you control the style and mood of the images.

Results: numbers that speak for themselves

By combining the two approaches, the price drops by another factor of two, but sometimes you will see artifacts in the images because the original image is being split.

This price was good enough for me, so I stopped at this result.

Dive into dApps: Your Ultimate Guide to Start Crafting Them Today!

Igor Shadurin — Tue, 17 Oct 2023 09:45:48 +0000

Content Overview

What is dApp?
What client-side technologies should be used for a dApp?
Which type of domain should you choose?
Authentication: MetaMask's Dark Side
Blockchain Selection: Which Chains Are Best for dApps?
Funding Your Idea Through Grants

What is dApp?

The commonly accepted definition of a dApp is, in short, an application that can operate autonomously using a distributed ledger system. At first glance, it seems straightforward. But, when you begin to question and list examples of dApps, it appears most dApps wouldn't qualify. It may even seem as if true dApps don't exist.

If one developer tried to explain to another what a dApp is in 2023, they'd probably say, "Well, it's like a website that calls various APIs working with blockchain." Just like that, the magic of the term 'dApp' would vanish. The other developer would think, "What's the big deal? Why so much fuss about it?"

The reason is that the genuine concept of dApps has long been sacrificed for user convenience. Originally, the term implied that every instance of the application runs on the user's device. You'd fetch wallet balances from your node, and you'd send transactions from it as well. The application itself should be stored on a distributed storage system resistant to censorship, outages, and attacks. All user-generated data should also be stored in such storage or directly in a blockchain smart contract.

It's a captivating concept, but it clashed with reality. Blockchain data can weigh gigabytes or even terabytes. Decentralized storage requires specific software, space for distributed data, isn't as fast as AWS, and often needs specialized browsers. Interacting with smart contracts costs money in cryptocurrency, and purchasing it isn't straightforward for first-timers. Then, factor in the complexity of setup, the need for specialized knowledge, ample free time, and the myriad of blockchains out there.

So, dApp developers started offloading the most complex parts for users to separate services, interfacing with them solely via APIs. Now, almost every blockchain has its API. This means dApps have to store settings for each network to cater to more users.

While APIs for distributed storage exist, hosting the dApp on them isn't efficient. Most solutions can't compete with web2 in speed and convenience. Hence, such storage systems are only used for tasks where response time isn't a priority. Even on Hackernoon, Arweave is used only for backing up articles.

What client-side technologies should be used for a dApp?

Well, if we aim to reach the maximum number of people in 2023 and 2024, then client-side web technologies are the way to go for creating a dApp. True, backend technologies like PHP and Python won't cut it, but any framework based on JavaScript/Typescript will do the trick. You can pick from the top 3 frameworks: React, Angular, or Vue.js. However, in my experience, Web3 components for Angular are rarer. My personal choice is React with Typescript. Of course, nobody's stopping you from using plain JavaScript, but why would you?

Further, for interacting with smart contracts, you'll need some kind of library. The most popular ones are Web3.js and ethers.js. In my opinion, both aren't the most elegant. Their APIs frequently change, and code examples older than a year might not work straight away. My personal pick is ethers.js. Its structure feels more intuitive to me, and compared to Web3.js, the solutions tend to be more concise. In the documentation of various projects, examples are usually provided for at least these two libraries.

First and foremost, create an empty project (React + Typescript).

npx create-react-app project-name --template typescript

Navigate to the project directory.

cd project-name

Install ethers. This will ensure you have the most up-to-date version. Keep in mind that older examples from the internet might not work without adjustments.

npm i ethers

Which type of domain should you choose?

No, I'm not talking about top-level domains like .com, .org, and the like. I'm discussing whether one should opt for decentralized domains instead of traditional ones.

Yes, domains can be decentralized too. Instead of the usual top-level domains, you might come across ones like .eth, .nft, .wallet, .crypto, and .go. Unfortunately, using them in popular browsers (like Chrome and Safari) without additional extensions won't work. Various companies have been trying for years to establish a domain zone that functions both in web2 and web3. So far, agreements have only been reached with less popular browsers like Opera and Brave. In these browsers, Web3 domains work.

So, if your target audience primarily uses the most popular browsers, the choice is clear: you need a Web2 domain. However, if your application becomes popular, domain squatters might purchase a domain with your project's name. When the Web3 revolution takes place and domains become accessible in all browsers, these squatters will likely demand a hefty price for that domain.

From this, it emerges that Web3 domains might be worth purchasing as a safeguard against squatters or for a hardcore audience using specific browsers.

Furthermore, such domains can serve as an alternative to the unreadable wallet addresses. Instead of a complex address like 0x5301b241879e66EC45fD284D3D97A5C51472D6f3, you could use a domain like mydapp.crypto to send and receive funds.

Authentication: MetaMask's Dark Side

Currently, MetaMask stands as the most popular browser extension for storing people's wallet private keys. The private key is the most crucial element - "Not Your Keys, Not Your Crypto". Entrusting such a vital component to anyone is a no-go, making it preferable to store it on one's device. MetaMask, in this context, allows users to keep their private key locally and doesn't share it with anyone, not even dApps, no matter how nicely they ask.

Despite its millions of users, getting started with MetaMask isn't straightforward. One has to go through a myriad of not-so-simple steps to set up an initial empty wallet. And then, an equal number of steps are required to fund that wallet. I can confidently say that the next billion users will opt for a different solution. But as of now, it's the industry standard, and every dApp should support MetaMask.

But what if I told you there are over a hundred other wallets out there? It would be ideal to support those as well. But don't pull your hair out just yet! Solutions already exist that support all popular wallets. Typically, apart from browser extensions, these solutions also cater to mobile apps, significantly broadening the potential user base.

Examples of services you can use: Web3Auth, WalletConnect.

Blockchain Selection: Which Chains Are Best for dApps?

If you delve into the website of nearly any blockchain project, you're often met with bold claims: their blockchain is the fastest, most user-friendly, cheapest, and boasts millions of users now or will very soon. So, with this vast array of blockchains and ecosystems, how do you pick the right one?

In my view, the answer is clear-cut: if the blockchain is EVM-compatible, you're already halfway there. EVM, or Ethereum Virtual Machine, backed by the Ethereum Foundation, is a standard that any blockchain project can adopt. Critically, all tools for testing, debugging, deployment, linting, explorers, etc., will seamlessly integrate with this new chain. This means that if you create a dApp for one EVM-compatible project, it can, with minimal configuration, work across nearly all others. Sounds like magic, right?

Regarding non-EVM compatible projects, when developing dApps for them, you must have a clear rationale. Recognize that targeting these chains may limit your user base, offer fewer tools, and present more unprecedented bugs. The smart contract languages also differ, sometimes drastically. Here are the languages used for smart contract development in the top 20 capitalization projects: Solidity, Plutus, FunC. Each of these languages is tailored specifically for individual blockchains. Grasping each requires considerable time, as their operational principles vary substantially.

Of course, you can architect your dApp to operate across a majority of these diverse chains. However, that's an advanced move and quite time-consuming. Straddling two worlds isn't always straightforward.

Let's dive right back into building our dApp with the newfound knowledge at our disposal. For this walkthrough, I'll be using the Gnosis Chain as our EVM-compatible blockchain. It's an L2 network that boasts cost-efficient transactions. For several years now, I've deployed a public notes smart contract on it, allowing users to create textual notes under their usernames. You can find it at this address: 0xf6b270136Da7F8a2113B93a3b9Eeaf5160C45bA0.

To read data from this contract, you first need to instantiate a provider. A provider essentially acts as an RPC API to a specific blockchain node. The server delivering the data is already in sync with the blockchain network and provides the most up-to-date state.

const provider = new JsonRpcProvider('https://rpc.gnosischain.com/');

To fetch data from our contract, we'll create an instance of Contract from ethers.

const contract = new Contract('0xf6b270136Da7F8a2113B93a3b9Eeaf5160C45bA0', notesAbi, provider);

If I had linked my contract address with a .eth domain, then you could access the contract like this.

const contract = new Contract('myapp.eth', notesAbi, provider)

In this instance, we're passing in my smart contract's address, the provider, and the ABI (Application Binary Interface). The ABI ensures that the node can interpret state data from binary correctly. The ABI content is quite detailed for this article, so I've moved it to a separate URL.

Next, we need to prepare the username in the required format to use it for data retrieval:

const usernameHash = keccak256(toUtf8Bytes('igor'));

Then, you can fetch all the records I've saved in the smart contract like this:

const items = await contract.getNotes(usernameHash);

You can check out the entire code for App.tsx here.

Also, a quick heads-up: In the example, I'm using a free provider. If you're scaling a dApp with a significant user base, it might not be suitable. In such cases, you'd either want to set up your node or opt for paid providers from services like Alchemy or Infura.

Funding Your Idea Through Grants

In the fast-paced world of dApps, innovative ideas can often operate at a loss for extended periods. It's great if you've got a plan to turn a profit swiftly and a few thousand dollars to sustain yourself in the meantime. But if you don't, fret not.

Ideas with a sound financial potential always catch the eye of venture angels and investors. But in the Web3 universe, innovation is additionally fostered through grants provided by major foundations such as Ethereum, Binance, and Optimism. These grants are often disbursed without any strings attached, either in phases or as a lump sum. Unlike venture capital, grants don't come with the business obligations typical of angel investors.

Projects awarded grants from a specific foundation should, in the long run, positively impact that specific ecosystem. The conditions and allocated amounts vary from one foundation to another, with grant amounts ranging from hundreds to hundreds of thousands of dollars. These are often disbursed in the project's native tokens.

To gauge if your project idea aligns with a particular grant program, study previously awarded grants and benchmark against your own. Think you can deliver something similar, or even better? You're likely grant material.

But bear in mind, securing a grant can be a long process. Despite being a fantastic avenue to bring your project to life, be prepared for each stage to take weeks or even months. The stages you'll navigate are:

Application Preparation. Many grant applications are straightforward. You'll be detailing your idea and showcasing your team's expertise. Put forward a compelling pitch about both the project and the team. Lack of experience in Web3 might reduce your chances of securing a grant.
Project Evaluation. After submitting your application, anticipate a long evaluation phase. The higher the grant amount requested, the longer the evaluation. Typically, you'll receive an approval or rejection email. However, some projects might ghost your application. A month post-submission, don't hesitate to follow up on the application status. And feel free to apply to multiple foundations. Some projects might even qualify for grants from various foundations. Just be wary of potential conflicts of interest and clarify the feasibility of securing multiple grants upfront.
Contract Signing. Post grant approval, you'll engage in a phase of document preparation and signing by all committee members. While you can often start working before the contract signing, there's no guarantee that the contract will get finalized. The hold-up isn't always on the foundation's end; sometimes, sanctions might prevent a grant's disbursement based on your citizenship or residency.
Project Acceptance. Acceptance of your grant can be slow-paced. Every committee member will thoroughly vet your solution. Prep a top-tier demo of your project since some members might have less technical knowledge and will evaluate based solely on your demo resources: demo sites, video presentations.
Grant Payout. Post a successful grant review, the approval decision goes to accounting. Here, too, payments can get held up, especially if multiple people's confirmations are required. Often, these individuals are engaged across various projects, not just grants.

To obtain a list of nearly all projects offering grants, search for "List Web3 Grants" online.

As you can see, if you have experience in web2 development, not all concepts in web3 will be clear at first. Many things might raise questions. Nevertheless, this article calls for a part 2, where we could build a full-fledged application using different networks, with the capability to store data in a decentralized manner, as well as interact with smart contracts either at the user's expense or the developer's.

See you in the next part!