DEV Community: Valeria

Agentic Development Survival Guide

Valeria — Thu, 16 Jul 2026 11:58:45 +0000

When was the last time when you were in the state of flow? Where hours passed by unnoticed as you were deeply focused on solving a tricky problem. I don't remember mine. I remember how it felt, I remember there were many, but which one was the last one I can't recall.

Endless rounds of layoffs, uncertain economic conditions, and the darn pressure to use more AI has been wreaking havoc to professional identity of myself, my team, my friends, my colleagues and strangers on the internet. So I know I'm not alone in this.

This article is my attempt to summarize my own coping strategies and turn it into a practical guide opinionated enough to be actionable and flexible enough to work for others. I can't help it - I'm an engineer, I don't like dwelling on problems especially when the solution is within my reach.

AI is Yet another automation tool

First thing first, we really need to talk about what AI is and what it is not. It is not magic, it is not consciousness and it is not a mythical ethereal power. It is a giant statistical model that is taught to predict the next token in a sequence.

The human brain has an estimated 100–500 trillion synaptic connections. Claude Mythos is rumored to carry around 10 trillion parameters, and while comparing a parameter to a synapse would give a neuroscientist an ick, the numbers are still humbling. A macaque's neocortex alone contains roughly 1.25 trillion synaptic connections. And, unlike Mythos, the macaque runs all that on fruits, seeds, leaves, and flowers.

Don't get me wrong, it is very impressive that AI came that far. But that's not even close to match a human in both capacity and efficiency.

So let's agree that AI is just a tool that we can choose to use to automate some of human tasks.

The Golden Rule of Automation

With that out of the way, let's look at what we already know about automation. If you search "The Golden Rule of Automation" you'll find a few different versions of it: "We must make deliberate decisions about how, when, where, and why to automate" or "Simplify and standardize processes before you automate them" or, my personal favourite, "Never automate a process you haven't done manually at least X times".

Mind you, these are the rules that allowed us to mass produce food, shelter and clothing. But the process of industrialization hasn't eliminated manual labor in developed countries entirely - it made it a choice.

With that said, you have probably guessed that step 0 in this guide is to shift the mindset from catching up with AI to grabbing the reins back. We could talk more about who and why promoted the AI superiority mindset, but I think Hanlon's Razor gives enough of an explanation, so let's dive into the solution instead.

Observe the process

The first step to automating a process is to observe it. As counterintuitively as it may seem, I would like to suggest that you set all AI tooling aside and try to implement something old-school. But in this case the purpose is not to abandon your favourite agentic harness entirely, but to note which parts of the process are genuinely a hurdle before automating it.

It can be something small, a side-project or a feature. Pick something that you are more or less comfortable with. If you've been relying on AI for development for a long time it will feel weird at first. But don't worry, it's like riding a bike.

If it helps - think about it as an AI detox, not permanent withdrawal.

Keep a note on the side - a paper one or a digital and whenever you feel stuck or annoyed - write it down.

It can be anything from "Forgot which command to run and needed to look it up in the code" to "The code structure fills me with dread and feels illogical". It doesn't matter how (ir)rational or (un)common your hurdles are, even if you're somehow the only one in 8 billions facing them, so don't judge or worry about solving them just yet. Fix if it's something small, otherwise just note and keep going.

Repeat the process a few times, keep taking notes and observe emerging patterns.

Refactor

With data in hand, you can now identify potential improvements. And I bet that the majority of them could be fixed with a refactoring. Move files around, decouple functions, clean up unused code, rewrite confusing bits, change tooling to a better one.

It is generally a good idea to spend between 20% and 50% of your time doing that. For starters, you can adopt the same observe-note-fix steps while working on a feature or task, but with time you'll be able to weave it into your regular workflow in a more natural way.

It doesn't matter how much or how little AI you're using in your development - your developer experience matters the same. And, subsequently, what is good for your DevX would make it easier for agents too.

Gradually introduce AI agents

Speaking of agents, I also bet you'll miss them during your observation/detox phase and hopefully you'd note when that happens. These are the parts you probably give back to agents first.

From my experience, there are a few tasks that are generally safe (for your flow and sanity) to involve agents early on.

Fill-in-the-Blanks

LLMs excel at predicting the next token. You don't even need a huge model for that, in fact tiny FIM (fill-in-the-middle) models that you'd find in IDEs autocomplete functionality are often so cheap to run you get them for free.

And hey if autocomplete covers all your AI needs and you feel productive and happy - maybe that's how the perfect flow looks for you right now. Being curious about technical advancements and trying things out is what's needed to stay relevant. Adopting a workflow, even a hyped one, that diminishes your abilities is not.

The same approach can be applied to LLMs, if you'd like a bit more AI in your flow.

Here are a few steps to try and see how it works for you:

Write types and/or interfaces for a small slice of functionality
Create a test file and write only titles for the tests you'd like to write
Ask your favourite coding agent to write the tests and functionality

And if it sounds familiar it's because it is the infamous test-driven development in a nutshell.

I don't follow the purist red-green-refactor loop. I write tests and code pretty much at the same time. And from my experience, there's no reason to force agents to do it differently. But I do prefer having tests over elaborate documentation.

Think about the development flow the same way you think about unit tests: the task for the agent needs to have one clear, well-defined purpose that should be easy for you to validate.

And while reviewing the agent's output might seem like the most straightforward way to do so, it is extremely tedious and I'd recommend building linter rules and static checks into the codebase before subjecting yourself to this torture. Unless you absolutely enjoy reviewing code written by someone else, of course. I do not.

Brainstorming

What I do enjoy doing is brainstorming a solution! Before chat bots I used to do that with a pen and paper and occasional thinking partner. Nowadays, AI becomes this thinking partner more often than I'd like it to be.

It's not that the world changed when AI became capable of maintaining a conversation. Facebook, Reddit and your run-of-the-mill Google search could yield plenty of delusional ideas and fabricated facts. But a post is not personal, it doesn't adapt to your situation and as much harm as it does - it doesn't become an echo chamber.

AI, unfortunately, can. So fair warning, if you feel isolated and have limited contact with other people and risk of developing delusions, please talk to your healthcare provider before using AI as your thinking partner in any capacity.

For general use, I find the "quiz me" approach the safest for brainstorming and the prompt for it looks something like this:

I am exploring <topic>. Ask me one question at a time to help me with <outcome>.

This way your thinking is still your own, AI can make suggestions, but you hold the decision power. Including the decision to shut down the darn thing and go back to pen and paper.

More Power - More Guardrails

Speaking of power, when it comes to finding the right balance between human and AI driven development, the crucial concept to keep in mind is that the more autonomous you let the AI be the stricter should be the guardrails.

And regardless of how much or how little AI you end up using, you don't want to rely on a document, verbal agreement or someone else's opinion to keep things under control.

The exact implementation of these guardrails will vary depending on the specific use case, the tools available and your personal preferences and way of working.

Here are the rules I follow that might or might not work for you:

Greenfield codebase should be setup by a human.
Core context should be written by a human.
AI should never be given more context than they need to complete a task.
Strategic thinking (brainstorming, planning, architecting) and implementation should never happen in the same session.
Deterministic checks > human review > AI review > no review.

There are multiple workflows that would follow these rules, including the ones where no AI is involved in the process. And if that is what works best for you, then there is no reason to change that.

It is also possible to setup a workflow where AI is doing most of the work, but it requires mature codebase and a very experienced developer who is comfortable with that way of working.

And all of that starts with somewhat selfish process of improving your own daily work first.

I became a developer because I fell in love with the process of turning words into digital worlds.
I stayed because I enjoy solving other people's problems.
I can do that with a lot of different tools, languages and frameworks.

AI is just one of many.

How to come up with a passion project

Valeria — Tue, 30 Jun 2026 05:53:17 +0000

"You can measure your worth by your dedication to your path, not by your successes or failures."
-- Elizabeth Gilbert, Big Magic: Creative Living Beyond Fear

I can't argue that Elizabeth Gilbert knows a thing or two about passion projects, after all she has written quite a few books, including her well-known memoir "Eat, pray, love". But what I will argue with is where ideas come from.

She describes ideas as disembodied energy forms that are floating around in the search for a human partner that would bring them to life. As romantic as it is, I think it's about time we, humans, took accountability for our own ideas instead of claiming that some mythical creatures hit us with them.

The way I see it - an idea is a result of creative thinking. Our senses supply us with enourmous amount of information all the time and our brains are trying to catch up and make sense of it all. We try and match new information with the patterns we already know and get quite stressed when we are met with something entirely new.

