u/IamSanja90

I wanted to share my experience of turning a small personal tool into an actual Steam release.

I work as a web developer and I like building things myself. I have been using Python for a while, I’m comfortable with it, and I understand what I’m doing with it. I also have experience with JavaScript and Electron.

And yes, I use AI while coding.

I would describe it as “vibecoding”, but with a brain attached. I let AI help me, generate ideas, explain things, and speed things up, but I still check what goes into the project. I try to understand the code, test it, and make the final decisions myself.

The idea started pretty simply.

I play a lot of games with friends, mostly stuff like Rust, Counter-Strike, and similar games. In our group, people often use tools to play sounds so others can hear them ingame. There are already several tools for that, of course, but none of the alternatives really had the functionality I wanted.

So I thought: why not build my own?

I started the project in September 2025.

The first prototype was a soundboard with an integrated web server. It served my sounds as sound pads inside my local network, so I could control them from my phone. It was simple, but it worked, and I actually used it myself.

At some point, I had the idea to take it further and maybe release it on Steam.

That was when the real research started.

How do you integrate software with Steam? What does Steam require? How does Steamworks work? What do you need before you can even start?

The first thing that slowed me down was the Steam Direct fee.

You have to pay $100 to get started, and that honestly made me hesitate. Not because $100 is impossible, but because I assumed I would probably never see that money again. For a small hobby tool, that made the decision feel bigger than it probably sounds.

That hesitation set me back by about two months.

At the beginning of 2026, I finally decided to just do it.

I paid the fee, started working through Steamworks, and connected my software with Steam. From there, I kept expanding the project step by step. Design, features, testing, removing features, adding new ones, changing things again.

The project slowly turned from “small soundboard I use with friends” into an actual product.

Over time, I added things like:

  • remote control through a local web server
  • a pad designer
  • a theme designer
  • an overlay
  • a Stream Deck plugin
  • a normalizer
  • a sound editor
  • Steam Workshop integration for themes

I also explored a lower-level audio approach to avoid relying on virtual audio cables, but I paused that idea because proper signing and distribution would be too expensive for the current stage of the project. If the tool ever gets enough usage to justify it, I might revisit that later.

Once the software felt ready enough, the next big part started: preparing everything for Steam.

To be fair to Steam, they explain a lot of the process quite well. From the store page to builds, there is a lot of documentation and guidance. But it is still a lot of work when you do it for the first time.

I created the store assets, designed logos and images, resized everything to Steam’s required dimensions, filled out all the forms, set up the store page, and kept testing my builds while the page was waiting for review.

Eventually, I submitted the build and waited.

During that time, I also built a first documentation page and a small website with a support form. Nothing fancy, but functional. I used MkDocs for the documentation and Django for the website. I’m still not really happy with the docs, so I’ll probably rework them later.

Then Steam reviewed the build.

The first review came back with two issues.

The first issue was that one text on one page was still hardcoded in one language, while the rest of the software supported multiple languages.

The second issue was related to the installation of the virtual audio cable. Steam expected it to be installed through a Steam install script instead of being installed directly by the application itself.

Both points were fair.

I fixed them, submitted the build again, and after the second review everything was accepted.

Then I launched the “Coming Soon” page.

After that, I had to wait two weeks.

And of course, I checked the Steam marketing page every day.

How many people saw it? How was the visibility? How many wishlists did it get?

The numbers could have been better, obviously. But honestly, that was not really the main goal for me. The process itself was the important part. I wanted to know what it feels like to bring my own software all the way to Steam.

And now?

My tool, EchoKey, has been out for three days.

It made two sales.

And honestly, I’m happy with that.

For many people, that probably sounds like nothing. But for me, it feels good because I know how much work went into it.

In the last two days, I also kept working on it. The first buyer had a small issue, and I was able to fix it directly with a patch. That part was actually one of the most satisfying moments of the whole project: seeing a real user problem, understanding it, fixing it, and shipping the solution.

This was not a huge launch. It was not a financial success story. It was not some overnight indie success.

But it taught me a lot.

I learned about Steamworks, build reviews, store assets, documentation, support, patching, audio routing, product decisions, and also where AI helps and where you still have to take responsibility yourself.

My main takeaway is this:

AI can speed up development a lot.

But it does not replace understanding what you are building.

And even two sales can feel pretty good when you know what it took to get there.

