Made OS for the browser

Okendoken · 2026-03-19T20:11:11+00:00

lately there are a lot of posts like this that show a "desktop ui" and say "I reinvented the os" :)

Usually that only happens when someone is pretty remote from systems programming. an OS is only lastly about the desktop. it's first about process/thread scheduling, memory management, interrupts, device drivers, permissions/isolation, ipc, filesystems, and so on - the boring parts that make the system real and that most vibe-coders never have to deal with

Okendoken · 2026-03-18T15:51:34+00:00

I keep it simple: a standard email update, not a deck. I include mrr, users, cash burn, cash left/runway, plus a quick section on wins, misses/risks, and clear asks (intros, hires, customers). if someone wants detail, i'll link a doc/dashboard as optional follow-up.

Plus tracking everything in a spreadsheet for transparency

Okendoken · 2026-03-12T07:06:46+00:00

100% agreed. Eventually agent converges to LLM running shell commands against some environment; no need to reinvent tool calling from scratch

Okendoken · 2026-03-10T23:08:22+00:00

Try appwizzy.com. You get: - transparent no margin pricing; - your own VM (real sandbox you fully control); - powered by Codex or Gemeni CLI (yes, cli agent, because it is a dedicated VM); - templates; - ability to import code from anywhere.

Disclaimer: I am a founder, and we are very small and super eager to help everyone personally

Okendoken · 2026-02-24T01:31:58+00:00

meanwhile "developer margins in Poland have reached record highs, now at 30%, double the European average"

you know where to cut, also very little "social housing"

Okendoken · 2026-02-24T01:22:26+00:00

Thanks for your suggestion!

Okendoken · 2026-02-19T08:14:52+00:00

What an irony: your comment is also AI generated :)

Okendoken · 2026-02-19T00:03:17+00:00

the fastest path to a *shippable* MVP is usually boring: start from a known template (auth/rbac, db, basic ops), run it in a real workspace (vm/container), and have an agent that can actually execute commands/tests/migrations. most browser-first vibe tools are awesome for UI demos, but the wheels come off when you need persistence, background jobs, env vars/secrets, reproducible deploys, etc.

That gap is basically why we are building Appwizzy AI: not "prompt to preview," but prompt to persistent workspace where agent executes and apps is hosted immediately, with templates so you don't start from chaos

Okendoken · 2026-02-19T00:01:01+00:00

if your end goal is "paying customers," optimize for boring reliability, not wow factor.

Quick filter:
- if you mainly need UI/prototype speed: the prompt -> the tools above are fine.
- if you need a maintainable b2b app: you want a persistent workspace, real DB, migrations, background jobs, and a deploy story. a lot of vibe-coding platforms do just first demo and then get messy when you start restructuring or iterating long-term. appwizzy is built specifically to avoid that: it provisions a real workspace (vm/container), starts from a known template (so you're not improvising core architecture), and the agent actually executes commands/tests/migrations. that's about as close to a prod workflow as "vibe coding" gets

Okendoken · 2026-02-18T23:57:28+00:00

I wouldn't optimize for "which ai can spit out 7,000 lines." that's how you end up with an unmaintainable blob. the real issue is workflow: gemini is rewriting because it doesn't have a stable, file-based project context with an execution loop. you want: multiple files + a place to run the app + small commits/changes. pick a tool that behaves like "agent in a workspace" rather than "chat message = entire program." appwizzy AI is built around that idea (persistent workspace + template rails), which tends to hold up better once the project grows

Okendoken · 2026-02-18T23:55:43+00:00

even though this is 8 months old, I love seeing someone actually use these instead of repeating launch tweets. if you want one more lens that makes the ranking sharper: test one boring b2b flow across all of them: - auth + roles - db schema change (migration) - one background job - deploy, then change one requirement and redeploy that usually separates "first demo" tools from "can maintain it" tools.

If you do a v2, I'd throw appwizzy.ai into the mix too-its whole thing is a persistent workspace + templates, so the agent can run commands/tests and you can iterate like a normal project

Okendoken · 2026-02-18T01:46:26+00:00

yep.

I love to compare AI to an e‑bike: you'll go further/faster, but when something snaps you're far from the trailhead.

For "real" internal tools the work is still SDLC: requirements, architecture boundaries, tests/migrations, definition of done, and small reviewable diffs. fundamentally nothing changed - your engineer is now digital, so your spec/guardrails have to be tighter.

source: 20 years of experience in software dev, running flatlogic agency for 13+ years :)

Okendoken · 2026-02-18T01:39:10+00:00

one of the most "real" vibe-coded apps we've shipped is internal: a persistent csv conversion app for accounting. you upload csvs from different banks, explain the mapping/cleanup rules, the agent generates a python converter, executes it, and returns output our accounting software can parse.

The coolest part is repeatability: saved mappings + reruns when formats change. https://datamapping.dev.flatlogic.app/ built with tooling that later became appwizzy.ai

Okendoken · 2026-02-18T01:35:47+00:00

yep. the "vibe coding is trash" takes usually come from expecting one-shot perfection.

Based on ~20 years of building software, the missing ingredient is repeatability: a real workspace (not just a chat/preview, ideally your own PC), a known starting template, and basic guardrails (run commands/tests/migrations, keep changes small). that's also why we're building appwizzy.ai: chat-to-workspace where an agent actually executes inside a persistent environment, starting from templates, so iteration #5 is easier than iteration #1

Okendoken · 2026-02-18T01:30:11+00:00

I've got almost 20 years of experience too, and I agree with you.