And we get quite pleased when we encounter something that matches one of our favourite patterns. So pleased, that we dedicate our time generously to whoever or whatever keeps matching these patterns and call them passion projects.

How to come up with an idea for a passion project

Based on the interviews I've had with software creators who successfully kept their passion projects alive for years and my own experience, the secret recipe to coming up with a creative idea includes only two ingredients:

Deep personal connection to a problem or a domain (a.k.a. passion)
Intentional limitations

Find where your passion lies

A common advice is to look around you, but I find it much more effective to search for ideas in the past experiences first. Find a quite place and ask yourself:

When was the last time I felt alive and excited?
What was I doing then? Where and with whom?
Can I think of any other time when I was in a similar situation and was just as excited?

It is very important to not judge any ideas you'll get just yet. Nothing is too silly or too ambitious at this point. Just take note of what comes and keep an open mind. The goal here is to narrow the problem and domain space for your passion project, not to get all the answers.

When you have a potential candidate - something you were excited about in the past, imagine yourself doing it again. Do you still feel excited about it?

Spend as much time as you need, explore different scenarios and try them on.
And when you notice that you're circling the same space over and over again - then you know you're close.

Here's an example:

Let's say you were thinking about all the places you visited in your travels; and those memories filled you with joy and excitement. You remembered the people you met, the places you saw, the food you tasted or the adventures you had. And the thought of dropping it all and going on a year long trip around the world makes you happy.

Or, like it would be in my case, you would be coming back to the feeling of flow when you were building a software project and the feeling of joy of solving problems with it. Or that time when the server crashed and someone complained about it (because that meant that they were using it!). As opposed to the thought of travelling - that would make me slightly bored and annoyed - the thought of spending my vacation in front of a laptop creating tiny digital worlds fills me with joy.

It can be anything really. As Robert C. Martin wrote in his manifesto "We, the Unoffended":

(We) Believe that, in order for the best ideas to rise to the top, all ideas must be heard and evaluated on their merits...(and) Believe that ideas are not harmful, so long as they do not specifically incite harmful actions.

So explore, dream and let yourself call all the shots.

Distill into an idea

Knowing what you are passionate about is the most important prerequisite for a passion project, but it still isn't an actionable idea yet. So far it's just a vague area and a feeling. And one that is quite disconnected from reality still.

So, when you've settled onto an area you're passionate about, start intentionally limiting the scope and grounding the project. Ask yourself:

What am I already good at that could help me in this area?
What would I enjoy learning?
What would I absolutely hate doing?

Feel free to go into as many details as you'd like: think about tooling, colors, concepts and anything else. The goal is to make the project idea a little bit more concrete, layer by layer.

You can, of course keep it theoretical, if you prefer, but I find it most efficient to jump into something tiny and try it out. No commitment yet, just a quick one evening or weekend experiment that you're ready to throw away.

There's no saying how much time the whole "coming up with a passion project" process would take: you might loose interest or discover something that would prevent you from continuing working on the project and you'll go back to the drawing board. This is a normal part of the process. And it is very important that you give yourself freedom to explore and experiment before you announce your commitment to the world.

Creative cocoon

The younger the project, the more malleable it is. In the very beginning you still don't know if it would work out or not. You only know that you're interested in it right now, not that you're going to stay interested.

Think about it like if it were a flirting stage of a relationship: you like what you see, but you don't know enough about the other person to make a lifetime commitment yet. Flirt with your prototype, flirt with a few of them, don't introduce them to your friends or family just yet and most certainly don't put it on your social media profile.

You want to be able to give yourself time to understand what is important to you and to explore without the pressure. You'll see that some projects might require more of you than you can give, some would turn out to be way less rewarding than you hoped for and that's okay.

I like to call this early stage a "creative cocoon". This is a very vulnerable stage of the project when it transforms rapidly and wildly. This is the time where you figure out your needs and build a relationship with your project. And not every idea would survive this stage.

Inevitably, you will end up with a project that you'll be coming back to over and over again. And you won't be interested in exploring other options.

Do NOT build in public just yet

Even when you land on the project that you're ready to commit to, resist the temptation to share it with the world until it is ready, as controversial as it might sound.

It's perfectly normal to want to make a living doing what you love. And it is tempting to try and see if this particular project would be the one that allows that for you. And it might, but in order for you to be able to convince others that your project is worth spending money on - you need to have an unshakeable belief in it.

A few years back writing software was taking way more time, so it made sense to try and see if someone would use it before you spend years and months on a project. LLMs made MVPs a commodity. And with the amount of sloppy almost-working project out there, I think it's about time we refine our projects for a little longer before unleashing them into the world.

But you still have to have someone use the project to be able to iterate on it, so I suggest that someone would be... you. Obsess about your needs and usage patterns, iterate on your own feedback and get to a stage where you are excited to use your project just as much as you are excited to build it.

You shouldn't feel guilty for building something just for yourself. You don't own the world your every thought, idea and project. And not every thought, idea of project would be a good fit for the rest of the world either.

Worst case scenario: you'll end up with something that makes your life easier and a ton of knowledge.

Whereas if you let other people's ideas and opinions influence your passion project when your vision is still maturing, you'll end up with a Frankenstein monster of lifeless and unfit body parts of someone else's dreams.

But it'll also be a waste to keep your beautiful creation locked away for too long.
So how do you know when the time is right?

Passion Project Lifecycle

In a nutshell, you want to go through a loop similar to the one below:

The more cycles you go through, the more refined your next iteration would be.
The goal, as you can see, is not to get the project right in one go, but to be able to iterate on it indefinitely and keep the passion alive.

And only when you feel like you have a solid understanding of what your project is and what it would never be - then you are ready to listen to feedback from others.

Not every external idea would be good, not every suggestion is worth implementing.
The more picky you are, the better the resulting project would be.

And, just like it was with your own ideas, you want to listen to feedback coming from people who use your product often and almost religiously. And until you have these people, it's best to draw inspiration from people who use similar products than your friends or family.

Sometimes you would end up with a project that might be too niche or too hard to scale to a larger audience.
And that's okay - depending on why you started the project in the first place it might be perfectly fine to leave it as is and keep enjoying your time together.

It's also perfectly fine to want to make money out of it.
Though I'd recommend to use a slightly different set of metrics than revenue to define the project's success, especially early on.

How does a successful passion project look like?

In the beginning, you want to end up with a project that you enjoy using, love working on and can keep doing that indefinitely. So at this stage success metrics are how often you use whatever you're building and how often you find time and will to work on it.

If you want a fancy name for it, let's call it:

Dogfooding Rate - the amount of days you actively used your project divided by the total number of days in the period (e.g. once a month 1/30 = 0.033 active usage rate or 3.3%)
Change Frequency - how many new versions you "released" during the same period (e.g. twice a month 2/30 = 0.067 change frequency or 6.7%)

The closer both of these metrics are to 1, or 100%, the better.

As with any infatuation, in the beginning you might spend a lot of time at it and then settle into something more sustainable, so it's important to give yourself at least a month or two before you jump to any conclusions. The trajectory over time is what matters most.

If after the initial "honeymoon" you're still happy to spend time on your passion project and you've settled into a sustainable routine - it's going in the right direction. Don't rush it, the inspiration is not going to dissipate as long as you are engaging with your project.

But you might get discouraged and disappointed if you open up for feedback a bit too early. And that would be a shame, because often it says less about your product and more about people giving the feedback.

It is just a matter of time till you land on a passion project that would become your life's work. Or a few of these. Just like it is with human relationships - we're not limited to only one passion in life, unless we choose to do so. And, inevitably, if you choose to share it, you'll end up with other people using it with the same joy and enthusiasm as you.

They will be just as invested and will contribute their limited resources like time, energy and money to support you.

Because both you and them will know that you mean business and wouldn't abandon the project when the next shiny idea tries to seduce you.

Great Little Software: Crit - Your Feedback Loop with the Agent

Valeria — Wed, 24 Jun 2026 08:00:00 +0000

I want it to be lean - it should work with YOU. It works with your IDE, it works with your issue tracker, it doesn't try to change how you work, it just makes it easy to provide feedback and iterate on the output.
-- Tomasz Tomczyk

Just some years ago we, software developers, were fighting holywars on React vs. Vue vs. Angular, JavaScript vs TypeScript, Chrome vs Firefox and countless others. I can't say the battles have died out, but nothing, in my opinion, compares to the epic confrontation of AI vs no-AI camps.

On one side of the fence we have people who claim to be the evolution, intentionally atrophying their ability to produce code by hand and using their AI provider bills as a measuring stick. On the other, we have people who deny AI advancements and brand anyone using LLMs a heretic. This article is for neither. It is for the folks in between, who, just like me, are trying to find a footing in the new reality.