reddit.com
u/IamSanja90 — 15 days ago
▲ 4 r/Odoo

Ich muss mir das gerade mal von der Seele schreiben, weil ich langsam wirklich keine Energie mehr dafür habe.

Wir haben jahrelang mit JTL-Wawi gearbeitet. Klassisches Setup: lokaler Server, Zugriff nur vor Ort oder per VPN. Es funktionierte irgendwie, aber modern oder flexibel war das alles nicht wirklich.

Irgendwann fiel dann die Entscheidung, Richtung Odoo zu gehen. Ich habe zuerst testweise die Community Edition auf einem kleinen Rechner installiert, Windows mit Docker Desktop. Nicht perfekt, aber als Testumgebung absolut okay. Das lief soweit, ich konnte mich einarbeiten, Module testen, erste Datenstrukturen verstehen und schauen, ob Odoo überhaupt zu uns passt.

Danach hat unser interner ITler mir eine Inhouse-VPS bereitgestellt: 8 Kerne, 12 GB RAM, Windows Server 2022.

Auf dem Papier klang das erstmal gut. In der Realität war das Ding eine Katastrophe. Ordner im Explorer brauchten teilweise Sekunden, bis sie überhaupt aufgingen. Die Odoo-Installation hat sechs bis sieben Stunden gedauert. Ich habe mehrfach gesagt, dass sich der Server extrem langsam anfühlt, aber mir wurde immer wieder erklärt, dass der Server „bombenschnell“ sei.

Nach viel Hin und Her konnte ich die Geschäftsleitung dann überzeugen, erstmal auf Odoo Online zu wechseln.

Und siehe da: Odoo Online war schnell. Wirklich schnell. Ich habe Produkte migriert, Dokumente erstellt, Prozesse eingerichtet, Automationen gebaut und sehr viel an die Firma angepasst. Zum ersten Mal hatte ich das Gefühl: Okay, das kann wirklich funktionieren.

Dann kam irgendwann die erste Wartungsrechnung bzw. Rechnung für Code Review von Odoo. Nicht dramatisch, aber natürlich wurde intern sofort wieder überlegt, ob man das Geld nicht sparen könnte, indem man wieder lokal hostet.

Und dann kam unser ITler wieder mit: „Ich mache den Server. Debian. Alles lokal. Kein Problem.“

Mein Vorschlag war: Wir mieten einfach einen günstigen Strato-Server oder etwas Vergleichbares. Für ungefähr 11 Euro im Monat bekommt man da schon 6 Kerne, 12 GB RAM, ordentliche SSD-Performance, feste IP, saubere Erreichbarkeit, Firewall, Domain, SSL — alles berechenbar und von außen sauber erreichbar.

Antwort: „Warum Geld ausgeben, wenn es auch inhouse geht?“

Ich war zu dem Zeitpunkt schon so müde von der Diskussion, dass ich irgendwann einfach zugestimmt habe.

Dann kamen die nächsten Probleme.

Unsere Firma hat keine feste IP. Die Hauptleitung ist ein 6000er DSL-Anschluss. Also wurde über Vodafone für 5 Euro Aufpreis eine feste IP auf einem 4G-Router gebucht. Schon das fand ich für ein produktives ERP-System fragwürdig.

Dazu kommt: Ich habe eine Django-Webseite gebaut, die mit Odoo kommuniziert. Odoo sendet Webhooks an die Webseite, und die Webseite holt sich Daten per REST-API aus Odoo. Bedeutet: Odoo muss sauber von außen erreichbar sein.

Dann kam die nächste Lösung vom ITler: Er mietet einen 2-Euro-Proxy, über den dann zur Webseite bzw. zum internen Server weitergeleitet wird.

Auch da war ich innerlich schon durch und habe es abgenickt.

Das Ergebnis: Der neue Server läuft auf Debian, aber ist wieder extrem langsam. Images bauen, PostgreSQL und Odoo einrichten: teilweise 40 Minuten. Ein Odoo-Datenbankbackup mit relativ wenig Daten einspielen: teilweise 60 Minuten, wenn es überhaupt sauber durchläuft.

Ich wurde stutzig und habe angefangen zu messen und zu recherchieren. Ergebnis: Die Festplattenperformance liegt irgendwo bei 3 bis 6 MB/s lesen/schreiben. Zum Vergleich: Bei einem günstigen gemieteten Server wären eher 300 bis 600 MB/s realistisch.

