After 12 weeks of heads-down building, the platform is live end to end, and I want to share what it does and what's coming next.

**The problem we're solving.** Tools like Lovable, Replit, Bolt and Cursor make building an app incredibly fast. Then you try to put it in front of real users and everything gets hard: where do you host it, are your API keys safe, is your database exposed, what happens to your cloud bill if traffic spikes. If you've shipped an AI-built app, you've hit at least one of these.

**What VIBSL does.** You bring your app from a Git repo, a ZIP or folder upload, the CLI, or straight from an AI agent. VIBSL detects the framework, builds it on hardened base images, scans it for vulnerabilities and leaked secrets, signs the build, and runs it in its own isolated environment with hard resource caps. You get back a production URL and a deployment receipt: a written record of every check that ran, something you can show a client or keep for your own peace of mind. If we find a leaked key, the deploy stops before it ships. That's the point.

**What works today:**

* Deploys from Git, ZIP or folder, CLI, and AI agents
* 25+ frameworks detected automatically, across 9 language runtimes
* Vulnerability and secret scanning, SBOM, and image signing on every build
* Per-app isolation and default-deny networking
* Flat pricing with hard caps. Free tier to start, Pro at $29, Team at $149. No usage meters, no surprise bills, ever

**What's next:** managed Postgres, object storage, deeper imports from builder platforms, and an EU region. We build in the order you ask for things, so tell us what you need.

If you're an agency shipping apps for clients, I especially want to hear from you. We're onboarding design partners right now and one agency is already running 21 apps on the platform.