And I think Tomasz Tomczyk, creator of Crit, has a good amount of insight to share on the matter.

LGTM = TLDR

"I use AI to generate plans a lot - and reviewing those in the terminal was painful," shared Tomasz. "It's hard leaving granular comments (e.g. 'for X workflow, change A & B...') - it would take a lot of scrolling up and down, copy pasting, writing comments. Accidentally hitting enter would send it before I was actually finished. Speaking to peers, they had similar experiences - and often resolve to approving plans without reading them thoroughly and seeing subpar results."

Indeed, AI generates a lot of code and fast, definitely a lot faster than a human can read, let alone understand.
I too often resorted to blind vibecoding (and then throwing the whole project away) just because reviewing that amount of slop was too much work. And yet writing code entirely by hand felt like refusing to accept autocomplete and linters and going back to the embarrassing early days when I thought that real developers should only use Notepad.

Instead of jumping between two extremes, Tomasz seem to have been determined to find the middle ground. On February 16, 2026, he pushed this commit:

Single-binary Go CLI for reviewing markdown files with inline comments.
Browser-based UI with GitHub PR-style commenting, syntax highlighting,
mermaid diagram support, dark/light themes, and real-time .review.md output.

And that was the beginning of Crit, though for a few hours it has been called "PlanReviewer".

"Vibecoded" go-to tool

Crit quickly became a go-to tool for Tomasz himself, his friends and colleagues, and started to spread. At the moment of writing this article, Crit repository has almost 500 stars on GitHub, just four months after its conception.

It's worth noting that Tomasz, while having over two decades of engineering experience under the belt, in his daily work wields Elixir, not Go. In the interview he gave to the "Cup o' Go" podcast hosts he honestly said that he went with Go because that's what the coding agent recommended for CLI. He didn't know Go at all. Yes, his tool was so good, that he got invited to talk about it on a podcast dedicated to Go developers regardless.

So what's the secret?

In its creator's own words: "Once this workflow became my day to day driver, I wanted to mimic it for other parts of my job: reviewing code, reviewing running site. Turns out it's a very transferable UX/DX, commenting on plans, code diffs, dev site. Point and click, leave a comment, iterate. It became fun again and allowed me to improve what the output looked like without making me hate the process."

From my point of view, Crit was able to offer developers something very valuable: the way to go back to the flow - a magical state of ultra productivity and creative joy that has been fractured for many ever since the advent of AI agents.

AI != Easy

Writing code has never been easier, but agents can get you only this far. To quote Tomasz: "AI-driven development gets you 80% of the way very quickly and it looks impressive, but that last 20% is extremely crucial for good UX." It's one thing to spin up a prototype - a refined product requires a lot of iterations with or without AI.

And while Tomasz trusted code generation and stack choices to the agents, product philosophy and vision belonged entirely to the human behind the wheel:

The main thing I'm being pushy on is the DX: I don't want to remember many commands (/crit is a context-aware skill) and I want it to be lean - it should work with YOU. It works with your IDE, it works with your issue tracker, it doesn't try to change how you work, it just makes it easy to provide feedback and iterate on the output.

Crit supports pretty much any agent you can think of and for the outliers, like myself, it has an easy step-by-step tutorial to how to port it to anything else.

The Future

When I asked Tomasz about what he would like to achieve with the project, he said that even if the project stays as it is - he wouldn't mind it because the fact that his creation is used daily and loved is already a huge success. Of course, it doesn't mean that he can't dream big!

Looking back, Tomasz says that he'd consider more elaborate frameworks if he'd do it all over again: "What started as a simple app for reviewing just plans now functions in 4 different review modes and with a multiplayer option on the web. My agents are still telling me it's fine though!"

And they are absolutely right! But even they can't tell what the future holds. Tomasz dreams of Crit becoming the GitHub of plans: a place where teams are sharing, reviewing and iterating on product requirement documents, architecture decision records, specifications and so on.

"For the local app," he adds, "I'd be interested in exploring a world where it's more of a kanban style work orchestrator, kinda like https://www.conductor.build/, but it'd be a huge scope increase so not sure about it!"

I admire Tomasz's ability to keep himself grounded in reality and to not accept the status quo.
Give Crit a try, see if it fits into your workflow.
It's a great little software.

EvilCorp Syndrome

Valeria — Fri, 12 Jun 2026 13:33:23 +0000

An essay on sales, marketing and better ways to do it...

We can never make anyone do anything against their will without enormous consequences.
-- Marshall B. Rosenberg

I know a person who is generally very caring, reasonable and empathetic, but when they need to sell something to someone, be it an idea, a product, or a service, they tend to turn on the "EvilCorp" mode, as their team calls it.
A slight exaggeration here, a little lie there, a slight coercion and a tiny bit of selfishness. Nothing fancy, nothing criminal, but it does leave an aftertaste.

And I know another one. They're balanced and calm and are a great listener. They have valuable insights to share and I do believe they genuinely want to help others. But they also have a tendency to say "I don't intend to turn it into a pitch" and proceed to do just that regardless.

Seth Godin, renowned author of "This is Marketing", said: "It's not an accident that people who have been hustled, pressured, tricked and abused by marketers aren't fans of the profession.".

And, based on my personal experience, a lot of us, builders, engineers and creators share this sentiment.

Am I bad at marketing or am I simply a good person?

As a rule of thumb, people who say "I'm bad at selling" turn out to be bad at lying, coercing and being selfish. So for me that is generally a "green flag" and an indication that we're about to have a wholesome interaction.

I think one of the most undervalued quotes about marketing comes from a place you wouldn't expect - a questionable movie "Fifty Shades of Grey", where Christian Grey (played by Jamie Dornan) says: "Business is about people, and I've always been good at people. What motivates them. What inspires them." explaining his incredible fortune.

I understand why you'd be hesitant to take on this source as a reputable one, but Seth Godin agrees with it, saying that "Marketing is the generous act of helping someone solve a problem. Their problem.".

The problem is that understanding the problem, the underlying unmet needs and seeing past what people say is hard and takes a lot of time and effort. And often we're not patient or skilled enough to do things the right way.

And it is partly because we see some "succeed" through scheming and machinations and thus jump to the conclusion that this is the only way.

It's not. More than that, it's not even a way.

Let me show you why with some examples.

To infinity and beyond

The first assumption that one needs to make to be able to properly violate other people is to convince oneself that they're not people. That whatever is being done is done to a faceless mass, a general number, not individuals. We are born with a certain failsafe mechanism in place that prevents us from harming each other unless we have to protect ourselves. At least that is my understanding of the claim Marshall B. Rosenberg makes in one of my favourite books: "Non-violent communication: the language of life".

So for us to hurt someone with premeditation we'd need to first coerce ourselves to believe that we're doing the right thing.

And the easiest way to do so is to focus on metrics: it's not 200 human beings suffering anymore, it's 200 users. It's just a number. And the number is, by definition, infinite.

From this perspective, it is very easy to assume that there's an infinite amount of users and disregard the loss of them. Generally speaking there's a limited amount of time you can fool an individual, sooner or later all of us realise that they're being manipulated. But if you believe that there is an infinite source of people to manipulate - you wouldn't see any problem with prioritising immediate benefit over long-term gain.

But people aren't infinite. There's a very finite number of roughly 8.3 billion on this planet. You'll ever reach a fraction of that number and if one is set on burning through their trust - it is just a matter of time till the source is exhausted. And since people who are lacking empathy often tend to be quite greedy (something has to fill the unmet needs after all) - the burn rate tends to accelerate rather quickly too.

It might take years or decades, but it's never the right way.
And in today's world people are exhausted, making it almost impossible to gain traction this way, let alone sustain it.

Selling like pies

In the book "Traction" Gabriel Wienberg states that every source of customer acquisition is bound to exhaust eventually. I do not agree with that. There are a few that never get old.

A baker will almost always rely on the smell and look of their pies to attract customers. A bistro restaurant would start sautéing onions and garlic whenever their seats are empty. That has worked for hundreds of years, as far as we know.

There's no coercion in it - aside from worries about my weight I most certainly enjoy being sold pastries or going to my favourite cafe for a fika. It's a tiny cafe called Manufaktura, just outside Täby Centrum in Stockholm, that sells amazing pies, sandwiches and, for my dieting days, a very tasty cup of yoghurt with fruits, seeds and honey. The owner there is a woman with warm eyes, full of life and genuine desire to help. One time, during my low-carb diet that didn't really work - she made me a sugar-free yoghurt cup and gave me some advice on what I can mix quickly at home. And she didn't bat an eye the next day when I was buying a pie.