Ich habe das angesprochen. Es wurde mehr oder weniger ignoriert.

Odoo läuft zwar grundsätzlich, aber man merkt ständig Lags. Besonders bei Suchfiltern, Listenansichten und allem, was auf Datenbank- und I/O-Performance geht. Es fühlt sich einfach nicht sauber an.

Dann habe ich durch Zufall noch festgestellt, dass die Weiterleitung über diesen 2-Euro-Server nicht sauber auf eine bestimmte IP gebunden ist und außerdem öffentlich per HTTP ohne SSL erreichbar war.

Und ganz ehrlich: Da war ich einfach fertig.

Was mich am meisten frustriert: Ich bin nicht gegen lokale Server. Ich bin nicht gegen Debian. Ich bin nicht gegen Selfhosting. Im Gegenteil. Aber wenn man ein ERP-System betreibt, an dem Geschäftsprozesse, Produkte, Dokumente, Automationen und externe Schnittstellen hängen, dann braucht man eine Infrastruktur, die messbar funktioniert. Nicht „gefühlt schnell“, nicht „wird schon passen“, sondern sauber getestet, abgesichert und wartbar.

Das Problem ist nicht Odoo. Odoo selbst läuft gut, wenn die Umgebung stimmt. Das habe ich mit Odoo Online gesehen. Das Problem ist diese Mischung aus falschem Stolz, Sparzwang an der falschen Stelle und einer internen IT-Kultur, in der moderne Ansätze erstmal reflexartig abgelehnt werden.

Docker? „Brauchen wir nicht.“

Externe VPS? „Geldverschwendung.“

Cloudflare? Kennt man nicht oder will man nicht.

RustDesk als AnyDesk-Alternative? Erst wird es als „Linux-/Docker-Scheiß“ abgetan, drei Tage später kommt dieselbe Idee plötzlich von jemand anderem zurück — dann ist sie natürlich gut.

Und genau das macht mich wahnsinnig.

Ich habe keinen klassischen IT-Abschluss. Ich bin da eher reingewachsen. Ich habe Python für mich entdeckt, arbeite viel mit Django, baue interne Tools und Webseiten, betreue VPS-Systeme und habe mir extrem viel selbst beigebracht. Ja, ich nutze auch KI und „Vibe Coding“, aber nicht blind. Ich versuche zu verstehen, was ich tue, teste Dinge, dokumentiere, messe und suche nach pragmatischen Lösungen.

Trotzdem stehe ich intern oft da wie der Typ, der angeblich nur Probleme macht. Wenn ich einen Fehler mache, wird sofort mit dem Finger auf mich gezeigt. Wenn andere schlechte Entscheidungen treffen, wird es irgendwie wegmoderiert oder ignoriert.

Ich bin mittlerweile an einem Punkt, an dem ich weniger über Odoo frustriert bin als über die Umgebung, in der ich arbeite.

Ich will nicht jeden Tag gegen dieselben Mauern laufen. Ich will nicht jedes technische Thema erst durch persönliche Egos, alte Gewohnheiten und „haben wir schon immer so gemacht“ durchprügeln müssen. Ich will einfach in einer Firma arbeiten, in der technische Entscheidungen anhand von Fakten getroffen werden: Performance, Sicherheit, Wartbarkeit, Kosten, Risiko.

Nicht anhand davon, wer am lautesten behauptet, dass sein Server schnell ist.

Vielleicht bin ich zu emotional, weil ich so viel Arbeit in die Migration gesteckt habe. Aber aktuell fühlt es sich an, als würde ein eigentlich gutes Projekt langsam kaputtgespart und kaputtverwaltet.

Odoo war nicht das Problem

Die Infrastruktur war es.

Und noch mehr die Haltung dahinter.

TL;DR: Wir sind von JTL zu Odoo gewechselt. Odoo Online lief schnell und stabil. Aus Kostengründen sollte wieder lokal gehostet werden. Der interne Server ist extrem langsam, Storage liegt bei 3–6 MB/s, externe Erreichbarkeit wurde fragwürdig gelöst, SSL-/Proxy-Setup war unsauber. Ich bin inzwischen weniger von Odoo genervt als von der internen IT-Kultur und dem ständigen Kampf gegen schlechte technische Entscheidungen.

reddit.com
u/IamSanja90 — 18 days ago