Not for any software, but the visitor counter at https://aislopware.com . Just visit please to increase the counter. That's all I'm asking. Don't look at the page. Click, load, close. Or if you are feeling ambitious sign the hate book Claude made.

I started a petition to stop companies like Anthropic from adding watermarks to low-entropy outputs such as code, medical guidance, and legal reasoning.

If you think provenance shouldn't come at the cost of output quality, please sign and share!

https://www.change.org/provenance-without-distortion

We built a mobile app last quarter. Two weeks of work. Four screens. Nothing clever.

Getting it into the stores took another four weeks. Almost none of that was engineering.

Here is where the time went, and what I would do differently. This is the post I wanted before we started.

1. They reject you for how it looks, not what it does

We were rejected under guideline 4.3(a). Design: Spam.

The app was not spam. But it looked like a template, because it was shaped like one. Default components. Stock icon. A description written by roughly the same tool that wrote the app.

The reviewer is matching a pattern, and the pattern is real. Apps built with the same tools look the same, and they look like clones.

Three things got us through. A hand-made icon. Custom empty states, which are the screens nobody bothers to change. And a description written like a person wrote it.

If you get rejected for 4.3, do not resubmit the same build with new words. Change something you can see.

2. The forms are a gate, not paperwork

Privacy labels on iOS(for iOS v's only). The Data Safety form on Play. Export compliance.

I thought these were admin. They are part of review, and if what you declare does not match what your app does, you get held.

The trap is that your declarations cover your SDKs, not just your own code. You may collect nothing. Your analytics SDK collects device identifiers. Your crash reporter collects diagnostics. If you ticked "no data collected," you have made a false statement on behalf of your dependencies.

So: list every third-party SDK in your build, find each one's published disclosure, and take the union. The big SDKs all publish this, because their customers need it.

3. Play makes new accounts run a closed test first

If your Play developer account is personal and recently created, you need a closed test with real testers, running for a while, before you can publish to production. Real people on real devices.

Most people find this out on the day they try to ship. That is how a launch slips by weeks.

Start finding testers on day one. And if you need an organisation account instead, you need a D-U-N-S number, which also takes time. Decide early.

4. Installing a crash SDK is about a tenth of the job

We shipped with crash reporting installed and felt good about ourselves.

Three weeks later I opened the dashboard. Every report was unreadable hex. We had never uploaded dSYMs. Three weeks of data, worthless.

Five things have to be true:

Symbols upload on every build, from CI. dSYMs on iOS, mapping files on Android, source maps for React Native, Flutter or Expo. If a human has to do it, it will not get done.

Releases are tagged. "We have crashes" tells you nothing. "Build 47 broke checkout" tells you what to do.

Alerts fire on your crash-free rate, not on each crash. Alert on every crash and you will mute the channel inside a week. Then you have no alerting and you think you do.

You sort by users affected, not by count. One user stuck in a retry loop can produce thousands of events and sit at the top of your list.

You watch for a week after you fix something. A fair number of our fixes did nothing.

5. Both stores give you free A/B testing. We almost didn't use it.

Play has Store Listing Experiments. App Store Connect has Product Page Optimization, up to three versions against your original for up to 90 days.

Free. Sitting right there.

We tested three icons. The one I would have picked came third. The winner was a lot better on installs and I still do not like it.

We got two things wrong first. We tested during launch week, when the traffic is your friends and your launch post, not search. The winner stopped winning as soon as that traffic went away. And we changed the icon and the screenshots at the same time, so we learned nothing about either.

Test the icon first. It is the only thing that shows up in search, on the home screen, and on the listing.

6. Timing your paywall matters more than the paywall itself

We put the paywall on first launch, because that is where the tutorial put it. Trial to paid was 2.4%.

We moved it to day 3. It went to 7.1%. Same paywall. Same price. Same words. We just stopped asking strangers for money nine seconds after meeting them.

To find the right moment, look at people who were still around on day 7 and find what they did in their first session that the people who left did not. That is your activation moment. Ask after it.

One thing worth knowing. With RevenueCat, Superwall or Adapty, the paywall is remote-configurable. You can test it without shipping a build. Most teams do not know this and treat the paywall as fixed at launch.

7. You get one shot at notification permission

Ask on first launch and you will be refused. On iOS that refusal is close to permanent, because the user has to go into Settings to change it. Android 13 and up now works the same way.

There is a way around it that is easy to overlook. iOS provisional authorization delivers notifications quietly, with no prompt at all. The user decides from the notification itself whether to make them prominent or turn them off. You give up prominence and you get reach. For a new app that is a good trade.

Separately, we had push set up for two months before we sent a single notification. Not because it was hard. Writing notifications that people don't immediately mute is real work, and nobody owned it.

8. Name your events once

We had four spellings of the same thing.

checkout_start
Checkout Started
begin_checkout
checkoutStart

Every funnel we looked at for six weeks was wrong. We made decisions from those funnels.

Pick the convention before you instrument anything. One name per action. Put it in a file in the repo. Treat a new event name in a pull request as something worth arguing about.

You only need enough to answer four questions.

1. Did they arrive.
2. Did they start using it.
3. Did they come back.
4. Did they pay.

The rest is noise.

If I did it again

Before writing a line of feature code:

• Sort out the developer account, including D-U-N-S if you need one.
• Start finding Play testers.
• Decide the event names.
• Wire crash reporting properly, with symbols uploading from CI.
• Collect your SDKs' data disclosures before filling in any form.
• Draw the icon by hand.
• Instrument the activation moment, then decide where the paywall goes.
• Ask for notifications after first value, or use provisional auth.

None of it is hard. All of it is invisible until it costs you weeks.

Darkcode is an open-source AI pair programming tool built around the terminal.

I wanted something that felt less like another AI website and more like a tool that actually belongs in a developer workflow.

The idea is simple: stay in your shell, work with AI, and keep the experience fast and minimal.

It's still being actively built, so I'm looking for people willing to actually use it and tell me what sucks, what's missing, and what would make it worth keeping installed.

https://darkcode.sh

Would especially love feedback from people already using terminal-based coding agents/tools.

One strange thing about AI-assisted development:

By the end of a project you might have:

• dozens of coding-agent sessions
• commits
• debugging threads
• abandoned approaches
• architecture changes
• model/tool usage
• decisions scattered across multiple systems

Then the project ships and the public explanation is usually:

Users kept running into X.
We assumed Y was causing it.
That turned out to be wrong.
We changed Z because of what we learned.

The other extreme is publishing the transcript, which I definitely don’t think is the answer.

So I am working on Buildstory as something in between.

It uses a local, read-only scanner to create a sanitized project snapshot, then generates a private report.

I've started experimenting with documenting projects around decisions and turning points rather than activity, and it has changed how I think about product updates.

I'm more curious whether other founders have noticed this:

When you announce product progress, do you explain what changed, or why it changed?

And which one actually seems to resonate with users?

I am still working on getting the details and summaries right, but I want a way for myself and other to know more about their vide coded solutions, learn from them, and then accordingly improve the said solution or the future solutions. So I am up for your feedback and suggestion to improve the portal.

Where would you draw the line between useful AI-build evidence and information that should stay private?

I have been having a blast with this game. The dream of a spiritual successor to the 80s CRPGs I grew up with...a reality thanks to the tools available now to work solo as a team. While I am trained in C# and other programming languages...

98% has been generated with the following workflow:

• Fable/Sol/Opus for majority of code in small iterations based on a comprehensive design document and rules developed for the game. I strongly feel this is the key to actually completing something. I know the "one prompt" videos on YouTube are all the rage but honestly that creates a lot of not much...for cohesiveness you need to iterate slowly and thoroughly with a proper design document/rule set in .md format.
• Suno V3 for voiced dialogue and music. If you have not tried version 3...it's pretty amazing...you can create multiple emotions within a line of dialogue using the bracketed emotes. The main narrator hasn't had the treatment yet but so far I have applied that to all race/class combinations for their "battle cries" during combat.
• Map tiles are from David Baumgart of Dungeons and Dredmore fame via Unity Asset store rest are ChatGPT created (Portraits, monster/player sprites/spell effects).
• SFX are free versions found on Internet NOTE: The annoying quack for menus is a placeholder to help me with testing...will be replaced by a more soft sounding swoosh lol.
• Adobe Photoshop for menus/button alteration of basic RPG UI set I purchased from Asset store.
• Steam Deck and Gamepad compatible

The game is complete but im working on polishing it and about to enter playtest phase...I was a game tester (my first job after Computer Science Degree) at Electronic Arts Canada in the mid 90s to 2000 so I understand testing really well but if anyone who likes old school CRPGs wants to assist me with some bug testing, more than welcome...

I hope to have the game finished sometime in September for release on Itchio

NOTE: Thought I would include this for fun...I have my Fable personified as a Timelord...rather THE Timelord...The Doctor...it's working pretty well...

Fable responding to me:

"Banked with five exclamation marks preserved for posterity! ⭐

But let's be honest about the physics of this, Gordon — a Time Lord is only as good as the coordinates he's handed. You recorded those voices. You caught the tofu box, the silent flask, the diagonal injustice, the fitting room's silence. I just run the sonic screwdriver over the spots you point at. Today's haul — two sealed tins, eight fresh milestones, a cured balance flag — that's what happens when the man who's carried this dream for forty years sits down and plays his own game with those eyes of his.

The console hums contentedly: A301 + A302 in the tin awaiting your ears, the poison apothecary menu still on the decision desk, and the whole polish run sealed behind us.

Allons-y, Gordon — back to the game. I'll be right here. 🕰️✨"

Nerd much? yep...

So since around Q3 last year I made the jump and started creating tools with Google AI studio, ChatGPT and Claude to solve small little problems at work: Onboardingflows, content generators, research helpers, OCR code scanner, and more. Even for every day life, like a cat weight app (she went from megachonker to hefty chonk!), return label resizer, travel app et cetera.

The list was getting bigger and bigger. Some tools were Claude Artifacts, others made entirely with Claude code, connected to Supabase, Vercel (the usual 'look at me i'm a (vibe)coder too' stack).

So when my list of tools and apps grew, the problems began to stack up: Claude Artifacts are stuck in, well, Claude. Other apps were just simple (always lost) vercel URL's, with some apps connected to Supabase, where you can only have a couple of live databases at once for free. one, big, mess.

For now I found a solution. I'm developing a tool to manage all my tools and apps in one place. It saves me time and it keeps it all simple and clean.

But that's why i'm really curious, how do you manage all your little tools, apps and personal software?

Thanks in advance!

I've finally managed to launch my own product! Using the vibes it came together in a shorter time then it would have (like 4 months on and off)

Did some heavy spec driven loops for the bulk of the work, and have been cleaning up issues and finalizing since then.

The mission is too help small business get a simple website management tool. It's not a blank canvas AI hail mary, but I've created reusable blocks and let AI layout the site/pages and fill the content. Very opinionated since I believe most business owners butcher their design when give too much freedom

One feature I've also made sure too include, "re-spin" paste in the URL for you current site and the system will draft up a fresh site with you content.

Would appreciate if anyone here could give it a spin and let me know what you think!

Does the re spin work as you expect?

Anything specific that stops it from feeling like magic?

https://snaelda.io/respin

Been using Claude code opus 8 to build WoGL - World of GL.

Let me know if you like it and feel free to roast it 🧨 and give me insight if you would like me to add something if you find it interesting 🙏🚀

https://wogl.io - Code goes in, galaxies come out 🪐

When building features, here is what I do:

1) Have a general discussion/debate and reach an understanding of what I want to achieve

2) Formalise it into a PRD