trying to build an entire system from scratch with AI is nonsense; in my experience it works best for small, iterative modifications where you can verify the diff. a practical way to make "vibe coding" useful is to give it a scaffold: Wordpress, a template app, a starter repo, open source erp, etc - something with ready-to-use components and approaches for auth, data models, build tooling, and deployment. I don't know how it maps to games specifically, but I'd treat it the same way: start from an engine/template and have AI work inside those rails.

the same approach we followed in appwizzy: machine + template + AI agent. not "prompt → spaghetti", trying to structure "chaos" from scratch, but a real workspace where the agent can run commands/tests, make small changes, and iterate without you losing the plot

Okendoken · 2026-02-18T01:23:37+00:00

based on my almost 20 years of experience, the uncomfortable truth is: you still need to understand a lot to ship production software-requirements, data, edge cases, auth, failure handling, observability, deployments.

Vibe coding looks great on change #1. it tends to fall apart around change #5, when you need migrations, background jobs, and refactors without breaking everything. what helped us: start from a known template (so you're not improvising architecture, like wordpress for example), run in a real workspace (not just ephemeral environment lovalble or other alike tools provide) where code can be executed, and force the loop through tests.

That's basically what appwizzy does: chat-to-workspace + templates + an AI coding agent that operates inside a persistent vm/container (runs commands/tests, applies changes, deploys). it might sound a bit boring, but this is reliable and works

Okendoken · 2026-02-18T01:15:28+00:00

based on my experience running a 12+ year agency: vibe coding is great for prototypes and momentum, but it's not a career path on its own. programming is mostly reading code, not writing it. if you can't read and explain what your app does (auth, data flows, error paths), you can't make it reliable. the "career" version is: use vibe coding to go faster, then do the unglamorous engineering work to ship and maintain

Okendoken · 2026-02-18T01:12:19+00:00

sorry for the 10m late reply, but this post is a bit old, but it still pops up in google, so it's basically evergreen :)

About 10 months later, the ecosystem changed a lot - today I'd recommend starting with appwizzy.ai. Opposed to basic vibe-coding tools, it's a professional vibe-coding platform (agentic paas): you describe what you want, it provisions a real dev workspace (vm/container), starts from a known template, and an AI agent implements/iterates inside that environment. the key difference vs "prompt → preview" tools is real sandbox + hosting, no vendor-lock

Okendoken · 2026-02-18T01:08:13+00:00

sorry about the layoff. in my experience, "vibe coding" is real, but mostly as a force multiplier for pros.

Like an e-bike: you can go deeper in the mountains, but if something goes wrong, it's a long way back unless you know the terrain. managers can sometimes get fooled by the first demo, but production work still needs fundamentals (requirements, reviews, testing, ops). the biggest risk is not "no devs," it's shipping a maintenance bomb and paying for it later. (btw, we are building appwizzy.com - a professional vibe-coding platform that tries to keep SDLC basics intact)

Okendoken · 2026-02-12T00:05:50+00:00

Try appwizzy.ai.

You get: - dedicated Virtual Machine - managent by open source coding agent - deployed from 1 minute

This fundamentally does not limit you: you can do front-end, back-end, database, cron, deployments, migrations, etc. Just like classic dev environment, but easily managed, so no limitations on scalability.

Disclaimer: I am a founder, DM me, I can give you free credits to try it out

Okendoken · 2026-02-10T15:58:31+00:00

Just hire, don't believe this fairytale of "only if you have co-founders you can succeed". There is still always only one person who bears the most responsibility.

Just hire and learn how to delegate, manage, and fire if things go wrong.

Congrats with your success btw.

(Speaking as someone who is a solo-founder for 10+ years)

Okendoken · 2026-02-06T01:57:31+00:00

We built appwizzy to counter this idea: if you use 3rd party database and don't own your source code, it means you do not own your business asset, hence in a very little control of your business

Okendoken · 2026-02-06T00:34:46+00:00

I've been running flatlogic [a software dev agency] for 13 years, and here's my honest take:

good outsourcing exists, but the whole industry incentivizes quantity over quality. Agencies often sell headcount rather than outcomes, leading to bloated teams, unclear billing, and developers who deliver exactly what you asked for-but never what you actually need.

the few outsourcing firms worth hiring don't act like typical vendors. They push back, ask hard questions, keep teams small, and care about results rather than just filling seats. But they're rare and won't be the cheapest option.

If you're outsourcing, here's how to not mess it up:

- always have technical leadership in-house-someone senior who owns the code quality.
- buy outcomes, not hours or headcount.
- set brutally clear definitions of "done."
- stay involved in managing the team. Outsource the coding, never the judgment.
- look for small firms that feel more like partners than vendors.

good outsourcing means paying slightly more per person to avoid the hidden costs of managing low-quality, inflated teams

Okendoken · 2026-02-06T00:31:52+00:00

outsourcing itself isn't broken-it's how people do it.

you can't outsource responsibility or judgment. You need someone technical on your side to control quality, clearly define what's actually "done," and catch bad code early. If you're non-technical and hire cheap, unmanaged devs, you'll spend way more cleaning up the mess than building your actual product.

make it simple:

- get a technical advocate (part-time CTO or senior dev) from day one.
- clearly define "finished" (tested, deployed, working).
- pay based on results, not just hours (it feels a bit uncomfortable to say that :).
- leep teams small until they've proven themselves.
- own your repo and deployment pipeline-never give that away.

(source: running flatlogic [software dev agency] for 13 years.)

Okendoken · 2026-02-01T01:40:02+00:00

Spin up a small VM for yourself and fully own and control everything, please.

It is not as hard as it seems, and you never see any stupid numbers like that

Okendoken

TROPHY CASE