This cafe is almost never empty.

We only go to other cafes when this one is closed or full.

So can we apply this to the great little software we build?

Free as in freedom, not as beer

First of all, I bet you have never been to a cafe where all food and drinks were free all the time. Maybe you bought an "all-inclusive" resort hotel or paid for "all you can eat" buffet. But it was never totally free and I also bet that you didn't find it revolting.

We tend to fall into the fallacy that because the software distribution costs next to nothing, that the cost of software itself is nothing. But it still requires your time and effort. And a great software, that will be missed if it's gone, requires a lot of that. And that at the very least requires your electricity and internet bill to be paid, a roof over your head and something in the fridge to eat.

It takes time to make a venture profitable, but the costs should always be considered and accounted for.

Seth Godin says that "Low price is the last refuge of a marketer who has run out of generous ideas.".
Just like you, I consider inflated margins extortion, more so, I am convinced that a lot of problems we see today are because a person didn't know when enough is enough. So it's not about keeping your prices high. It's about the balance.

Rocky Leon, in his amazing song "Billionaire" that I tend to listen to on repeat when I'm particularly angry at EvilCorp representatives, sings: "Do you really think that anyone deserves more than like 50 grand a month?" and makes a few explicit suggestions of what to do with those who disagree. He has a point. Confirmed by the 2010 Study by Nobel laureates Daniel Kahneman and Angus Deaton who found that emotional well-being plateaued at roughly $110000 a year adjusted to modern inflation. The idea has been challenged a few times and I find Rocky's number more reliable, but the consensus remains that after a certain point there are diminishing returns to how much joy and happiness money can bring.

So find that magic number for you: approximate how much money you need to have your needs met, add 20% to it and calculate the price for your services. And revisit it every once in a while. Because when your needs aren't met, there's a risk you too would turn into a victim of the EvilCorp syndrome without ever meaning to.

And the world needs less of that.

SOAC

Now that you know how much your software pies should cost, you need to make it worth every penny and more.

Forget MVPs. Undercooked pies that are empty inside are not what we're going for. Instead, I suggest we embrace Jason Cohen's SLC approach: simple, lovable, complete.

Or, since "Lovable" has been somewhat misused, perhaps we should call it "Simple, Obviously Awesome, Complete" instead? Borrowing the middle bit from April Dunford's brilliant book on product positioning.

The cafe I told you about is small and simple:

But it has everything you need to have a great "fika". And the owner made it so cozy and welcoming - obviously awesome.

This is the bar.

The Kaizen of Great Little Software

Don't like SOAC? Draw inspiration from Gene Kim's "The Unicorn Project" novel and its five ideals of DevOps:

Locality and Simplicity
Focus, Flow and Joy
Improvement of Daily Work
Psychological Safety
Customer Focus

Who didn't invent it either, but enhanced The Toyota Way built on the idea of kaizen - continuous improvement for the better.

Pick and choose, mix and match - in the end it's all about placing the software you're proud of in front of people in need without tricking them into wanting it.

And there are plenty of successful businesses that do just that.
But because those businesses don't have an ambition to conquer the world, you wouldn't see them as much as those who are driven by fear of abandonment and greed.

Chances are, unless you live where I do, you would never have found out about cafe Manufaktura.
And chances are, I don't know anything about the great little software you built.

But it doesn't make it any less real, nor does it say anything about its probability of success.

Great Little Software: Rackula

Valeria — Tue, 19 May 2026 16:31:46 +0000

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. ... I'm building a project or webapp, but it's not really coding — I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."
-- Andrej Karpathy, February 2025

One morning I woke up excited to spend some time on my side-project. I finally had the energy. I'd spent the last week in selfhosted communities and setting up my tiny Intel NUC. Finally I felt that I had an idea how to proceed with the project. I opened OpenCode and 30 minutes after I wanted to throw my project, LLMs and a laptop out of the window and change career to something that doesn't involve saying "NONONO, not like this" to a very annoying program.

I looked at the code and I felt disconnected from it. I knew what it was doing, I reviewed it all, but it felt foreign. The flow was gone and I spent the next few days remembering how to code by hand. I'm happy to report that I've produced the world's most over-engineered counter application: with in-memory storage and APIs for increasing and descreasing the count.

Vibe coding ravaged developer communities deliberately and exponentially speeding up copying from Stack Overflow without understanding. But there is a reason I have to rely on AI assisted development and, while my LLM detox has been extremely beneficial for mental health, I sought out to find better ways to write software with AI.

And I think Gareth Evans, creator of Rackula, has a lot of experience to share on the topic.

Rackula. The Beginning.

It started in the end of 2025. In Gareth's own words:

Originally I was looking to help my Dad organize his super messy server rack, which had several big heavy audio amplifiers and networking equipment. I wanted to think about the layout of the rack and the equipment in a more organized way, without moving these awkward and heavy things around more than once. My Dad is a civil engineer, so loves diagrams and planning. I went looking for a tool that would help me visualize the layout of the rack and the equipment. Surprisingly, there were none that met my needs: easy to use, exports images and doesn't lock in data.

Oh, the allure of the side projects, just like sirens they deceive us with their alledged simplicity and promises of good time. And LLMs only add oil to the fire:

If you recall that Nov-Dec 2025 was right when LLM-based tools were really beginning to show that they could be used to build software in a tangible way. So, like many others I was playing with Claude Code just to see what it could do. I initially wanted a way to visualize the rack layout and equipment arrangement and move the items by dragging them around. I also wanted to be able to save it as a format that could be easily shared and imported. It also needed to be able to export the layout as an image.

I also specifically remember reading Harper Reed's My LLM codegen workflow atm blog post about how he uses AI to brainstorm and generate the specifications that are then used to prompt the LLM to generate code. So, with the need in mind I spent some time building out my spec and then quite rapidly had a working prototype up and running.

The Good, The Bad and Safari

Writing code is easy, when you know what to write, with or without LLMs.
Early on Gareth found out that defining the data model and schema was unexpectedly hard: "I realized (eventually) that a well-defined schema was crucial for building a scalable and maintainable system."

I arrived to the same conclusion. LLMs are horrible at designing the software from scratch, but given a starting point and some guardrails it becomes a lot easier to wrangle overly eager coding agents.

I think there's a lot of good materials out there to get inspired by. Rackula's schema, for example, has been inspired by NetBox:
the code structure couldn't be more different, but the conceptual model of what a rack is, what a device is, what properties they have, how they're related are very alike.

And then there's the scope creep. When possibilities are endless, choosing what not to build becomes a problem. Or as Gareth put it:
"Ideas are easy, it is much harder to limit scope creep. What began as a simple idea quickly grew into a complex system with many moving parts. Initially I wanted to do everything - keep tons of detail about every item"

He also said that if he'd done it all over again, he'd been more diligent about intentionally limiting scope: "I definitely burned some cycles on features that were not necessary for the initial functionality. I had a ton of ideas around modelling networking and power connectivity, which while valuable, were not critical to the core app."

Rome hasn't been built in a day and, judging by 1040 commits, Rackula has been through a lot of iterations. And to a big part that can be attributed to browser quirks:

The architecture of Rackula is focused on SVGs in the browser, and dragging and dropping them. Sounds simple, right? Sure, until you try and get consistent behaviour across browsers. Each major browser has its own ideas of how to handle SVGs and drag/drop, leading to inconsistent results. This meant that significant time was spent digging into how one browser's implementation would affect the user experience in another. I have a GitHub issue label "damnit/safari" for a whole slew of Safari/webkit bugs and inconsistencies.

Even the name of the project has changed in the process:

I initially named it Rackarr, in sort of a playful reference to the *arr suite (Sonarr, Radarr, etc.) and then introduced it to the Reddit community. There was an almost immediate reversion to the name, because it is not truly related to the *arr suite.

It's all about UI

The core philosophy of Rackula is that it must be intuitive. In creator's own words:

I'm not sure if I'm there yet, but I wanted it to be a tool that my parents could use: which is a high bar for usability.

The process has definitely been long and non-linear:

I am not a designer, but do feel like I know when software makes sense (or doesnt). So, my initial layouts were kind of thrown together and would often feel clunky or inconsistent. This led me down a rabbithole of looking at how other canvas-based apps handled UI design and how to make my app feel more fluid. There are still many, many things I would improve if I had more time.

I'm sure that there's more to it, but I do think that the effort placed into Rackula was well worth it.
I, for one, could figure it out and loved the little easter egg of "banana for a scale" I found in the settings:

AI vs Humans

