From Book-Cover Illustrator to Indie Developer: Maxim Mitenkov’s Journey of Building for His Own Pain
A CoderLegion Developer Story featuring Maxim Mitenkov
Interview conducted and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion
What happens when an illustrator gets tired of doing the same task over and over?
You build a tool.
For Maxim Mitenkov, that meant turning years of experience as a book-cover illustrator into a growing journey as an indie developer.
Maxim has spent more than fifteen years working in design, primarily creating book covers and illustrations. But processing dozens of images every month — resizing, cropping, compressing, and converting them for different destinations — became a problem he couldn't ignore.
The obvious solutions weren't good enough.
Photoshop Actions broke when the source changed. Scripts became difficult to maintain. Cloud-based image processors created a privacy problem when the files belonged to clients and hadn't been published yet.
So Maxim started building.
Today, he is the solo founder of Image Pipeline, a batch image processor that runs entirely in the browser.
His journey combines software engineering, illustration, product development, privacy, and the realities of building an indie product around a problem he personally understands.
From Computer Science to Illustration — and Back to Code
Maxim's relationship with technology didn't actually begin recently.
He studied Computer Science and Radioelectronics at Belarusian State University of Informatics and Radioelectronics (BSUIR) from 1993 to 1998, graduating as an Engineer.
Professionally, however, his career developed around design.
For more than fifteen years, he has worked as a book-cover illustrator, along with illustration and some branding work.
The tools were familiar:
Photoshop.
Illustrator.
A drawing tablet.
The creative side of the work was what mattered.
But there was another side to the job that was much less interesting.
Every month, Maxim would prepare 50 to 100 images for portfolios, clients, Behance, Pinterest, and other destinations.
Resize.
Crop.
Compress.
Convert.
Repeat.
Every hour spent repeating those tasks was an hour that wasn't spent drawing.
The Problem That Started Everything
The repetitive image-processing work eventually became too obvious to ignore.
Photoshop Actions seemed like a solution, but they fell apart when clients supplied images with different aspect ratios.
ImageMagick scripts worked, but only as long as Maxim remembered how they worked months later.
Cloud converters created an even bigger problem.
Client artwork could be unpublished or covered by an NDA.
Uploading it to someone else's server simply wasn't something Maxim wanted to do.
The problem was specific enough that he already knew what the product should look like:
Open a link, drag files in, hit a button, get a ZIP.
No account.
No upload.
No subscription.
That simple specification became Image Pipeline.
Becoming a Developer Because There Was a Problem
Maxim didn't originally set out to become a software developer.
Instead, he realized that the person who could write the script was also the person who could build the interface around it.
He started learning JavaScript.
Then he moved to React when plain JavaScript started becoming limiting for what he wanted to build.
Eventually, the code became a product.
His transition wasn't driven by a career plan.
It was driven by necessity.
"I did not become a developer on purpose. I became one because there was a problem and nobody else was going to fix it."
That idea captures much of Maxim's approach to development.
He isn't building software simply because software is interesting.
He's building because he sees something that could work better.
Why Image Pipeline Runs Entirely in the Browser
One of the most important decisions in Image Pipeline was privacy.
Rather than processing images on a backend, Maxim designed the application so the work happens inside the browser.
Resize.
Filters.
Format conversion.
ZIP creation.
All of it happens on the user's machine.
There is no server receiving the images.
There is no image-processing queue.
There is no server-side image storage.
The result is a privacy model based on architecture rather than marketing.
Maxim describes the claim simply:
"I can't see your images."
That's a powerful difference.
The product doesn't need to promise that someone won't access your files.
The files don't need to reach the server in the first place.
Building for Yourself Has an Advantage
Maxim was his own first user.
That changed the way he built the product.
He didn't need to survey users to decide which features were important in the beginning.
He already knew what he repeatedly needed.
Resize.
Crop.
Compress.
Export.
Those were the operations he performed constantly.
But building for yourself also creates blind spots.
Maxim discovered this after launching.
His first public review on AlternativeTo was only two stars.
The reviewer wanted brightness, contrast, and exposure controls. The preview was too small, and multiple export wasn't working.
Some of those requirements had never occurred to Maxim.
But the criticism was useful.
He fixed the problems.
The next review was five stars.
That experience led to one of the clearest lessons from the project:
"Your pain gets you version one. Other people's pain gets you everything after."
Launching Before Everything Was Perfect
Image Pipeline launched with nine nodes.
There was no elaborate onboarding system.
No extensive FAQ.
No attempt to build every possible feature before allowing people to use it.
Maxim wanted to find out whether anyone actually wanted the product.
That decision quickly exposed several lessons.
Minimum Isn't Readiness
The features Maxim personally needed weren't necessarily all the features other users expected.
An image-processing application naturally creates expectations around things like brightness, contrast, and exposure.
His own workflow had created a blind spot.
Preview Is Trust
The original preview wasn't good enough.
Users needed to see what was going to happen before processing their images.
Maxim rebuilt it with a larger live image, zoom functionality, and a before/after slider.
The preview eventually became one of the strongest parts of the product.
Feedback Beats Planning
Users also requested ways to change the mood and feeling of images.
Instead of spending weeks planning the feature, Maxim built an emotion filter in a couple of days.
The experience reinforced another principle:
"Launch early. The only expensive failure is launching late and finding out nobody wanted it."
The Technical Choice He Didn't Make
One of the most interesting technical decisions in Image Pipeline was choosing not to use WebAssembly.
WASM seemed like the obvious answer.
It's fast.
It's powerful.
It's designed for exactly the kind of computational work browsers increasingly need to perform.
But Maxim wasn't optimizing for benchmarks alone.
He wanted the application to open quickly, including on mobile devices.
WebAssembly would introduce additional download size, build complexity, and compatibility concerns.
So the image-processing core remained plain HTML5 Canvas code.
The application processes pixel buffers directly through browser APIs.
It may not be the fastest possible solution for enormous images.
But Maxim's goal wasn't to win an artificial benchmark.
It was to build something that solved the real problem efficiently.
The engine stayed small and relatively boring.
And that was exactly the point.
Why React Flow Was the Right Engineering Decision
The visual pipeline required a node-based interface.
Maxim could have built the node editor himself.
But that would have meant spending significant time solving problems that another project had already solved.
Instead, he chose React Flow.
It provided capabilities such as:
- Drag and drop
- Connections
- Connection validation
- Zooming
- Node-based interaction
That choice saved development time.
Rather than spending a month building and debugging a custom node canvas, Maxim could spend that time improving the actual product.
For him, that was the better engineering decision.
You don't prove that you're a good developer by rebuilding everything yourself.
Sometimes the better engineering decision is knowing what not to build.
From Nine Nodes to a Growing Product
Image Pipeline has grown significantly since its initial launch.
Maxim's profile notes that he shipped 14 node types in six weeks.
The product has expanded with functionality including:
- Blur and sharpen
- Denoise
- Watermarking
- Rotation
- Color temperature
- HSL adjustments
- Emotion filtering
The pattern behind many of these features remains simple.
Someone asks for something.
Maxim considers whether the request makes sense.
Then he builds it.
The product is evolving through actual usage rather than through a huge feature roadmap designed in isolation.
Privacy Isn't Just a Checkbox
Maxim sees privacy as more than a feature of Image Pipeline.
He believes the broader web is moving toward more client-side processing because users are becoming increasingly uncomfortable with uploading their data everywhere.
Every service wants an account.
Every signup form wants an email address.
Every cloud-based tool requires some level of trust.
Image Pipeline takes a different approach.
If the processing can happen locally, why send the user's files somewhere else?
For Maxim, privacy isn't a promise added after the architecture.
It's part of the architecture itself.
Building as a Solo Founder
Maxim's development schedule doesn't look like a traditional software job.
He describes it as switching.
Mornings are for illustration.
Days are for code.
Evenings are often for testing.
Image Pipeline was built in the gaps between paid illustration projects.
A client finishes early.
A day becomes available.
Instead of waiting for the perfect schedule, Maxim uses the time to build.
The hardest part isn't necessarily finding the hours.
It's switching between two very different mental modes.
Illustration is about emotion, composition, color, and visual judgment.
Programming is about logic, behavior, and systems.
Moving between the two takes time.
Sometimes that transition requires a coffee.
Sometimes a walk.
Then it's back to the other world.
How Design Influenced His Code
Maxim's background in illustration naturally influences how he builds software.
After spending years thinking about composition, color, typography, and visual communication, he can't simply ignore the interface.
The nodes need to look good.
Typography needs to be readable.
The preview needs to communicate trust.
Design isn't something that gets added at the end.
It is part of the product.
But the influence works in the opposite direction too.
Programming changed the way Maxim thinks about design.
Once you understand how software works, you start seeing pipelines everywhere.
Illustration itself is a pipeline.
Sketch.
Line.
Color.
Light.
Detail.
Each stage takes an input and produces an output.
Building software around workflows made Maxim more conscious of his own creative process as well.
What He's Building Next
Image Pipeline continues to evolve.
The emotion filter is planned for another version, this time driven by real data rather than matrices manually tuned until they looked right.
Maxim is also exploring Web Workers for client-side heavy lifting.
Outside the core product, he's thinking about another problem from his own workflow.
Processing images is only one part of preparing a portfolio.
Organizing, tagging, and exporting those images for different platforms is another task that still takes manual work.
That has led him toward the idea of a portfolio preparation tool.
Typography is another area he is interested in.
After fighting with fonts every day, he suspects other designers have similar frustrations.
The pattern remains the same.
Find a problem.
Understand it.
Build something.
Use it yourself.
Then see whether the problem exists for other people too.
Building From 0 to Revenue
Maxim's profile describes his current focus as growing Image Pipeline from 0 to revenue.
The product has already passed several milestones:
- Launched on Product Hunt
- Received a 5★ review on AlternativeTo
- Listed on Launch Llama
- Shipped 14 node types in six weeks
- Reached 46 passing tests
- Maintained zero backend image processing
But the product is still evolving.
That's important because Maxim isn't presenting the journey as finished.
He's still experimenting.
Still responding to users.
Still adding features.
Still questioning his technical decisions.
And still building for himself.
What Coding Changed About His Career
Maxim's story doesn't fit the traditional idea of a developer journey.
He has a formal engineering education.
He built a career in illustration.
Then he returned to software through a problem he personally experienced.
Today, he sits between several worlds:
Design.
Illustration.
Programming.
Product development.
Indie entrepreneurship.
That combination is what makes his journey particularly interesting.
His development experience didn't replace his creative background.
It extended it.
His design experience didn't disappear when he started coding.
It became part of how he builds software.
The Lesson: Build From Your Own Pain
There is a simple principle running through Maxim's entire journey.
The best product idea may already be sitting inside your own frustration.
For Maxim, it was processing hundreds of images.
For someone else, it might be a workflow at work, a repetitive task, a missing tool, or a problem nobody has bothered to solve properly.
You don't always need to start with a startup idea.
Sometimes you just need to notice the thing you keep doing manually.
Then ask:
Why am I still doing this?
That question took Maxim from Photoshop and Illustrator to JavaScript, React, Canvas, and eventually a product used by designers beyond his own workflow.
His own profile sums up the philosophy well:
"Ship when it's embarrassing, not when it's perfect."
But there's an important second half to that idea:
Fix the bugs users actually complain about.
That's perhaps the most practical lesson from Maxim's journey.
Build early. Listen carefully. Keep improving.
About Maxim Mitenkov
Maxim Mitenkov is a book-cover illustrator, engineer, and indie developer from Belarus.
He studied Computer Science and Radioelectronics at Belarusian State University of Informatics and Radioelectronics (BSUIR) from 1993 to 1998.
Today, Maxim is the solo founder of Image Pipeline, a browser-based batch image processor designed around privacy and client-side processing.
His technology stack includes:
- React
- TypeScript
- JavaScript
- HTML5 Canvas
- Tailwind CSS
- Vite
- Zustand
- Node.js
- Vercel
- Git
He is currently exploring Web Workers for client-side processing, emotion-driven image filters, and growing Image Pipeline from 0 to revenue.
He has launched Image Pipeline on Product Hunt, earned a 5★ AlternativeTo review, shipped 14 node types in six weeks, and built the product with zero backend image processing.
View Maxim's full CoderLegion profile:
https://coderlegion.com/user/Maxim Mitenkov
About This Developer Story
Developer: Maxim Mitenkov
Series: CoderLegion Developer Stories
Interview conducted and edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion
This Developer Story is based on Maxim Mitenkov's interview responses and his experience building software alongside his professional career as an illustrator.
