Today let's talk about pet projects and indie development.

As someone who has been juggling corporate work and somewhat profitable indie projects for many years ? my team lead salary in Germany and pet project income in 2024 are roughly equal , I often notice how newcomers struggle to get into their indie projects because their heads are cluttered with corporate thinking: Kubernetes, testing, frameworks, and other buzzwords from their day jobs.

Programmers who started their career in corporations find it hard to start writing indie stuff because they immediately fall into massive overthinking - they start creating problems that don't actually exist.

They've been drilled for years that these problems exist. That you always need to think about performance ? and God forbid you forget about Big-O notation :DDD , that you must always write tests, that life without Docker and Kubernetes is impossible, and CI/CD with fancy zero-downtime blue-green deployment is mandatory.

Meanwhile, some indie nomadlist goes BRRR, being just an index.php file, frontend in jQuery, SQLite database where JOINs aren't even used, and it all gets deployed through the magnificent drag-and-drop via FTP. And its author, Pieter Levels, makes $2.5 million a year from his indie projects. Solo. Pre-tax.

Or take any other indie project from Indiehackers.com or StarterStory.com with MRR of $5K+ per month. I guarantee you'll hear raging butthurt how can they do this and how do they make so much money on such crap!!11 echoing through the whole neighborhood.

Self-taught programmers who started as "indie", who are used to the "YOLO to Production" methodology and "Fail Fast, Learn Faster", conversely find it hard to fit into corporations.

Their armpit hair starts tingling when their team allocates six weeks of sprint time to repaint one button.

So why is this happening?

As someone who has experienced both sides firsthand, I can say: there's no "right" or "wrong" approach here. There are just two different worlds that you shouldn't mix up, and then everything will be fucking great.

Today's post is about exactly that.

Any company is a long-running mechanism whose main goal is the long-term survival of the entire system, not the beauty of its individual shiny gears.

Every new line of code you write at work should not just solve its task (any junior-middle dev can do that) - it should guarantee that the person who touches it after you won't break anything. And ideally, they should be able to understand it too.

For large corporations, it's normal when there's not a single person on the project who understands the system entirely. Almost always, the original author has either quit, switched projects, or got promoted.

That's why all these additional protection layers are needed - code review, testing, automated deployment, rollback, performance monitoring, and so on.

Just put yourself in a newcomer's shoes. Would you feel more comfortable ramping up on a project where everything is covered by tests, automatically builds, and warns about potential problems in advance, or in a typical "YOLO production" startup where everything falls apart like a house of cards if you touch it?

Exactly. That's why six weeks for a button.

In corporate, you don't write code "for yourself", but for that poor dude or dudette who will come after you. Otherwise, it's ass. Nobody likes those damn "artists" :)

And even I myself, as a team lead in corporate, watch over this. Because while I'm at work - I wear this hat, yes.

On the other hand, we have indie. You're alone. You're sitting at home in your underwear trying to code another SaaS to bring value to people, and ideally earn enough for a cheese platter.

In indie, you're your own founder, product manager, frontend dev, and backend dev. ? Here and further "indie" means any project made by one person, without investor money, without trying to make a "startup" and build a team - purely bootstrap stuff aiming for self-sustainability.

There won't be people "before" or "after" you. The main and only person who will ever see your code is future you. Even if you become super successful and sell the project, they'll be buying the company, not looking at the code.

In indie, your main task is to write code that YOU YOURSELF can fix a year later at 2 AM while drunk from your phone

The stack for a good indie project is the dumbest possible stack. So dumb that you should feel embarrassed about using this mammoth piece of crap.

Take my vas3k.club ($15K MRR) as an example - it's written in Django + Postgres + Redis + asyncio. I've been using all of this since the decade before last ? okay, back then it was tornado instead of asyncio and know it like the back of my hand. Wake me up in the middle of the night, and I'll migrate all your database models without even regaining consciousness.

Same story with deployment. At work, everything's naturally in kubernetes-schmubernetes, but even after five years of dealing with them, I still don't trust them enough to use at home. ? Your case might differ from mine. I'm telling you about my experience, and you can extrapolate to your own experience and draw analogies with technologies yourself.

For the first year, I deployed the Club using my familiar method - manually via SSH and pulling the old Soviet docker-compose down/pull/up. That's how it was in all my pet projects. The Club wasn't anything special back then.