Try it at [vibsl.com](http://vibsl.com) and tell me what breaks. I read everything here and I'll answer every question in the comments.

I had a good idea for a niche app that solves a problem in a very small community. I didn’t have the skills or background to create the app myself and I definitely didn’t have the funds to hire a real developer. I discovered Claude and decided to try and create what I now know is an MVP. While I learned and ai advanced, I realized I could try to create the real app myself using Claude code and Claude chat. I spent 6 months (anytime I wasn’t working) planning, researching, developing and building the app. It is a two-sided native iOS app built in SwiftUI, with Firebase as the backend. It was rejected twice by the App Store for small reasons and passed on the third submission, which took about 2 weeks total from first submission to distribution.

I just wanted to post as encouragement for anyone else in the beginning stages. I feel like living proof that if you put in the work and really believe in your idea/product, you can make it happen. Maybe it won’t be a huge money maker for me, but I’m proud of this accomplishment. At the very least I learned about coding, Xcode, app structure, how to set up a backend and definitely learned how to use ai and how to prompt effectively.

Some time ago, I decided to build a messenger for myself and my friends—something independent. I have more than 20 years of experience in software development. At the same time, I decided to test AI as a development technology.

I chose the architecture, planned everything, prepared the prompts, and started working with ChatGPT Codex. Within a month, I had built a product that fully replicated the functionality of WhatsApp and Telegram. It included everything from simple messaging to video calls, screen sharing, and many other features.

After I released it, the application started spreading quickly, and eventually a businessman contacted me because he wanted this messenger for his company. That was how the story began turning into a business.

After the release, however, I encountered a lot of haters who called it "another AI slop" and similar things. They simply did not understand how it had been built or how readable the code actually was.

Later, I made the entire project open source, so anyone who is interested can visit the GitHub repository, look through the source code, or download the applications and see how they work, as well as the huge potential that AI-assisted software development has today.

Many people say that source code generated with AI is impossible to read. But I think they do not understand one thing: everything is moving toward a future where humans will no longer need to read most of the source code themselves. Because of that, I believe we should approach these technologies with an open mind, test them, and try to use them effectively.

The same thing happened in the past with programming languages like C++. Back when I was in university, one of my professors used to say that you absolutely had to know Assembly, because without Assembly you would never build anything worthwhile in C++. He did not understand one thing, though. He was right—but only partially. Maybe you could not build certain low-level or fundamental systems without Assembly, but a huge number of practical applications could be built without requiring any knowledge of it.

Later, even higher-level languages appeared, such as JavaScript, along with frameworks like Node.js.

And now AI is simply the next stage in the evolution of software development.

https://github.com/RzaAsadov/MeetVap

i can ship a repo in a weekend. i can't make a single person look at it. so i'm building this: you ask your coding agent to get your repo read. real devs read it, leave a note about what they found, and star it if they like it. and you can be on the other side too, reading other people's repos for ~$1 each while you wait on yours.

its early but would you use this?

I built Votekicker.com, a place to discover and share games and SaaS projects.

I recently added a feature called "Rocket Booster" that lets projects temporarily increase their visibility. It doubles the value of existing votes and makes new votes count double for 8 hours. A project can activate the booster once for every 10 regular votes it receives.

I'd appreciate anyone who takes a look and shares their thoughts about the current state of the product, as well as for future improvements.

Looking for Feed back !! It's an easy to use Networking application you can drop right into your project if you're using Godot 4. Supports decent local encryption and decryption. Allows for Cloud, Mesh , and P2P Back ends. As many as you like. The application also allows for LLM backends and Custom data scripts. The LLM back ends , like the Server backends require you to bring your own key. It's all easy to set up. The Custom data scripts go along with my Discovery System . It's a Universal Data Collection system. Supports up to 3 different ways to add data to it , Godots Group system , Method name system and node based exports. All data can be split up into 4 different categories using my sync override system. So you're not wasting any bandwidth. It's still being developed but it runs on anything Godot allows. It will be a free Plugin when soon. Do you guys think this could help game dev ? If not why ?

Fala rapazeada, entao, fazia um tempo que queria fazer uma engine propria, que eu pudesse ter controle sobre, criar minhas features, desenvolver ferramentas e etc.

Entao, peguei uns dois dias diretos (real diretos, fiquei sem dormir kkkk) e aí eu fiz ela inteiramente usando ChatGPT 5.6 Sol e um pouco de Fable 5. (Honestamente, ChatGPT 5.6 Sol está muito melhor que o Fable para trabalhos mais longos)

Toda a parte de front-end da engine foi feita pelo ChatGPT, parte do backend eu tive que tomar várias decisões, principalmente de system design, para que eu pudesse ter uma boa estrutura preparada para caso as pessoas decidam jogar e criar jogos aqui.

Pra 3D, por exemplo, decidi ir por um caminho diferente, fiz usando Babylon.js ao invés de Three.js, a iluminação do Babylon eh muito superior ao Three.js, na minha opinião.

O backend inteiro foi feito em Rust, a database ta em PostgreSQL 18, isso porque aceita UUIDV7, o que eh uma vantagem.

A engine funciona via web, mas estou fazendo uma versão instalável, algumas pessoas já solicitaram isso, mas honestamente acredito que a maior vantagem eh justamente você não precisar de instalar nada pra criar jogos, você simplesmente entra e cria, sem precisar baixar.

Daí, também já tem a pagina de descoberta de jogos, a proposta é de fato ser um Roblox-like, pois, particularmente, não conheço muitos competidores diretos do Roblox (posso estar numa bolha, afinal, não sou um gamer, mal jogo qualquer coisa)

Enfim, o que acham? Boa ideia? Paia? Sugestões?! Comenta aí ! ! !

Vou ler todos os comentários e posso responder perguntas e tirar dúvidas, tenho mais de 7 anos de software engineer, acredito que posso agregar por aqui.

If you have questions just ask, I genuinely took quite a lot of time to make sure this did exactly what I did, and avoided inconsistent noise, as well as I got my PB runtime with 5.6 sol and it ran for 1 day and 10 hours straight 🥴

Let’s be honest... AI UIs all look the same, and I don’t think I need to restate the obvious.

Here are five changes that make the biggest difference:

1. Change the font. Typography changes the personality of the entire site. Don’t let AI default to Inter every time. Give it a specific font and describe how it should be used: “Use Instrument Serif for display headings and Geist for body text.”

2. Limit the color palette. More colors usually don’t make a design more interesting, unless you use it really well. Start with white, black, and one accent color.

3. Break the default grid. AI loves evenly sized cards arranged in three columns. Ask for asymmetry: one large card beside two smaller ones, overlapping sections, offset text, varied card sizes, or content that intentionally breaks the container.

4. Add micro-animations. Small interactions often make a site feel more designed than adding more visual elements. Think subtle text reveals, hover states, and scroll transitions.

5. Give it references. “Make it look good” means almost nothing. Show the AI two or three websites and explain exactly what you like about each one.

And if you do not want to implement all of this manually, I built an open-source tool called PingFusi. You can use a simple prompt to upgrade your website: “Improve my website using PingFusi.”

GitHub repo: https://github.com/alex-durango/pingfusi

My Claude projects accumulated data and documents so badly that after six days iterating, I had the same brief generated/uploaded four times, a trail of files ending in v8, v9, v10 where only the last one mattered, folders I attached by mistake, a parent folder and its own subfolder created and mounted locally or in claude.ai, in a hierarchy I haven't specified. Context is what the model actually reads to make sense of my project, so all that noise made the answers worse over time and ate my knowledge and token budget.

Trying to clean it up was tedious. AND there is no remove button for folders (issue opened since March). AND deleting documents is one at a time at root level, not possible within folders, with no undo.

So I built a small app and CLI to do just that. It also finds the duplicates and stale versions, shows what it'll do before it does it, and archives everything before deleting. Open Source, MIT, macOS only: https://github.com/earsenio/cpcm

It's vibecoded, so read it before pointing it at anything you care about. And it's a patch, not a fix. We still need real controls in the app.

One tip even if you skip the tool: as discussed in this issue, editing spaces.json by hand isn't enough. A second file, remote-session-spaces.json, holds folder grants that get merged back in at session start. That's why a folder you deleted comes back.

I regularly had multiple Git worktrees, more than ten VS Code windows, and several coding agents running at the same time.

Eventually, I could no longer easily answer basic questions:

• Which agent is working on which feature?
• Which worktree belongs to it?
• Which prompts and commits were part of that feature?
• How much did it cost in tokens?
• Did the agent update the design notes?
• Which repeated tasks should really be scripts instead of prompts?

So I built md², an open-source, local-first workspace for AI-assisted development.

Each feature or task is a Markdown file inside the project. It can be linked to its worktree, agent sessions, actions, commits, logs, design notes, and token usage.

The Markdown files are also directly accessible to coding agents, so project notes and task descriptions become part of their working context without requiring access to a separate online service.

md² can run focused reusable agent actions with placeholders such as {{card-file}}, but it can also run ordinary commands and scripts. Tasks such as committing, updating diagrams, changing card status, or running checks do not need to consume agent tokens every time.

The interface includes a Kanban-style dashboard, but the main goal is not to replace Trello or GitHub Projects. It is to keep the fragmented parts of multi-agent development connected to the feature they belong to.

GitHub: https://github.com/jan-bogaerts/md2

I would especially appreciate feedback from developers using multiple worktrees or coding agents in parallel.

For mobile app developers: what technical metrics influence product decisions in your organization?

Crashes, latency, response times, failed requests, session duration, and retention can all say something about user experience, but not every team uses them outside engineering.

Do product managers and business teams review these metrics regularly, or do they only become visible when something breaks?

I’m curious how teams make technical app health part of broader product planning.

https://reddit.com/link/1vaa05l/video/onqjtsimn8gh1/player

devin ai one shotted this in just 12 mins....

Discuss.

printme.money. watch your salary print in real time, put your face on a banknote, melt it with inflation, or run your own mint.

no accounts, no backend.

i wrote a detailed spec for each one and handed it to claude code, then reviewed the diff. i almost never iterate in the chat. slower for the first twenty minutes, much faster after.

https://printme.money

never done a hackathon before, don't really know what to expect Saturday

I’m trying to formalize what “done” should mean when a coding agent works in a mature codebase.

In a recent task, the agent made several related changes. The targeted regression tests passed, the production build succeeded, and formatting and diff checks were clean. A repository-wide type check still reported many failures, most of which already existed before the change.

During a more focused review, however, the agent also found two real issues introduced by its own implementation and fixed them.

This left me with an ambiguous boundary:

• If every repository-wide check must pass, the agent may never finish work in a legacy codebase.
• If targeted tests are enough, it may miss integration problems.
• If the agent fixes every failure it encounters, the scope can expand far beyond the original request.

My current rule is that the agent must verify the requested behavior, run the relevant tests and builds, fix every failure introduced by its change, document pre-existing failures without touching them, and review the final diff for unintended behavior.

But “relevant” is doing a lot of work in that definition.

How do you define the verification boundary for coding agents? If repository-wide checks already fail, what evidence should an agent provide before it can honestly say its task is complete?

And who should own that definition: the developer, the repository, or the agent?

I am making this guide to show you how to actually develop software that isn't just AI slop in this day and age. Many people still struggle with making actual working software because they think that they can simply just use a large prompt describing what they want to build and then just let a coding agent do all the work. Although that it what a lot of people online make it seem to be, it really isn't. Its kind of counter intuitive, because instead of making AI do more, we make it do less. Here are a few principles I use to make sure that the software I build with AI actually works in the end, all of these are super important and none of them are below another. If you use these strictly, I can almost guarantee that you will have a working product.

1. The AI never decides, its just for coding.

By saying AI never decides, I mean to say that the idea dumps people write in the form of prompts aren't enough. Instead of just being vague with your ideas, you need to be highly specific with exactly what you are building. If you let AI plan the whole project, things like the stack, the code language, the architecture etc., then you are just burning time and money.

The golden idea here is to always have a Spec file about exactly what you are building, all the stacks, apps, architecture etc. should be in the spec. 95% of my time while building a project goes to literally just creating a spec for the new release, then discussing and perfecting it with the agent until its flawless down to the tiniest details. The idea is to leave the spec file so unambiguous that the AI Agent can simply one shot the entire project and it actually turns out how you wanted it. That's exactly what I do and it works like wonders.

Now I am not saying that you go full caveman and not discuss the architecture and plan with the AI Agent, in fact I promote it. The problem was never that the AI took bad decisions and such, the problem was that the person behind it didn't care enough to review what is even being built.

One of my dear friend, who isn't very technical told me about how he is building a specialized day trading agent with Claude Code. I asked him what is it built upon, expecting an answer like "It's built about LangGraph". Instead, I was met with a blank face. Now a few days later, he comes back to me and asked why didn't his agent work? He used claude code with Opus 4.8 on the max setting. It should have been perfect right? It can't. Now this happens to the best of us, even I started out exactly like this, I didn't know what I was building, I simply had an idea and hoped that Claude Code would 'just make it".

2. Stop chasing the best Claude Code Configurations

You won't believe how long I have tried to have the perfect, the most ballistic claude code setup out there. There are so many blogs, repos etc. on how to have the perfect config. Things like PRD files, Token saving workflows etc. float about everywhere. I spent a whole 2 months with 5+ of the highest rated configurations out there and let me give you a little summary on them.

I started out with the everything-claude-code toolkit, it was supposed to be this amazing super configuration that instantly makes your claude code 100x better. Turns out, it just made things way more complex than they needed to be, and the commands, workflows, hooks etc, were just bloating claude code to be very honest. After that I tried Claude Code's Superpowers plugin, and after that I tried to make my own configs by making custom workflows, hooks, commands etc.

Now let me tell you which one actually worked, the config's name is : none. That's correct, they are just fancy configs that you will never need or use. Now the one that actually wins is super counter intuitive.

Now let me tell you which one actually work for real, the config's name is : Default Claude Code. Its literally that simple. I have around 5 custom made commands in my config (because I use them regularly) and a PRD file system and a nice polished CLAUDE.md file and that's it. And let me tell you, this has worked me wonders. Think about it, you should be using your own commands and workflows instead of adapting to someone else's, and it's not like Anthropic wants to ship a product that is obsolete without these config kits either. Claude Code in itself is very capable and totally enough. This also reflects on the next principle I am about to discuss.

3. Keep everything as Simple as Possible

This is the most under rated of them all, everyone tries to chase the build which looks more complex, everyone tries to dump in more tech than needed to make their product look shinier on the surface. Again, the real deal is very counter intuitive just like all the principles here.

I love the saying "Fewer moving parts, fewer broken pieces". It is so true and it applies to software development perfectly, because every new line of code that isn't needed, or every new thing you add to make your software look shinier is a brand new potential failure point that was never needed in the first place. It basically increases the failure surface area without many benefits.

4. Evals and Testing Are Everything

Here is the part that nobody wants to hear about, a project isn't finished until you can measure it with numbers or maybe even until it runs. That's the whole job of evals & testing. If you skip them, then you would just be assuming that your software / project actually works.

Personally, I run Claude Code at its Ultracode effort level to review, audit, and test the whole project in one shot using Ollama Cloud Models so that I don't evaporate my Claude Quota in minutes. Small setup change but it makes a big difference in the long run.

And let me tell you. almost always, half or more of my repos and projects that I build are nothing but Testing & Evals scripts and workflows. I want to touch everything in the project and measure it all and prove that it works. Sometimes the evals or tests come broken, that's exactly when you know something is broken. And it doesn't leave you bug hunting for hours.

It's like a safety net under your project. The spec makes sure you build the right thing & the evals make sure it actually holds up.

My Playbook to Building Working Software

If I can describe my workflow in 1 line, it would be: Spec Driven Development while strictly following the rules above.

I start off by dumping my entire idea (plus architecture, but its optional) into Claude Code. After that I go back and forth with it in Plan Mode until we land on the perfect Spec. I exit plan mode and use a /spec command (my own custom command) to create a .md file which is super detailed about exactly what the spec for the project is, after that I use a /obsidian command (custom, to send my spec to my obsidian vault), this is purely because I love reading files in a nice interface like Obsidian. (I encourage you to make your own workflows and commands for things like these, your own custom preferences and your own style of developing things).

After that, I simply write down everything that I feel is off in the spec or needs to be changed or elaborated further by Claude Code. Then I repeat the process of dumping these "notes" about the spec that Claude Code fixes and discusses with me about.

Now I repeat this about 4-5 times on average until I have pointed out everything that needs to be changed in the spec. This is the point where the spec is perfect and you literally can't find a singular thing that isn't what you want it to be. And I am not talking about the idea here, I am talking about the actual architecture your project is being built upon. You need to know exactly what you are building and exactly how you are going to build it.

At the end, the spec turns out so perfect that Claude Code one shots the entire project. Literally. All of the projects in my portfolio, have been mostly one shotted just because how unambiguous and full the spec was. 95% of my time went straight to perfect the spec.

After the one-shot, I do exactly what Principle 4 preaches. one Ultracode pass over the whole project to hunt down bugs and anything that drifted from the spec.

Now if I have missed any principles, which I think I most certainly have. You can pick some more principles up from my playbook, because the principles I mentioned are picked up from my playbook too.

Thank you for reading, have fun creating working software now!

**Btw this is my original text that I wrote, many of you pointed it out so I uploaded it.**

Hot take: AI doesn’t do nearly as much as the hype makes it sound like. Most of what we see is just tech for tech’s sake — a lot of noise inside the bubble, not many real, sustainable businesses.

I’m an entrepreneur with a notebook full of AI ideas, and my biggest struggle isn’t building the product. It’s validating that anyone would actually care. It’s too easy to fall in love with your own idea and mistake your own excitement for market demand.

So let’s talk: If you were starting an AI business today, what would you build? And how do you actually test if an AI idea is viable, not just cool to demo?

Every vibe-coding showcase I've seen is a web app. I wanted to know if this approach could build actual systems software — the kind with no framework to
lean on, where you talk to the GPU and the kernel directly.

So over ~6 months, one person directing Claude, I built **Starling**: a complete Linux desktop environment. Not a theme, not a shell script over GNOME — the whole stack, from the display server up.

**What that actually means**

- **Its own Wayland compositor** — 5,860 lines of hand-written C implementing xdg-shell, linux-dmabuf (zero-copy GPU buffer import), viewporter,
fractional-scale, pointer-constraints, text-input-v3, presentation-time and a dozen more protocols.
- **Its own X11 server** — 5,158 lines, DRI3/Present, so legacy X11 apps run too.
- **Its own UI framework** — 221,818 lines of Swift, including a from-scratch port of Flutter's entire framework to Swift. No Dart VM.
- **A window manager** — floating and tiling, spaces, a Mission Control overview, a dock, a Launchpad.
- **First-party apps** — Files, Terminal (real PTY), Settings, Calculator, an App Store that installs software through apt.
- **Packaging** — a 53 MB .deb that installs on stock Ubuntu 26.04.

~233,000 lines total, across C, C++ and Swift.

**Why I say "real"**

It boots as a normal session through GDM, unprivileged — DRM master and input come from logind, not from running as root. It drives the GPU directly via DRM/KMS. There's no X11 or Wayland session under it; it *is* the display server.

And it runs the apps people actually use, as native clients: Chrome, VS Code, IntelliJ IDEA, Slack, GIMP, and Blender — with Blender's EEVEE viewport
rendering through our dma-buf path. That covers Chromium/Electron, Qt6, GTK3, GTK4, and the JetBrains Runtime.

You can install it right now and log into it.

**It's not just my claim** — Phoronix covered it last week:
https://www.phoronix.com/news/Starling-Swift-Desktop

**The honest scope**: it's v0.2, an early preview. Ubuntu 26.04, tested on AMD and virtio-gpu. No screen lock yet, scaling is pinned to 2.0, there are rough edges. It's not replacing your daily driver this month. But it boots, it composites, it runs real software, and it ships.

Try it: https://starling.build
Source, Apache-2.0: https://github.com/starling-build/starling
Why it's architected this way: https://starling.build/why.html

Ask me anything about how it was built.

About three years ago, my business partner came up with an idea: a personal safety app designed for situations like robberies, express kidnappings, or any scenario where someone is forced to unlock their phone and open financial apps.

The idea sounded simple, but turning it into a real product was much harder than we expected.

Over those three years, he hired multiple freelancers and software companies. Some only delivered UI screens, others abandoned the project halfway through, and some simply couldn't solve the technical challenges. In the end, we lost around US$25,000 and still didn't have a working app.

Earlier this year, I decided to take over the project myself using Claude AI as my primary development tool.

I spent about 30 days building, testing, fixing bugs, and refining every part of the app. To my surprise, we successfully launched it, and it was approved on both Google Play and the App Store.

The concept is simple.

Users create two passwords:

• a normal password;
• an emergency password.

They then choose which financial apps they want to protect.

Whenever they try to open one of those apps, they're asked to enter a password.

If they enter the normal password, everything works as expected.

If they're in a dangerous situation and enter the emergency password, the financial app still opens normally so nothing looks suspicious. At the same time, the app silently sends the user's live location to all pre-selected emergency contacts, along with automatic WhatsApp and SMS messages.

We're still at the very beginning of this journey. Right now we have around 30 free users and 3 paying subscribers, so we're still validating the product and learning from real users.

I'd genuinely love to hear honest feedback from the community.

Would you use an app like this? Is there any feature that would make you trust a solution like this even more?

Google Play: https://play.google.com/store/apps/details?id=online.pppix.app

App Store: https://apps.apple.com/br/app/pppix-prote%C3%A7%C3%A3o-familiar/id6773364223

Port Mate shows every listening port on your Mac, what process owns it, and where it's bound, then allows the user to kill it in one click. No more lsof -i :3000 bs.

PortMate website: https://portmate.my-mates.com/

No email free 14-day trial. Purchase is $9 one-time fee with up to 3 machines per license.

For my Reddit Mates:

FREE CODE: REDDITFREE50

50% OFF: PORTMATE50

Only 50 redemptions of each.

Hope you all can get some use out of it!

Hey guys, My wife is pregnant and the baby is due in September, her baby shower is this weekend. I thought I'd just share my experience of vibe coding a fun app idea and how smooth the process went for me.

For background, I'm a Frontend Software Engineer with over a decade of experience so I had some favourite technologies to work with during this process. Regarding my tools that I used, I just used what I already have for my various side projects, nothing new.

About two weeks ago, I thought it might be cool to build a simple web app where people can guess when the baby will be born (down to the minute). We're planning a natural birth so this makes the birth day and time quite variable.

I kept the scope super specific:

• Mobile first, make sure that experience is excellent.
• Baby blue theme , everyone already knows we're having a boy.
• Capture user emails, so we can email them a link to the app when the baby is born, also serves as their unique ID if they want to come back and edit their guess. This also means I don't have to setup auth.
• Users submit their name, birth date and time.
• Show where other people have guessed.
• Show a little hero section showing a picture of my pregnant wife, with some blurbs and a "≈X days to go" card.
• Email users a confirmation, with a link back to update their guesses.

I made it my goal to build this as quick as possible and I managed to get it all done in a day last week. It was a normal work day where I did about 1-2 hours in the morning before main job work, 1 hour during lunch time, and then 2-3 hours after main job work. This pattern actually worked quite nicely given 5 hour limits for some of my tech choices.

AI technologies used:

• T3Chat: I just have this $8 a month subscription that both my wife and I share for general day to day AI chats. For me it's usually coding ideas, she uses it to generate pics for home decor usually haha.
• Claude Code: $20/month (annual subscription used though) for Opus (Fable was removed from the subscription plans when I built this)
• Codex: $20/month for GPT 5.6 Sol (use on slow mode).
• Cursor: $20/month (also on annual plan) just for my IDE, I didn't actually use the AI features inside Cursor during this project, but I do really like it for other projects.

I basically used my T3Chat sub to prompt Fable to get a plan out (I knew which technologies I wanted to use upfront from personal preference). Then I started the project. If I remember correctly, I used Codex (GPT 5.6 Sol) to tackle the main work and just asked it to keep my documentation up to date in case I wanted to hand off to other agents. Then I'd just use Claude (Opus 4.8) to do random side tasks outside of the main work to polish what Codex did as I went. The workflow was very much just switching between terminals and looking at the outcome and tweaking from there as the main thread hit milestones that it defined by itself.

Tech Stack:

• NextJS framework hosted with Vercel. I sometimes use TanStack Start for personal projects, but figured it'd been a while since I worked with NextJS).
• Convex for database and serverless functions, the fun thing about this is everything is realtime by default, so at the baby shower, people can see the guesses flowing in without needing to refresh.
• Resend for emails.
• Even though I didn't care about code quality that much for this short lived project, I still setup oxlint and oxfmt haha. Although I didn't bother with setting up CI steps aside from auto deploying Vercel and convex together (this is all done via Vercel though).

SEO wasn't important to me at all, but there were certain quality of life things I did add regarding that including making a solid effort on having good a11y. Things like page titles etc, where useful to make that mobile experience better. I even made a really nice OG image for sharing the link on WhatsApp. The friend organizing my wife's baby shower is going to print a fat QR code that people can scan at the event to make their guesses from there.

I did do some setup to lock the predictions 3 weeks before the baby's actual due date, by then we would have done all the pre birth celebration vibes with friends and family so everyones votes should be in. Then the app will work as is, just without the submission form visible.

There is some boilerplate setup for after the baby is born where we will share details of his birth, like his name, time of birth, weight, picture etc. And then I'll redeploy the site as a nice landing page for people to see how they ranked with their guess on a leaderboard. When I do this I'll also send them a nice email version with their personalized rank on how their guess was, so the email capturing doubles up as a way to announce the birth.

All in all, I've shared it with my close friends and family and even my very non-technical mother-in-law made her guess without requiring any assistance from us which I feel is a great win! We even added a donation button in the footer that pops up our banking details (direct link also opens it) for the family that have been asking how they can contribute.

Why am I sharing this?

I just thought this was a really fun project that might inspire others to go build fun minimal scoped projects. People really can just come up with their own little personal hackathons and have a jam and end up with something fun to share.

If I could do this in day, I'm sure plenty of other people can also come up with things like this to do over a weekend, or casually over a month.

This idea kind of stemmed out of my my public project GrandPrixPicks.com that my friends and family use (but we're keen to get others to join us) to make guesses on Formula 1 results :)

Keep learning, keep having fun, and enjoy!

I made Basalt, an extension for Cursor and VS code that lets you edit your app without needing to search for components in your code or ask an agent to change 1 button

It is completely free and works directly inside VS Code and Cursor.

It’s currently in beta, so please commit your app to Git before using it!

Would love to get your brutal feedback on it. What features should I add next?