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.

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:

1. Locality and Simplicity
2. Focus, Flow and Joy
3. Improvement of Daily Work
4. Psychological Safety
5. 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.

“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.

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.

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.

…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”:

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.