I am genuinely impressed by Rackula's quality and I can't help but wonder how much of that can be attributed to Gareth and how much to AI.
And so I asked him for his secret sauce in the hope to apply it to my own projects. Here's what he shared:

As mentioned earlier, (I used AI) extensively, based on Harper Reed and others who espoused AI-first approaches particularly using Test Driven Development (TDD). AI (Claude Code) was used to define the specifications through interative feedback, and then from there define a blueprint and prompt plan for the tests which eventually define the code that makes up the app. If you recall, Anthropic had doubled the usage limits over the Christmas break: this was the gasoline thrown on the fire for me. I was running 5+ agents in parallel churning out tests, code, and definitely could not have done this without AI.

His process sounds a lot like Kaizen to me, or it's derivative, The Toyota Way: the code generation itself might be done by a machine, but the human is in control, obligated to pull the cord and stop the production when the quality drops.

But what's even most important, I think, is to build the right thing and for the right reasons.
I asked Gareth about his ambitions for Rackula and, despite the project's name, world domination is out of the roadmap:

Well, before this I had never had a project get really any traction. So, at first the dream was "someone clicks on my thing", and now a few months down the road its at over 1k stars on GitHub. So now, my wildest dream is to have Rackula become a go-to tool for the several communities that use it. Really, what I want is for it to get to the point where it takes on a life of its own. I have already seen several individual contributors putting in PRs and helping shape the project, and I believe there's a lot of potential for Rackula to grow and become a valuable tool for the community.

I think this way, where creative process remains in the hands of us, humans, is the way towards sustainable AI assited development.
I also believe that self hosting AI models is an important milestone for that. And if somewhere along the way you get inspired to build a server rack - give Rackula a try.

It's a great little software.

Great Little Software: Theo & Vangogh

Valeria — Thu, 14 May 2026 08:49:34 +0000

Theodorus van Gogh (1 May 1857 – 25 January 1891) was a Dutch art dealer and the younger brother of Vincent van Gogh. Known as Theo, his support of his older brother's artistic ambitions and well-being allowed Vincent to devote himself entirely to painting. As an art dealer, Theo van Gogh played a crucial role in introducing contemporary French art to the public.
-- Wikipedia

GOG - Good Old Games - has been created with a mission to Make Games Live Forever, according to their website. But over a decade ago, in September 2010 they disabled their website making users and journalists believe that it has been permanently shut down due to their DRM-free strategy. GOG.com has been down for just a few days and the site's management eventually revealed that it was nothing but a marketing hoax to draw attention to the new version of their website citing being a small team and having a limited marketing budget.

You can imagine the backlash from their fans that followed.

"I can't afford much in a way of physical media collection - I like to build similar digital collections. Naturally, I wanted some way to manage and showcase that games collection. GOG.com poor-taste marketing stunt prompted me to prioritize that" - explained Bogdan (aka boggydigital), creator of vangogh and theo.

Local copies of game executables could live forever with or without GOG, but the metadata, descriptions, screenshots and other keepsakes you'd have in a physical copy would be lost. Imagine the Louvre, but all paintings are stashed next to the wall in no particular order.
Games are art and deserve to be treated accordingly, digital or not. This sacred duty falls on vangogh:

There's a light theme too, if you prefer:

And theo, his little brother, is responsible for running the games on MacOS and Linux (Steam Deck).
Clearly, naming comes naturally to Bogdan, I can't think of a better duo with this distribution of responsibilities!

But I imagine building them wasn't easy at all.

A hobby for decades

"Finding time to invest in such hobby is always challenging against demands of a day job, family and other hobbies." - says Bogdan - "I've been chipping away on vangogh for almost a decade now and can easily see myself working on this until I die - there's an endless supply of ideas and improvements to work on!"

Being motivated by the work itself is impressive and I admire his ability to do it for so long. And while removing the pressure of making profit helped, limited time and unlimited ideas "that have to be rationalized and implemented" are still a challenge.

But Bogdan seem to have cracked the secret of maintaing focus, flow and joy and I think it has something to do with his principles.
Which are:

"Front end performance/latency should be really good. I don't like using slow websites, so I'm not going to produce one."
"I don't want to use any third-party dependencies. Practically everything in my projects is bespoke, meeting my personal needs."
"Services I work on should work really well together and work similarly. If a user learns how to use one service - they should know how to use another one (e.g. vangogh and theo)"

A passion project

It felt silly asking him about his relationship with AI: like asking Vincent van Gogh if he uses photo camera for his works. But he didn't get offended by my stupid question.

"I don't use AI for development in any way." - Bogdan said, - "Delegating personal passion projects to AI is not the route I'm interested in right now.

Most of the time I spend on those projects is thinking about how to change something to allow for the next idea - typically happens when I'm not near a computer anyway.

If somebody was chipping away on their personal coding projects before the boom of AI - I suspect they continue to chip away in a similar way.

We don't do that to pump the maximum amount of code in the shortest time anyway".

As of today, vangogh has 2118 commits with the first one dated Aug 2, 2020. And by the looks of it its just the top of the iceberg.

AI might've sped up the development, but when there's no market to go to, no investors to please and no expectations except to preserve the art of game development and enjoy the process - why rush indeed?

What's next

"I've recently got into DRM-free Steam and Epic Games Store games. I've been a die-hard DRM-free user and avoided Steam and EGS, assuming most (if not all) games have some form of DRM, but turns out significant amount of games are DRM-free on those platforms. What's more important for me - significant amount of games I would like to own/play are DRM-free! If I'd known that earlier - I'd build vangogh in a more store-agnostic way. Right now - vangogh is focused on GOG games and theo (client for vangogh) can install games from vangogh, Steam or EGS (those two options bypass vangogh and install directly from the source). I'm working on adding ability to self-host DRM-free Steam and EGS games though and expect this will happen later this year." - shared Bogdan.

As for me, I think the last time I thought about DRM in the games was when you had to buy them on the CDs, after that, to my own shame, I've assumed that DRMs are the necessary evil, and "it is what it is" for a gamer. On vangogh's screenshot, I've noticed "Arcanum" - a steam-punk RPG I never got to finish because the version I was playing was crashing at a certain point all the time. I always wondered how it ends, so perhaps that could be the first one to relive. That is once I get a bigger storage for my home server, my babynuc, a refurbed mini PC I use for experiments, couldn't possibly handle the whole GOG collection.

And perhaps get a steam deck with a controller too.
Bogdan is planning to give theo a GUI ("and it should be fast, appealing and work with gamepad") and add cloud saves between theo and vangogh ("a must").

"I'd like to add a server for ROMs (similarly - there's a surprising amount of legal ROMs many people own, so doesn't have to be illegal) that theo can integrate with for a full spectrum of gaming needs." - he continued, "That would be my personal gaming nirvana - completely self-hosted games collection across platforms that you can enjoy on any supported device!"

Give vangogh and theo a try and, if you're up for it, make your own contribution to preserving games dev masterpieces.

As theo & vangogh are great little duo.

Great Little Software: Papra

Valeria — Mon, 11 May 2026 07:00:00 +0000

To me, the main non-negotiable point is the ethical aspect of the project. From having everything opensource, to being selfhosting friendly and privacy-focused, no dark patterns, no shady stuff, no monetization of user data, no bullshit. It's really important for me to build a product that I can be proud of, that aligns with my values, and that make a positive impact, even if it means slower growth or less profit. I'd rather build a smaller sustainable product that treats people well than a bigger one that doesn't.
-- Corentin Thomasset

Papra came up in a research that AI agent did for me. It was a very disappointing research, small indie apps built on strong ethical foundation are very hard to find. I think partly because those who make them care more about the apps than the marketing, but mostly because of the sheer volume of yet-another-too-good-to-be-true AI SaaS platform. So when I stumbled upon Papra I got very excited to see the one that made it through the noise!

I was a bit nervous reaching out to Corentin Thomasset, but he turned out a wholesome human being and generously shared his and Papra's story, that I am so very eager to retell you.

"I've started Papra on January 2025 as a side project while still being employed full time" - he shared in his email, "I needed an archiving platform for myself, and I found existing solutions to be either too complex, or not user-friendly enough to be usable by non-technical users (family). So I decided to build something that fits my needs, and hopefully fits others' too."

I have a theory why many software projects start this way: I think there's a lot of correlation between an artist and a software developer and if you think about it this way, you wouldn't be suprised that a painter painted a sunset view from their backyard - that's what was available at the time - anything goes, because we can't resist the call of "what if it could be done better?" even if that would cost years of working after hours with no return, except for the sense of accomplishment.