In the second year, when I realized the project had taken off, I got tired of doing this manually every time, so I wrote a Github Action that did the same thing for me automatically on each commit to master.

Aaaaand, that's it.

Yes, it still works like that. On a project bringing in around $10K MRR per month. And this very blog has the same crap.

If I told this at any IT conference - they'd chase me off stage with mops and kick me backstage afterward.

But every time I tried to "use something more modern" - I spent more time fighting with the framework or compiler than actually solving the problem, which made me abandon the project before release. ? No, if you're making a pet project purely to learn TypeScript or Rust - that's totally legit. But if you have any plans to show it to people later - no. Don't do it.

As a counter-example, take Pepic - an image/video upload/proxy service that I use in four of my projects. Similar to imgproxy, but with upload capabilities.

Pepic is written in Go, which I supposedly know. But still, every time I need support for trendy AVIF or HEIC formats, it turns out that my library is outdated, needs a new one, but the new one can't do what the old one could, so I have to rewrite everything for at least a week because in Go everything "gets outdated" every year, just like in JS.

Total pain.

I could have written everything in "slow" Python (+Pillow) and put Nginx + Cloudflare as a static proxy in front to not stress Python. But no.

Even docker-compose was a "novelty" in my pet projects world three years ago. Before that, I really deployed everything through SSH + git pull. It took me about ten years to start truly trusting Docker and stop waking up at night from another disk space overflow or Out-of-Memory because I forgot to set up yet another fucking log rotation or call system prune somewhere.

If you're not sure your tool won't wake you up at night - don't take it. There's always a simpler tool.

Don't trust Docker - pull ./myapp.sh restart manually.

Not sure about the trendy database - take Postgres and don't try to be fancy.

Don't know backend - write everything in your Node.js and don't listen to "true backend devs".

Don't know git - upload files via FTP.

Even jQuery just had a major version release last week.

No project in the history of the world has ever died because it chose a too slow programming language, too old framework, or deployed code via SSH.

Most indie projects die because their authors simply burn out and give up on them. So the best way to delay this is to take the simplest building blocks and build everything from them, saving your mental energy for much more important things. Like the value your project brings to its users :)

Conway's Law briefly states that architecture always mirrors organizational structure.

If separate frontend, backend, and devops teams work on a project, there's a 100% chance they'll have three repositories - "frontend", "API", "infra".

Devops don't want to talk to developers, frontend devs don't want to touch backend, and as a result, even the simplest project in any company always looks like that old meme video about microservices.

Companies are convinced this is efficient. After all, if a fat full-stack dev quit before, you had to search the market for another fat dev and throw them a double pile of money to continue after the first one.

Now, if your frontend dev quits - you just open the window and there's definitely a couple more frontend devs hanging out on the bench outside. Convenient. Cheap.

Corporates like this. After all, their main goal is interchangeability.

However, this approach not only bloats company headcount but also leads to bloated applications.

Take SPAs for example.

SPAs have absolutely no benefits for the end user - it's pure sabotage against the modern web. The only reason everyone's building SPAs is that same Conway's Law with its cheap replacement of cogs.

I'm amazed how corporates managed to sell the idea of SPAs to the world. We had a browser that was fucking great at taking HTML and rendering it on your screen. After decades of evolution, browsers learned to do this so fast you can't even blink.

But no, someone came and said instead of giving the browser its beloved HTML, let's first load 12 megabytes of JavaScript, then make it grunt executing it on the spot, so that in the end the thoroughly exhausted browser realizes it now needs to hit 25 different REST endpoints, get 50 megabytes of JSONs (WHAT?), and theeeen try to crap it all onto the page in the right places while the user watches.

Everything's jumping, blinking, a dozen spinners spinning on the page, feels like you're at Cirque du Soleil.

The ringmaster is passed out drunk in a pile of NPM dependencies, nearby acrobats are reinventing URL/routing on the frontend, fucking clowns jumping around who invented CSS-in-JS. Literally early PHP vibes.

Then the main clown bursts onto the stage like - look what I came up with, let's render pages on the server. No, not like before. Worse. We'll show the button on screen, but won't let you click it yet because its handler in those 12 megabytes of client JavaScript hasn't loaded yet!

COOL I INVENTED??)))

The audience sits in shock wondering why they even came here. Waiting fifty seconds just to load one cookie banner. How's that for ya?