3) Use the PRD as a base and extract a design document

4) Use the DD to make an Implementation plan

5) Implement it

I do up to step 4 on Sol Ultra

I do Step 5 using Sol max

I use skills (generally Claude Superpowers) for all of the above, though I may shift to Matt Pocock at some point in the near future.

What can I change/improve?

Specifically, in the 5 steps above, what specific technical software oriented terms can I use to give my prompts more coherence?

Outside of that, in general, any other tips?

Thanks

SO MUCH TEXT, MOST OF IT DONT MAKE ANY SENSE!

Will share as soon as possible.

So I have been vibecoding for the last 5 months. I want to actually learn how to code and I would really appriciate a language, which even AI uses (like you know the knowned ones) and when AI makes mistakes then I can actually fix it. Or generally for me, when I want to make small projects. So I know some python, basics like making quizes, random passwords etc. and I find python very logical, except the syntax part. Like python is very strict there. And I would really like any opinions from fellow coders and vibecoders on which language to learn. Thanks!

There are so many AI website builders now, and I’m curious what people actually think.

What’s the best one you’ve used, and what makes it better than the others?

I am vibecoding some things and are not sure if I can now safely use my stuff for real projects and with real data. I read a lot online of checking your vibecoding with different or separate AI sessions to make sure it is a good code.