Luckily, Papra gained traction and within 9 months Corentin was able to fully focus on the project.
Let me say it again, he was able to make revenue from an open-source, self-hostable, affordable project!

The Right, The Hard Way

There is a reason why the most common business advice is to solve problems for big companies and charge them exorbitant amount of money: it's easier and you only have to get a few customers to be able to cover your own salary. An even easier way is to raise money for your idea - you don't even need to build anything, "just" convince investors that your promises are worth the risk.

It's an art too, just not the style I personally aspire to. I think that business, just like any form of leadership, is about caring about the people you serve and placing their interests above the sheer profit.

And it was very obvious to me that Corentin shares the same values:
"As an open-source and self-hosting advocate, Papra is for me a way to empower people to take control of their own data instead of handing it over to corporations that monetize it. Document archives are deeply personal (tax returns, contracts, medical records, payslips, ...) and I think people deserve tools that treat that seriously.", as he put it - "And, to be honest, I also just love building software. Crafting a product from scratch, solving problems, and learning new things along the way. It's a very rewarding experience for me, and I enjoy the process as much as the result."

Guilty, I do too.

One-man-band

Building stuff is fun indeed. Corentin worked with a tech stack he liked and is deeply familiar and enjoys working with. This freedom to choose how, when and what to work on is the greatest benefit of solo development, but there's the other side of the coin too.

As Corentin put it: "...being a solo founder, you have to wear many hats (every hats to be honest), from development, to design, to marketing, to support, to infrastructure, and more. Every discord ping, every issue, every "it doesn't work" message, every PR, it's all on you to handle, and it can be overwhelming at times. But the community around the project has been amazing and supportive, it's motivating and makes it all worth it."

Naturally, one would suggest to turn to the all-powerful-LLMs to balance the load out, but I think Corentin has a good point about it:
"As a said above, I really enjoy building software, writing code, finding solutions to problems, and crafting stuff with my bare hands, so AI has never had a significant role in Papra's development. I don't want the robots doing the fun part for me, or to lose my connection with the codebase."

He mentioned the famous line by Joanna Maciejewska: "I want AI to do my laundry and dishes so that I can do art and writing, not for AI to do my art and writing so that I can do laundry and dishes.". Given that I've spent the last year trying to tackle this exact problem (never-ending laundry and dishes), I couldn't agree more.

I'm not anti-AI and my impression is that neither is Corentin. He said that he genuinely tried to make it work, but got frustrated because correcting and re-prompting LLM often takes longer and yields worse results than doing it manually. He uses it for reviews and feedback - as a second pair of eyes and a "safety net, not as a builder".

Unfortunately, not everyone shares this perspective and like many of open-source maintainers Papra and Corentin are plagued with vibe-coded low-quality contributions, from people, which took them few seconds to prompt and submit. "But on the other side, it takes a lot of time to review, correct, and give feedback on those PRs (feedback which often just gets forwarded back to their agent). It makes it hard not to get a bit sick of AI-generated code." - he shared.

With great power, comes great responsibility, as Uncle Ben taught us.
We just have to hope the latter comes sooner rather than later.

The recipe for success

As of right now, Papra has 4.4K stars on GitHub, which I find very inspiring and see it as a testament to its maker's abilities and expertise. I asked Corentin if he'd be willing to share his knowledge with us, other solo builders and solo founders, which he did and I believe it's best that I share his answers verbatim:

"The reality is that my projects are not yet profitable enough for me to fully live off them. I have the chance to have some savings, and can collect some French unemployment benefits for a while. Plus my partner is working full time which is a huge safety net. So I have the huge privilege of being in a comfortable enough position to focus on Papra without the pressure of needing it to pay the mortgage next month, but I'm clear-eyed that this window won't last forever. At some point, Papra needs to become profitable enough to sustain me, or I'll go back to a more traditional job and keep building it on the side. That's just the math.

As for tips and advice, I think the main one is to do this for the right reasons. Trying to build stuff just for the money is a recipe for burnout and disappointment, especially in the early stages when the project is not yet profitable. Building something you care about, that solves a problem you have, that aligns with your values, is what will keep you going through, and make the journey enjoyable regardless of the outcome.

As for marketing it's indeed a challenge, especially for a solo builder with limited time and resources. It's clearly not my strong suit, and I don't have a magic formula for it. But I think being authentic, and engaging with the community in a genuine way is important. It goes with the "do stuff for the right reasons" advice, people can sense when a project is built with passion and care, and that can be a powerful marketing tool in itself. I'd love to grow the team eventually and bring in people with marketing or community-building skills, but for now it's just me wearing all the hats and doing my best to get the word out while building the product.

In the end, I'd rather build something small that I'm proud of and that genuinely helps people than chase numbers I don't care about. If Papra ends up being a sustainable one-person product that pays my bills and serves a community of users who care about their data, that's a huge win. Anything beyond that is a bonus.

So if there's one thing I'd say to other solo builders: don't measure yourself against other products outcomes. A profitable, sustainable, one-person product that lets you keep doing work you care about is already a rare and valuable thing. That's the bar I'm aiming for, and I think more builders should give themselves permission to aim there too."

What do you wish you'd done differently with the knowledge you have now?

"I'd tell my past self to focus less on making things perfectly perfect from the start. I easily get caught up in the details and try to build the ideal solution, sometimes getting stuck on a problem for too long, or over-engineering things at the cost of shipping and getting feedback. There's a balance between building something good enough to be useful and obsessing over making it perfect, and I'm still learning to find it. Hard habit to break, but I'm getting better at it."

What's your wildest dream for the app?

"I'd love to see Papra become the go-to reference for document archiving, empowering millions of people to take control of their own data, and maybe even inspiring companies to go full open-source and self-hosting along the way.
And beyond that: a thriving community of contributors and self-hosters around Papra, where the project belongs to more than just me, with an open governance model. The kind of open-source project that lives beyond its creator, one that will adapt and evolve with the needs of its users. That would be the long-term win."

I encourage you to try Papra out at papra.app.
It is a great little software.

Great Little Software: psikat

Valeria — Mon, 27 Apr 2026 09:30:00 +0000

...I've always known that I've been missing out and the modern day just lacks that special charm...
-- Palace, "Back to '85"

Ghostbusters were released in 1984, the first Back to the Future movie and Microsoft Windows - in 1985; and 1986 has brought us The Legend of Zelda and Castlevania. It was a different era, the one I too experienced only by watching the movies and playing games.

You might be wondering what do cats, 1980s and a musical sequencer have in common.
Well for starters, the song I quoted belongs to an artist known as Michael Palace,
the creator of psikat - the browser-based tracker-like sequencer- is holoflash
and both of them are the same person: Redas Jefisovas.

Why a successful musician decides to become a web developer is a story for another time, but it seems that neither of his passions ever fully took over because psikat has been born of them both.

Why psikat?

"Psi - as in the greek letter Ψ (psi); kat - as in cat, because I love cats" - said Redas when I asked.

For at least 15 years, before getting into programming, the main way he interacted with computers was using the mouse and a handful of keyboard shortcuts. Dragging around audio clips in Logic Pro, moving around vector points in Adobe Illustrator - all the interfaces he needed to interact with were built around the mouse.

When he made the transition to programming, he was suddenly forced to put both hands on the keyboard and learn how to actually type properly to become productive, and add a lot more keyboard shortcuts to his repertoire.

Time went on, he learned how to do almost everything on the computer without ever touching the mouse. "This meant I could finally be one of those cool cats who can get by with just a laptop, and I got rid of my whole desk setup with external monitors, mice and keyboards." as he put it.

And once the carpal-tunnel-syndrome symptoms were gone, going back felt horrible. He discovered so called music trackers, that are in some cases completely keyboard based, with a look and a feel of a hex editor, but so very different from the software he used to create music up until now.

So he needed something in-between Fast Tracker 2:

And Logic Pro X he was used to:

He couldn't find one, so he built psikat and the rest is history!

If only it'd be that easy

Getting started, as Redas shared, wasn't hard: the plan was to start with the basic tracker and then bridge the gap towards the DAW (Digital Audio Workstation). The first goal was to build a "tracker that kinda works like FastTracker 2 and can playback .xm format files". This format has been around long enough to be fully documented and iterated on, so it was trivial to reimplement. Especially with the help of LLM’s.

A downside of an established format is that it usually comes with a certain legacy. And thus he felt that if he would label psikat as a tracker, he’d have to jump through to a lot of hoops to satisfy everyone that’s looking for a "tracker".

As a result he decided to narrow his focus or in his own words: "That’s when I changed the description to tracker-like, deleted all of the code and started from scratch. I would have to make my own decisions to make this thing my own and I can’t be weighed down by trying to support all legacy formats people expect."