Well, you get the idea. Looking from the outside - it's all very bad. Don't copy these clowns. ? And no, I have no issues when SPA is actually an "application". Like a graphics editor or Excel in the browser. But damn, now even Reddit, a freaking feed with pictures, is also SPA =/

So in indie, none of this exists. No Conway, no "teams", no areas of responsibility, no staff turnover. You're alone. And this simply eliminates 90% of your problems.

Indie folks can whip up in a week what a corporate would take six months to birth. Simply because they have no communication overhead. Indie is always monolithic, and monolith is the most efficient structure.

However, monoliths are contraindicated for "teams" - because a monolith implies that each team member understands everything happening inside. And that doesn't happen in corporates, which is why they hate monoliths so much, and about 9 out of 10 articles on the internet will be about why monoliths are bad.

But in indie you're alone, which means you know everything by default. That's the power of indie. It's what allows you to outrun sluggish corporates.

However, you have a problem - 99% of tutorials on the internet are written by corporate folks. If you try to ask for advice in professional communities, they'll look at you like you're mentally ill.

Let me tell you my story.

When I was just starting to write the vas3k.club engine, I immediately decided I didn't want an SPA. It's just a regular collective blog where most things are standard for any browser, I just wanted "a bit more interactivity" like clickable tags and other stuff that grandpas used to call "AJAX" ? uh smells like mothballs .

I was quite dumb then and thoughtlessly asked the internet for advice on "which JavaScript framework would you recommend for a simple blog". For which, of course, all the true frontend devs dumped a pile of crap down my collar, after which I realized I'd walked into the wrong neighborhood :)

I made a second approach. I took GitHub's website as an example of what I wanted. A set of regular HTML pages that load quickly, are indexed by search engines, but which SOMETIMES have interactive elements like likes, context popups, and form autocompletion.

Then I went looking if you could make such "partially-interactive" sites with the popular React or Vue at the time.

I mean, in theory, you could take React and instead of initializing the whole page through it, just create a new React instance for each like button on the page, right? Who's gonna stop me?

Turns out in modern frontend that gets you 10 to 15 years of strict regime.

You can't do that.

Just can't.

No.

Absolutely all frontend devs told me I don't understand anything about programming and that I should stay away from their territory with such ideas.

I don't remember how, but I found literally one article on the internet ? which I've already lost where someone managed to make Django (which is purely-oldschool-backend framework) + Webpack + Vue.js work together exactly this way. Django rendered honest HTML, and then Vue loaded onto the page and initialized separate interactive elements.

I didn't know Vue then, but all these hipster frameworks take about an hour to learn, so this was a real victory! It did exactly what I wanted. Since then, the Club's been on Vue :)

I'm happy with everything except for one small problem: since our engine is open source, sometimes frontend devs who "want to fix a bug" stumble upon it. And out of a hundred willing contributors, there was about one who didn't run away in horror from the fact that I don't have an SPA there, but this kind of hybrid.

But I don't really care about that. It's indie after all :)

Since then, I've been watching new frontend libraries for several years, trying to find the one that would popularize this strange style of mine.

And I think I found it a couple of years ago - HTMX.

It essentially continues what Basecamp started with their HotWire - when instead of JSONs you send ready HTML to the browser and just brazenly insert it in the right place.

Frontend devs will fiercely hate me for such tricks, just like they hate the library's author. But yeah, turns out you can do that :)

So when I was updating this very blog where you're reading this text, I tried using only HTMX for all interactive elements like likes and comment submissions for the first time.

And you know what? It's fucking great. If I were starting vas3k.club today, I'd take HTMX right away and forget about everything else. Vanilla JS for widgets and that's it.

Yes, because I'm a backend dev, but remember the previous point. The dumber your stack - the more likely you are to complete the project and not burn out.

I'm a CEO of HTMX!!!

In modern tech, there are literally just a few companies that achieved success purely through self-sustainability from day one without attracting crazy investor money for "growth acceleration."

And investors always want one thing. Even if a company can comfortably sustain itself and build new products at its own pace, investors will demand squeezing 10x, 100x, 1000x from existing ones, just to multiply their investments.

Both the dot-com bubble and the current tech crisis essentially resulted from injecting huge amounts of VC money and the panic that followed.

That's why any corporate software always undergoes enshittification. When instead of focusing on the product and user problems, the company at some point switches exclusively to milking money from its users.

What stopped Dropbox from just remaining a convenient file storage without breaking old features in favor of new paid ones, or Reddit from being an open global community platform without declaring war on third-party clients and their own moderators?