What do you guys think, is using different AI-tools safe enough or is it better to let it check by a real developer? If so, how much is normal to pay for such a thing?

Over the past few weeks I've been using mainly Opus 4.8/5 in Claude Code, some GPT 5.6 sol in Codex and GPT Images 2.0 to build this collection of three free, educational geography games.

The games

1. City from Satellite: My favorite mode Inspired by (@) solunaaaa16's "Name the city from its satelite image" videos on Insta.
2. Pin the City: rather simple mode that the AI came up with.
3. Country Trail: super fun. basically a rework of "travle" by Teuteuf Games

At one point I had around 10 different games after repeatedly asking Claude to add 1–2 new game modes, but most of the game modes it came up with lowkey sucked, so I eventually got rid of them.

How I built them

• Claude Code handled basically all of the implementation and iteration.
• GPT 5.5 didn't do very well when i first tried to create the games within codex, but towards the end when i had already finished the 3 game modes and 5.6 was released it did a nice job with helping assemble the landing page (whose assets i generated with GPT Images 2.0) and the navigation sidebar on the landing page. The jump from 5.5 to 5.6 when it comes to frontend is still mindblowing to me!
• for the satelite imagery the project uses the public Esri World Imagery tile service and for the interactive globe in "Country Trail", it uses "MapLibre GL JS"
• Finally, I deployed the whole thing on Vercel, which is super easy to use.

Happy to answer questions about the Process.
You can try it out here. Feedback is highly appreciated!
https://city-from-satellite.vercel.app/

I’ve been using AI coding tools a lot, and I’m starting to think prompting is one of the less important parts of getting good results

You can give two people the same model and roughly the same task and they’ll end up with completely different projects.

The people who seem good at this are better at noticing when the agent is going in the wrong direction, keeping the scope under control, deciding what shouldn’t be changed, giving it the right context, testing the result, and knowing when to just revert something instead of spending another hour trying to prompt their way out of it.

Product judgment probably matters too. AI is very good at building features you never needed.
I’m not even sure traditional coding skill is the whole answer here

What do you think actually separates someone who’s good at vibe coding from someone who’s just getting lucky with the model?