One-Person-Software

The decision to build just for yourself might sound counterproductive: how would you market it, how would the app get users if it made only for one person?!

But if you had been to the rabbit hole of marketing books, you would have discovered that a common advice is to build for a very specific person in mind. They call it ICP (Ideal Customer Profile) and no, it has nothing to do with the age, or geografical location, or gender. The best and most useful description of an ideal customer comes from knowing their beliefs and needs.

When you are your own ideal customer that's gotta make it a lot easier and if noone ever use the software you make - at least you get a custom made software out of it! I think there's another side effect to this "selfish" software-for-the-sake-of-software process: when you don't think about how much money you'd make out of it or how you'd be advertisting it - your software becomes an art piece, a reflection of your own values, thoughts and perspective.

And when it comes to psikat - it became a reflection of its creator's view on the art in general and music in particular.

One of the main distinguishing aspect of tracker programs and an element that is central to psikat - is that the notes/commands are arranged and read vertically, as opposed to horizontally in more mainstream and modern music software. Hence the Ψ (psi) letter, that is often used to denote the Y-axis in Greek mathematics.

So why would someone who used to write music left-to-right suddenly would decide to turn things a quarter down?

Redas says that the inherent difficulty of making music in a tracker is the main feature for him: "If you’re coming from a traditional DAW, you can be sure that it will force you to break out of patterns you’re stuck in and make you see music from a completely different perspective."

Back to the future with LLMs

Both Michael Palace music and holoflash interfaces have this old-school feeling to it; he compares trackers to vim and DAW to VSCode; so, naturally, I had to ask about his relationship with AI. What place does modern day tools take in his work?

"With AI I’m able to iterate fast and try out many different ideas and avoid becoming a victim to the sunk cost fallacy" - he said, "For example, at some point I started to doubt that I could achieve the performance I wanted using wasm in the browser so I had Claude rebuild the whole thing in SolidJs."

And after doing some research he discovered "the thing that would make the Rust version work as intended" and just as quickly deleted the whole javascript version and went back to wasm.

Redas shared, that the speed it took to try out a completely different stack didn’t leave him feeling like he had wasted his time, but instead helped to try different approaches, remove any doubts and continue with what works.

"Also, working with audio requires a level of mathematic prowess that I simply don’t possess" - he adds, "but it’s an already solved problem that I’m not that excited about re-solving.". AI allowed him to focus more on the essentials, not the implementation details.

And his essentials are: How does it perform? How does it feel to use? Can I make music with it and does it sound any good?

Don't build a DAW

Redas shared that his only regret was that he hasn't built psikat sooner:

People often advise against building a DAW and with good merit. It’s a very very complex piece of software to build. And based on what people online were saying, I was too scared to even try to start. But you can trick yourself into building a DAW, if you don’t start by building a DAW.

He started by building an audio file browser for the terminal, then one small goal after another psikat came to be as it is today. It's not what you would consider a DAW yet (it lacks recording capabilities), but you can mix a song right there in your browser, like this one, I called it "psikat jam":

Click to play

I imagine this could be a soundtrack to something like nyan cat, but way cooler:

I don't think I fully explored what psikat has to offer: my relationship with my own music is complicated. And if this is what the app can do today, in its alpha version, I can only imagine what v1.0 would do!

I bet it would be intentionally unconventional for a good reason.
Or in the words of its unconventional creator Redas aka Michael Palace aka holoflash:

If using psikat can help at least one other person be creative and express themselves in their own voice, I’ve accomplished everything I could ever dream of.

I encourage you to try it out at psikat.com and join Discord.
It is a great little software.

Im looking for indie apps and tools built by solo developers, their stories and perspectives for a newsletter I’m starting. If you know a solo maker or use an overlooked gem built by one please let me know! 🙏

Valeria — Mon, 06 Apr 2026 15:25:55 +0000

Wrangling GenAI: Optimising prompts for Visual Tasks

Valeria — Sat, 28 Mar 2026 13:48:29 +0000

When I wrote the first version of the magic cleaning tasks generator for Hounty I wasn't particularly happy with it, but I thought that this is as good as it gets with Generative AI APIs and let it be till I have time to train my own model. Well, today I proved myself wrong and I want to show you exactly how I managed to drastically improve performance by adjusting the prompt in a few inconventional ways.

I encourage you to follow along and try the prompts yourself. I used Gemini and Claude, but pretty much any chat AI app or API should work. And if you have never worked with GenAI - that's no problem - you don't have to have any prior knowledge to follow along.

The Task

Here is a picture of my living room this morning:

It looks like this a few days a week and every time it's a chore to get started. I do rely on Hounty to tell me what to do and where to start. So let's try and replicate the core functionality with nothing but prompts and see how to improve them.

Take one: You are an expert

You've probably seen the advice to start your prompt with "you are an expert in ...". It sounds like a good idea, but let's try and see what it actually does.

Paste an image of a messy room (yours or mine) into your AI chat and prompt this:

You are a home cleaning expert. Create a cleaning todo list of 3-5 most impactful tasks

Here's what I got from Gemini:

And now let's try without the "you're an expert" preamble:

The second output is about half the size of the "expert" one and I find it much more actionable and clear: "Clear the Floor" vs "Clear the Floor Transit Zones". So why does this happen?

Turns out, giving AI a title doesn't unlock more knowledge, but instead it forces it to act like an expert or, in other words, researchers found that Expert Personas Improve LLM Alignment but Damage Accuracy.

Not to say that personas have no use, but in majority of cases adding "you are an expert" would result in a confident tone and bloated output. Which means you'll burn more tokens for no benefit.

Skipping it works better.

Take two: Detailed prompt

On the first glance, a common advice to describe what you want in as many details as possible makes sense, so let's give it a try.

Same image, more explicit prompt:

Look at this image. List every visible object. For each object, determine whether it is out of place based on what should be in a Living Room. Consider laundry, dishes and clutter specifically. Return your findings in a structured list of 3-5 most impactful cleaning items as JSON.
Example:
[{"task":"Throw away newspapers", "advice":"Recycle as newspapers"}]

Here's the json it returned, since it didn't fit into the first screen:

[
  {
    "task": "Fold and put away laundry from the sofa",
    "advice": "Sort by owner or garment type and move to the bedroom or closet to regain seating space."
  },
  {
    "task": "Stow reusable shopping bags",
    "advice": "Empty any remaining contents and store the Lidl bags in a pantry, kitchen drawer, or car trunk."
  },
  {
    "task": "Clear the floor of miscellaneous items",
    "advice": "Pick up the pink hairbrush and the black tub; return the brush to the bathroom and store the tub in a utility area."
  },
  {
    "task": "Declutter the windowsill and cat tree base",
    "advice": "Move non-decorative items and loose papers to a dedicated desk or filing system to improve natural light flow."
  }
]

And now try a simpler version:

Create a todo list of 3-5 most impactful cleaning tasks. Return as JSON {title,advice}

Here's the resulting json in full for comparison:

[
  {
    "title": "Clear the Sofa Surface",
    "advice": "Fold or hang the large pile of clothing on the couch. Clearing this central furniture piece will immediately make the room feel functional and less overwhelmed by 'clutter weight'."
  },
  {
    "title": "Consolidate Floor Items",
    "advice": "Gather the loose items on the rug and the shopping bags by the door. Use the empty black bin shown in the foreground to quickly corral miscellaneous objects that don't have a dedicated home yet."
  },
  {
    "title": "Clear the Windowsill and Radiator",
    "advice": "Remove the papers and pink organizer from the windowsill. In a bright room, clear horizontal surfaces near windows reflect more light and create a much cleaner visual line."
  },
  {
    "title": "Reset the Dining Area",
    "advice": "Tuck the dining chairs neatly under the table and remove any small items from the tabletop. Aligning the furniture creates a sense of order that anchors the rest of the open space."
  }
]

Both prompts produced a similar list, but the first one added a lot of noise, which would not only made it much harder to use in an API, but would also cost more since it used more input and output tokens.

And the pink brush the first list mentions? It's a cat brush, it doesn't belong in the bathroom - it belongs in a box with cat stuff. Skipping that detail made the second list appear more precise.

So why did the detailed prompt backfire?

Because the second prompt gives the model room to reason. We've stated the goal clearly and let it do its job. When we provide too many details in the context LLM experiences effects similar to overtraining a model. In other words:

Overtraining (often synonymous with overfitting) occurs when a machine learning model learns the training data too well, capturing noise and specific details rather than general patterns.