Investors.

Poor companies develop bipolar disorder because, on one hand, they can't change anything to avoid breaking their business model, but on the other hand, they urgently need to change something to start earning even more.

This is where all these "changes without changes" begin, when everyone endlessly moves to new frameworks, invents the third design system of the year, implements OKRs and other things nobody asked for.

This is where small and nimble indies, who don't need any of this, can cut them off at the turn.

In an indie project, you start with exactly zero money. If you have enough for food, that's fine. You have nothing to lose. You have no one to answer to.

That's why the goal of any indie is to find a real problem and solve it in a way that neither Google, nor TikTok bloggers, nor corporates with their ERPs, nor anyone else in the world has solved it yet.

And then people will want to bring you money.

People bring money when your service saved them more energy than they would spend earning that money

You don't need to search for a previously unsolved world problem. All modern corporate-written software is so bad that if you just make one single feature, but in one click and without a "cloud" subscription - people will already be grateful and bring you money.

And even a small amount of money by corporate standards is enough for an indie dev to support themselves, their family, and pay the mortgage. They don't need to show 10x growth to investors at the end of the quarter - for survival, they just need a cheese plate and paid electricity bills. And then they can keep building more.

That's why indie projects might seem so dumb from the outside. "A phone alarm app that correlates your calendar with your dog's pooping schedule and then recommends you the perfect time for walks" - can bring its indie author tens of thousands of bucks per month. Yes, people could adapt Google Calendar for this, but they're not idiots.

This is your indie strength again. ? For example, the last indie app I personally bought did just one thing - it allowed setting the touchpad scroll direction on a MacBook separately from the mouse scroll direction. Yes, fuck, apparently you can't do this in Mac settings anymore! Here's a dollar, kind person from Reddit who solved my pain with one click.

And this again dictates our approach and stack. If you have 0 users, does your app need a fancy testing framework? Dark theme? Password recovery form, even?

Here's a secret: most of your indie projects will die before reaching this necessity.

Does a service that gets three visitors per day need seamless deployment? Probably not, lying down for 30 seconds while docker-compose restart runs isn't a big deal.

0 users - that's your problem. That's what you need to focus on. And throw all other overdesign out of your head.

In indie, you can do things that are unavailable to corporates

Take the simplest idea of a direct Telegram chat with the project founder, where anyone can request a new feature or report a bug. No FAANG can afford this because they have too serious faces and too many users.

But for an indie project, this can become a turning point when people think "wow, that's so cool, they answered my questions and fixed my bug, I'll go give these guys my hundred bucks for development".

The same goes for interface jokes or, for example, you have a GitHub bug tracker where you set up a bot that allows people to put real money for their feature to be implemented. And when the feature is worth it and you've made it - the bot automatically credits you with all donations collected for the implementation. Isn't that cool? No Facebook can do that.

Long time ago (in 2018) I even wrote about this phenomenon in a newsletter about "Craftiness - the secret of success", where I explained that in the modern world of Chinese copies, people are attracted to projects made with real hands, love and soul, even if they're not perfect. Still works.

In 2024, cyberpunk is already in full swing and major tech corporations don't even try to pretend to be "nice" anymore, doing blatant crap. Against this background, small and human-oriented indie, on the contrary, seems like a breath of fresh air and gives hope.

So if you still have 0 users and $0 MRR, then each time ask yourself - if I spend a week on X now, will it bring me at least $1, or am I doing this because "that's how it should be" and "well, books said that without X everything will break"?

And then the answer will become obvious.

The goal of this post wasn't to humiliate corporations but to show that even in modern tech there are still lots of opportunities for indie if they don't try to blindly do everything "like the big ones". During crisis, the industry gets even more skewed and more new paths open up for indie folks because people start respecting corporations less and less.

Of course, all this dichotomy can be considered conditional. Extremes are useful to highlight nuances, but in real life you'll always have a mix.

Even in my life, there were at least two examples when at work I was given carte blanche to launch a project in "indie" mode. Just to test the concept and decide if it's needed.

Indies also come in different forms. Sometimes you really can't afford to lie down for half a day with a 500 error if you're solving a time-sensitive problem.

Speaking in systems thinking language - always look at the system above that's directly above your code. Let it dictate your constraints, not because "that's how the industry does it" and "well, you can't do it differently".

Why can't you? Who says you can't?