By giving the LLM too many details we limit the ways it can solve the problem and thus as a general rule - less is more. You can always add or clarify something later.

And once again, less tokens spent!

Take three: Structured data

Now that we have the tasks in place it would be nice to add the coordinates of the areas on the image which illustrates each task.

Let's try and enchance the prompt to return just that:

Identify 3-5 most impactful cleaning tasks and return ONLY JSON{task,x,y,w,h} mapping tasks with the areas on the image where x,y are top-left corner pixels of the bounding box and w,h is width and height

Adding "ONLY JSON" was needed to make sure that LLM doesn't interpret "do this and then that" as two separate requests and spits out text and JSON.

Here's the result:

Hm, I didn't ask for a "label".

We could keep patching the JSON prompt, but there's a better tool for the job - CSV(comma-separated values).

Try this adjusted prompt:

Identify 3-5 most impactful cleaning tasks and return ONLY CSV(task,x,y,w,h) mapping tasks with the areas on the image where x,y are top-left corner pixels of the bounding box and w,h is width and height

And here's what I got:

CSV is just as easy to parse as JSON, but turns out it produces more reliable output with less tokens. I think it might have to do with a fact that JSON requires AI to add something around values and it can occasionally go overboard, whereas CSV is just text with values as is. LLM native, if you must.

So ditch JSON, use CSV and alike. The only gotcha to keep in mind is that comma in the text might break the output, so it might be worth asking LLM to escape strings in the output.

Take four: Spatial coordinates

In the previous step we asked LLM to provide the coordinates of the top left corner of the area corresponding to each task, let's see how it fared.

To test it I prompted Gemini and Claude to create an app. You can use the resulting artifact or try this prompt to create one yourself:

Create a small frontend app that would ask user to choose an image and paste a CSV(task,x,y,w,h) with tasks and areas on the image in either absolute pixels (add switch) or normalized coordinates (0.0 - 1.0) as well as x,y being either top-left or center of the box

Let's see how our original prompt with absolute pixel coordinates performed:

Meh, stupid AI, can't even outline a box properly, right?!

Now let's try to adjust the prompt to return normalized coordinates instead:

Identify 3-5 most impactful cleaning tasks and return ONLY CSV(task,x,y,w,h) mapping tasks with the areas on the image where (x,y) are coordinates of the top-left corner of the bounding box and x,y,w,h are normalized floats between 0.0 and 1.0 (fraction of image dimensions). Box must stay within image: x-w/2 >= 0, x+w/2 <= 1, y-h/2 >= 0, y+h/2 <= 1

I added the last sentence because Gemini kept returning absolute values (way more than one) for the y coordinate.

Here's how the resulting overlay looks:

Not too bad, but still a little off.

And now for the last trick, let's try and switch top-left corner to a center instead:

Identify 3-5 most impactful cleaning tasks and return ONLY CSV(task,x,y,w,h) mapping tasks with the areas on the image where (x,y) are coordinates of the center of the bounding box and x,y,w,h are normalized floats between 0.0 and 1.0 (fraction of image dimensions).Box must stay within image: x-w/2 >= 0, x+w/2 <= 1, y-h/2 >= 0, y+h/2 <= 1

Voilà! Almost as good as Hounty:

If you're wondering why LLMs work better with normalized centered values - it boils down to how the original data that model was trained on looked like.

Asking a vision model to produce output in it's native 0-1 centered way makes it easier for them to give you what you asked for than to perform operations on the go.

"But what if I need a different format?"- you might ask.

I hear you, I also wouldn't want to release a new app every time I'm making an update to my API - the app in my case expects absolute values returned as json.

And this is where the plain old geometry comes in handy!

If GenAI produces a reliable machine-readible output (like CSV) you can take that output and transform it with a little bit of regular programming into whatever format you'd like.

As a rule of thumb: if you can do something without AI - it would be cheaper and more reliable to do it without AI.

Cool, but how do I ship my prompts?

Great question! We spent this whole article in the chat, that's not something you can just use or can you?

And the answer is: yes you can! GenAI APIs are pretty much standardised and you can write the same prompts as you do in the chat and send them via REST API just like you'd do for any other service.

Almost any cloud provider nowadays has their managed Generative AI API; Claude, Gemini & co also offer that, and you can even host or run your own model with Ollama.

AI might have changed software development quite a bit, but in the end of the day it is still based on the same principles and sheer logic.

There's no perfect prompt like there's no perfect code, but every iteration gets you a little bit closer to it.

Oh and I did clean up when I finished updating the APIs :)

TIL that App Store apparently loves small frequent updates. New version of Hounty got into review within hours today!

Valeria — Mon, 23 Feb 2026 22:35:29 +0000

5 things I learned from building and releasing Hounty

Valeria — Fri, 20 Feb 2026 18:58:18 +0000

First of all, I can't believe Hounty is actually out! It's been so long since I started a small project that turned out to be a year long crusade and I can't be more proud of crossing this threshold.

TL;DR You can download Hounty on App Store for free, the app is written in Flutter and the backend is in Serverless Go + Serverless PostgreSQL.

Looking back I can't say I would do many things differently - the lessons I learned had to be learned, but I sure wish I knew a few things sooner.

1. Build in Public

While the idea is great and helps build trust and relationship it really only works if:

You are building a tool aimed at developers
You have something for them to try

Same goes for building a community on social networks before the app is ready. When I submitted the new shiny Freemium version for release I made the previous version free and shared a video "Coming soon" with the app preview on TikTok:

Five hundreds downloads are amazing! Except these users must've been so frustrated when they didn't find the new AI cleaning planner and were met with completely different design...

My point is - advertise what is ready.

2. Deploy small changes

I've rewritten UI and backend several times and every iteration has taken me weeks up until the moment where I would either get exhausted or paint myself into a corner. It only started to work when I learned to apply what I preach: to refactor as you go.

Here's an example: I was working on a sync feature and I wanted to change the logic from log-based storage (all events are stored in one table and then replayed on the device) to an entity-based storage (every entity is stored in it's own table with it's own versioning).

At first, I tried rebuilding everything all at once and it got really frustrating and I almost abandoned the whole thing, but then I started moving small pieces:

moved the files of one entity into a separate folder, tested, commited, deployed
wrote an abstraction for command pattern, refactored one "submodule"
refactored the rest one-by-one
changed the storage one-by-one

Apparently, this approach suits not only for working in a team, who would've thought?!

3. Play store requires 2 weeks and 12 beta testers

This one was new for me, my old Play store publishing account was no longer usable - I don't know if it was because it was created in Russia originally or because I did something stupid, but I needed to create a new one to publish and I discovered that I had to find 12 beta testers to test the app for 2 weeks before I could release it. My friends and family are on Apple devices, so it's going slower than I expected.

There's a "testercommunity" app and a few communities on Reddit where people support each other, so definitely not a deal breaker, but I chose to focus on App Store for initial launch.

4. App Store subscriptions are a hassle

Releasing a one time pay version was very easy - it got approved in two days, but the free version with subscriptions took almost 2 weeks of back and forth.

First, I didn't add the subscriptions to the release and the app went out with a beautiful paywall and no working subscriptions.

A tip here is to check that the subscriptions have all the locales and obligatory fields filled and have status "Ready for review" before you submit a new version.

And most importantly to add them to the version before submitting it for review. If you don't see where to do it - your subscriptions aren't ready. Super frustrating.

Then, apparently it's obligatory to have a dedicated "Restore purchases" button even for subscriptions, even if you store the subscriptions on user account.

Oh and you have to have a link to your terms of services in the description.

And after the release subscriptions might be lagging and not appearing on the app store or in your app for 8-24 hours. Joy!

5. Tech Stack for Solo developers

Being the only developer and working after hours with a very limited amount of time LLMs are a must, but they need a bit of handholding and depending on choices of language they might need more or less.

Anything web-related that looked like React has been a breeze, Flutter was okay-ish after I setup all the scaffold, and yet I am holding myself from refactoring most of it.

I managed to make it work with Go, but if I'd do it again - I'd build the backend in Rust. I didn't like Rust compiler barking at me - but I love it keeping Sonnet and Opus in check. Besides, it has great documentation and the only one way of doing things in a majority of cases - which makes LLMs predict the code more reliably.

So was it worth it?

I don't know what comes next yet. Well, apart from Rust rewrite, of course. It's time to send Hounty into the world, look at the data and iterate. It wasn't easy, I'm yet to brag about my MRR, but it has been a fun ride.

I built something I'm proud of, users are downloading it and my kids are showing me their perfect before and afters (they clean!). So yes, I think it was absolutely worth it!

So, wanna see my clean pics?