DEV Community: Diego Dotta

Cloudflare Built EmDash. I Built NeighDash.

Diego Dotta — Tue, 29 Sep 2026 19:40:11 +0000

Hello World, Goodbye PHP

The first post on this blog is dated 1999 and says, in its entirety, <?php echo "Hello World" ?>. This month, twenty seven years later, the blog finally stopped running PHP. That is a very long hello (and an even longer goodbye). In 2004 WordPress made my life as a "blogger" a lot easier, and it carried this blog for more than twenty years, so this isn't a breakup post (okay, it's a little bit of a breakup post).

The Stable Wasn't Stable

All my sites lived on one Namecheap shared server called premium52. This blog, The Sunrise, Smart Keys, Fireflow, teatime.london and three smaller ones, all sharing one machine with who knows how many strangers. For years that was fine. This summer TLS handshakes started taking 20 to 30 seconds, and every now and then the whole box went dark for an hour, taking every one of my domains down at the same time. By the time I started, Fireflow was answering HTTP 520 to anyone who knocked.

The satisfying part was proving it wasn't my fault (a rare feeling, I recommend it). From an SSH session on the server itself, fetching a static robots.txt from its own IP still took 20 to 30 seconds to shake hands, while my account's CPU and memory usage sat at roughly zero. The incidents in UptimeRobot lined up to the minute with the traffic collapsing in the access logs.

"Keyword has not been found" is UptimeRobot's polite way of saying Cloudflare showed an error page where my site should be.

A static site on Cloudflare has no origin server to fall over. So the fix wasn't tuning the server, it was not having one anymore.

On diego.horse this is a little toy you can click: it sends the same request to the old host and to the new one, with the delays we measured.

The timings on both sides are ones we actually measured. The odds of getting a good day, a slow handshake or an error page on the old server are my guess (a generous one, looking at that UptimeRobot list).

WordPress, We Need to Talk

To be fair to premium52, it only gave me the final push. WordPress and I had been drifting apart for a while.

Me, halfway out of WordPress, galloping anyway.

My inbox had a steady drip of Wordfence emails about someone, somewhere, trying to break into my WordPress. Getting regular reminders that strangers are rattling the door handle of a personal blog does wonders for nobody's nervous system.

Then there were the plugin updates. I got burned badly by automatic updates in the past, so I turned them off and started updating by hand, reading every changelog first like a terms of service I actually intended to honor. I don't miss a single one of those updates I was too scared to click. That's a lot of babysitting for sites I update once a month, twice on a busy one. None of them really needed a CMS (they needed a place to keep the files and someone to hand them out).

WordPress also brought a lot of friends to every page, scripts and markup I never asked for, and changing the layout usually meant fighting the theme with !important until one of us gave up. Now the pages carry (mostly) only what they need, and when I want something to look different I just change it.

And then there's the drama around WordPress itself, which I got tired of following like a novela I never signed up for. Its co-founder Matt Mullenweg runs Automattic, the company behind WordPress.com, which has been in court with the hosting company WP Engine since 2024. This month Automattic's board tried to put him on leave, and he used his 84% of the vote to undo it in about 33 hours. Then he rebuilt the board, with two of the new seats going to co-founders of IRL, the social app that shut down after it turned out nearly all of its users were bots. I don't have a horse in that race (okay, I have exactly one horse, and it's this blog), but I'd rather my sites not depend on how the next episode goes.

Money was never really the point, shared hosting is cheap. But it was another service to keep an eye on, plus a support center I'd have to chase whenever things stopped working, and I'm happy to have one less of both.

Meanwhile, at Cloudflare

In the same month, Cloudflare moved its own blog to a new CMS running on Workers. They call it being Customer Zero, running your own products before you ask anyone else to. They load tested it with k6 up to 7,000 requests per second, rolled it out through a proxy Worker at 1%, then 5%, then 15%, then 100% in a single day, and later absorbed a 28,000 requests per second DDoS during Agents Week without blinking (InfoQ has a nice summary).

The CMS they built is called EmDash, which feels a bit personal since the style guide for this blog completely bans the em dash. As an ESL learner, I never understood the em dash anyway.

My version of Customer Zero is Customer Zero Dollars, the Workers free plan. My traffic peaks at a few requests per minute on a very good day, so my load test was opening the homepage, and my gradual rollout was deleting two DNS records. On smartkeys.so the script backed them up, deleted them and attached both domains to the new Worker in 1.3 seconds, ready to put the old records back if anything failed. There was no 1% cohort and no cookie routing, everyone got the new site at once, including me, who is honestly most of the audience.

I'll be honest, I think my approach is better (for me, and I'm very biased). EmDash is a proper CMS, with an admin, scheduled posts and a database sitting behind two layers of cache, which makes total sense when a big team publishes to a blog read by millions. My sites have one writer who publishes about once a week, so there's nothing to put a cache in front of, because there's nothing behind it. Every page is rendered before anyone asks for it, and most visits never even wake up the small Worker that takes care of old links (more on that Headless Horseman below). I'm calling it NeighDash, a Stable Site Generator. (For my ESL friends, neigh sounds like nay), nay dashes, nay CMS, nay dashboard, nay logins, nay database, nay headaches, and it's stable in a way my server and wordpresses never were.

Meet the Headless Horseman, NeighDash's only moving part. He rides out when an old link calls, and the rest of the time he just stands there looking dramatic. A 25 Pfennig note from Berga an der Elster, 1921, via Wikimedia Commons (public domain).

It isn't without trade-offs. Fixing a typo now means making a git commit. Still, having multiple people update content is like a dev team working on the same project, you get backups, change logs, and version control for free.

Most of what I expected to miss has a static answer, by the way. Comments can live in GitHub Discussions or a tiny Worker, and scheduled posts are just a daily build that publishes whatever is due (the robot read the docs, both fit in the free plan, neither is built yet).

The real trade is ownership, and it's the part the "just go static" crowd never mentions. WordPress's superpower was never the editor, it's the plugin ecosystem, where someone else builds, maintains and patches every feature for you. Here, every dynamic thing I add becomes code I own, with its own spam and security updates to worry about. The owners of the smaller sites I moved can't edit them on their own anymore either, so in practice I'm their CMS now (a slow one, with opinions). For sites that mostly exist to be read, that's a great deal. The day I want logins or a shop, I'm building an app, and that's a different conversation.

The robot did the heavy lifting

I did the whole thing pair programming with Claude Code, the same way I built QWERTYS, except this took from August 4 to the end of September instead of a week. The agent worked out of a repo called cms-agent with a handoff document called CONTEXT.md, so any fresh session could pick up exactly where the last one stopped. It holds the mission, how to reach every server and API, the decisions that were locked, and a numbered list of hard won learnings that is now 29 items long. Reading it feels like reading the diary of a very organized intern who has been burned a few times.

Every site got its own private repo, plain HTML and CSS, deployed by a push to master. The small ones were rebuilt fresh as clean static pages. teatime.london was already static, so it was a straight lift and shift. One of them wasn't even WordPress, it was a Namecheap Website Builder site whose entire content lived inside a SQLite file on the server, so the agent rebuilt the pages straight from the database (a website stored in a database file, stored on a server that kept disappearing, what could go wrong).

The big two got more care. The Sunrise has 136 pages and this blog has 251 posts. Both went from WordPress to Markdown files and a small Python build script, with Pagefind doing search in the browser. The uploads folder here was 901 MB, but only 341 files were actually used by a post, and they are now 141 MB of WebP. Every old URL still works, including tags, date archives, ?p= shortlinks, the feed and even the old /wp-content/uploads/ image addresses, because Google Images and itch.io still link to them.

So this post is a text file in a git repo. Publishing it means deleting draft: true and pushing.

I was already writing pretty much everything else in Markdown, so leaving the WordPress editor for .md files felt more like coming home. It turned out even better than I expected, because now I can ask Claude to review a draft or change a few things, and every edit shows up as a diff that I approve or throw away in git (yes, including this post, which is a bit meta).

And the agent made itself mostly unnecessary, which is my favorite kind of employee. It left behind a script that pre-renders the whole site and optimizes every image, and each repo is connected to Cloudflare Workers, so a push to master builds and deploys on its own. In theory I don't need the agent anymore (in practice I'll keep bothering it, old habits).

Here's how the pieces fit together for this blog, the biggest of the eight.

No database and no server of my own, and nothing to update at 2 a.m. The only moving part at request time is the small Worker.

Two months, Diego. To move websites that were already online.

– The responsible adult who lives in my head

In my defense, it took two months because it was never the priority. It happened in the gaps between other things, and I wanted to be present for it, reading the decisions the agent made instead of waking up one morning to eight websites I no longer understood.

Things we got wrong along the way

The agent is very good, and also very capable of doing something dumb at full speed. A few highlights from the learnings list.

Roughly how it felt when the first deploy published the .git folder. From *The Virginian, via GRIT.*

The first deploy published the .git folder to the internet. Workers static assets serve the whole folder you point them at, repo history included. It was caught on the first site and every template now ignores it.
A compiled Python file went live on one site. A __pycache__/check.cpython-312.pyc sat there, publicly downloadable, with the local path of my Mac baked into it. A MIGRATION-REPORT.md was one merge away from the same fate. Now every repo ignores whole classes of files instead of a list of names.
It merged to master twice without asking. On these sites a push to master is a deploy, so it's supposed to be a decision, not a side effect. The second time was right after I had explained why not to. It now has a standing rule in its memory, work on dev and ask before anything goes live.
The biggest performance drag wasn't WordPress, it was Cloudflare. On Fireflow, Bot Fight Mode was injecting a challenge script that cost 1,309 ms of main thread work, about six times what Google Analytics cost. That was my own little Customer Zero moment. And switching it off in the dashboard leaves the JavaScript part on, so you have to check twice.
The cache lies, in both directions. After one deploy, five identical requests came back old, new, new, old, old. A single curl will happily tell you the deploy worked while most visitors still get yesterday's page.
The Worker was spending the whole account's free budget on images. Cloudflare's free plan gives an account 100,000 Worker requests a day, shared by every site, while plain files are free and unlimited. My setup sent every image and stylesheet through the Worker, about ten requests per page view, so two small sites used 31,000 on an ordinary day. A post like this one getting shared could have taken them all offline until midnight UTC. Now the Worker only wakes up for the few old links that need it (the Headless Horseman, again).

Every one of those mistakes became a rule or an automatic check, which is the part I'm proudest of.

The numbers

The agent ran Lighthouse three times on each side and kept the median, after one early single run produced numbers that were pure noise.

Site	Performance score	Requests
diego.horse	55 → 80	323 → 13
thesunrise.org	58 → 72	41 → 23
fireflow.cc	96 → 99	11 → 12

Lighthouse mobile, median of three runs on each side. This blog's homepage used to make 323 requests, now it makes 13.

On this blog the first paint went from 15.5 seconds to 1.7 on a simulated mid range phone (the homepage has different posts on it now than in August, so take the exact figure with a pinch of salt, the direction is not in doubt).

Same Lighthouse setup on both sides, captured August 21 and September 28.

The scores didn't land there by accident. After every deploy the agent ran Lighthouse (and PageSpeed Insights, the same engine in Google's clothes) and worked through whatever it complained about. On this blog the Substack newsletter embed was quietly loading Datadog, Sentry, Google Ads remarketing and about 130 other files on every page, and now it waits until you scroll down to it. The 60 pixel avatar in the header turned out to be downloading a 1,600 pixel image. The theme's CSS went from 134 KB to 58 KB, with before and after screenshots of 22 pages to prove nothing moved. On Fireflow, it even found that the brand colors inherited from the WordPress design failed the contrast test, something I had not been paying attention to at all.

PageSpeed Insights for this blog's homepage on desktop. On the simulated slow phone it's the 80 from the table above, but let me enjoy the four circles for a minute. There's also an Agentic Browsing category now, and the robots gave it 2 out of 2.

Smart Keys is the fun one. The standard script said the new site got worse, 69 down to 56, with a 10 second Largest Contentful Paint. Instead of shrugging, the agent chased it and found a one second delay before first paint that only happened when Lighthouse launched Chrome itself, and that nothing on the page caused. Lighthouse's slow phone simulation then stretched that one second into ten. Measured with the same setup on both sides, the store page went from 54 to 89 and server response from 537 ms to 117 ms. Lesson learned, believe the observed timings over the simulated ones when they disagree.

And the most important caveat is in the robot's own words. The "before" numbers are best case, because they were captured when the old server happened to be answering. The honest summary is not that the old sites were slow, it's that they were "unpredictable, and sometimes down." No Lighthouse score has a column for "there was no page."

The carbon rabbit hole

The reports also cover energy and carbon, and this is where I got more than I bargained for. The standard model (the one behind websitecarbon.com) works from bytes transferred, so for this blog it says 0.71 g of CO₂e per page view before and 0.05 g after, a 93% cut.

Sustainable Web Design Model v4, which only looks at bytes transferred. An estimate, and the robot was the first to say so.

Then the agent argued with its own number. That model multiplies bytes by a constant and never looks at how hard the phone actually worked. Measuring main thread time instead, the honest saving on a visitor's phone here is more like 73 to 78%, and on Fireflow it was only 35 to 55%, shrinking as connections get faster. For the old shared server it estimated my slice of a 64 core machine running around the clock, and then immediately pointed out that Namecheap's server doesn't power down because I left, my share just goes to the neighbors.

Then it counted the cost of the migration itself. The biggest term was the AI inference, somewhere between 50 and 1,000 Wh for the first site alone, with no way to measure it from my side. Its conclusion is my favorite sentence of the whole project:

Quantifying the carbon consumed more energy than the site's network saving will recover in a year at low traffic.

It also wrote that this was never a carbon decision, because the site was down, and that presenting the carbon saving as the reason would be backwards. I've read a lot of sustainability pages from companies ten thousand times my size that were less honest than that (and it came from the thing burning the most energy in the room).

Still, I want to believe it pays off in the long run. The migration cost was paid once, and the lighter pages save a little on every single visit for as long as these sites stay up.

Want to try it?

I packaged everything the robot learned (the playbook, every trap, the templates and the scripts it wrote along the way) as NeighDash, a free and open source Claude Code skill: github.com/diegodotta/neighdash.

Not technical? Open Claude Code (the desktop app is the friendliest way in) and paste this, with your own address:

Help me move my website example.com off WordPress and onto Cloudflare using NeighDash (https://github.com/diegodotta/neighdash). I'm not technical. Read the repo's skills/neighdash/SKILL.md first, explain each step in plain words before doing it, do the typing for me, and ask me before anything that could take my site or my email down.

It will still need you for the parts only a human can do, like creating a free Cloudflare account and clicking "allow" when a login pops up. The rest is the robot's job.

Already using Claude Code? Two lines and your agent knows what mine had to learn the hard way.

/plugin marketplace add diegodotta/neighdash
/plugin install neighdash@neighdash

Using another agent, or curious about what's under the hood? Here's the prompt I'd start with today, knowing what I know now. It's the short version of those learnings (you'll find new ones, that's the fun part). Swap the bits in brackets for your own.

I want to move my WordPress site off shared hosting and onto static HTML served by Cloudflare Workers on the free plan. You're doing the migration with me. Work in small steps and ask me before anything that is hard to undo.

About the site: [domain], hosted at [host], SSH access [yes/no], DNS [already on Cloudflare / elsewhere]. I update it about [once a month] and nobody else edits it.

1. Start a handoff doc, CONTEXT.md, with the goal, how to reach everything, the decisions we lock in and a numbered list of learnings. Keep it current so a fresh session can pick up where the last one stopped.
2. Before changing anything, run Lighthouse three times on the live site and keep the median, so we have an honest "before".
3. List every URL the old site answers: posts, pages, tags, date archives, feeds, ?p= shortlinks, sitemaps and /wp-content/uploads images. Check the access logs for URLs other sites and apps link to. Every one must keep working, as is or as a 301.
4. Convert from the rendered pages, not the raw database content. Small sites become plain HTML and CSS. A blog becomes Markdown plus a small build script, with Pagefind for search.
5. Convert images to WebP at the sizes they are displayed. Keep originals out of git.
6. One private GitHub repo. Only a build folder (dist/) is ever published, never the repo root, so .git, notes, scripts and secrets can't leak.
7. Deploy with Workers static assets, connected to GitHub: work on dev, pushing to master deploys. Never merge to master without asking me. Add a check to the build that fails the deploy when something is wrong.
8. Write a script that requests every old URL and checks the answer. Run it on wrangler dev and on the workers.dev URL before we touch DNS.
9. Cutover: back up the DNS records, delete only the apex A and www CNAME, attach the custom domains, and put the records back automatically if that fails. Never touch MX, SPF, DKIM or DMARC.
10. After: purge the cache and confirm with several requests, not one. Check that Bot Fight Mode and its JavaScript detections are both off. Rerun Lighthouse with the same setup, fix what it flags, and check visual changes with screenshots, not status codes.

You'll need Claude Code (or any agent that can run a terminal), a GitHub account and a free Cloudflare account. The Cloudflare MCP server helps a lot for the DNS and account settings, and the agent can set it up with you.

What's left

The Namecheap plan is cancelled and premium52 is officially someone else's problem. There's still some housekeeping on my list (there always is, a migration is never really finished, it just gets quieter). And yes, this blog still uses WordPress's Kanso theme on purpose, it's kind of nice. Still, the redesign may come next (or never).

Cloudflare ended their post inviting everyone to try EmDash. My invitation is smaller. If your WordPress site gets a few visits a day and mostly exists so people can read things, you probably don't need a CMS at all. You need a folder of text files and someone patient enough to move 251 posts into it. Mine never complained once, it just kept a very long list of everything that went wrong.

Originally published on diego.horse, where the charts and the little race are interactive.

Same experiments, two very different apps. What the data actually said.

Diego Dotta — Mon, 01 Jun 2026 19:46:49 +0000

I have two indie apps. Smart Keys (smart keyboard for ESL writers) and Bird Rise (an alarm that wakes you up with birdsong). I ran the same marketing experiments on both, same budget, same channels, same broke operator. The results split wide enough to be useful.

Experiment 1: paid acquisition

Smart Keys: LTV/CAC barely 2, download-to-paid around 3%

Bird Rise: LTV/CAC topping 3, download-to-paid north of 6%

Experiment 2:

hard paywall A/B (read a RevenueCat report claiming small apps can pull this off, didn't believe it, tested anyway)

Smart Keys: flat no
Bird Rise: early read says it actually works

What I took from it

A metric on its own is just a number begging to be optimized. The same metric next to a wildly different app stops being a dial and becomes a verdict on the concept. You don't learn the shape of something by staring at it, you learn it by holding it up next to whatever it isn't.

There's no transferable playbook. Only the version you test on your own thing.

If you want the long version with charts, the Ritual × Tribe framework I built to explain the gap, and an uncomfortable chart asking whether the money would've done better in an index fund, full post

Surviving an Apple "Sherlock" and a 12-month cash burn

Diego Dotta — Thu, 05 Mar 2026 12:19:25 +0000

What do you do when you spend months building an AI-powered iOS keyboard to proofread text, and then Apple announces native proofreading in iOS 26? You panic, joke that Tim Cook is stealing your ideas, and then you adapt.

I just published a 16-month retrospective on building my app, Smart Keys. It started as a basic WordPress site using ChatGPT prompts and evolved into a full iOS and MacOS tool for text transformation.

The biggest technical and product takeaways:

Platform native is hard: The iOS ecosystem is tough for acquisition, but building the MacOS version actually became my personal favorite (even if I have no idea how to market it).
Retention over Acquisition: We burned cash for a year with a low ROAS. But because our Month 4 retention was >60%, the math eventually flipped in our favor.

I wrote a detailed breakdown of the development journey, the failed marketing experiments, and how I finally reached profitability without taking VC money. You can read the full architecture and business teardown on my dev log: diego.horse

My No-BS Building Process

Diego Dotta — Tue, 03 Feb 2026 19:44:15 +0000

Most people talk about building like it’s about speed. Ship fast… move fast… break things… Really?

The longer I’ve been building stuff, the more I see that the real work happens before anything actually ships. That quiet, slow phase where it doesn’t look like much is happening yet.

I have read many books about creating a startup, product iterations through experiments, finding market fit, and leveraging viral effects. They share a playbook that might work (or pretend to work) in the VC world.

The thing is, the indie-solo-bootstrap reality plays a different game from the silicon-valley-BS-unicorn fantasy. The good news is that there are many great books and resources available for those dreaming of a lifestyle business.

The spark to find my process came from one the first chapters in the MAKE book. It’s a good book for someone who wants to start building things and has no idea where to begin.

As a big fan of the Go Horse methodology, I tend to go straight to the building step. And that’s no good. That was the reason I decided to prioritize more the planning and research steps more in my life. And I wanted to build things that matter. Or at least, things I care about enough to finish. I realized that having a clear path helps when you’re stuck in the “what should I build” loop.

So here it is: my secret building process.

Celebrating and crying are important parts of it.

Let’s start with the first one, which is actually creating a list. From now on, I love lists.

1. My top problems

Spend a couple of weeks simply listing the problems in your life. (If you don’t have any problems, try making your life a bit more interesting stepping out of your comfort zone)

The Secret: Just write them down. Don’t worry about fixing them yet. It’s harder than it sounds because our brains want to jump straight to the solution. Try to resist that. Just let the problems linger and bother you.

When you’ve got a solid list, rank the stuff. Be real about what actually makes your life miserable and what’s just small annoyances you complain about. Keeping it simple is best. I tried a fancy decision matrix once, but it was way too much work and didn’t help much. Just going by the order of the problems worked best.

I’m still working through some things from my list from three years ago. But yeah, it’s a list that I occasionally add new items to. As you can see, there are various problems, such as the desire to write more or eliminate hair in unwanted places. 👙

I spend around 2 weeks and come up with 20 items. I’ve used Notion, so I could later document the next steps and status.

2. Solve them (without building anything)

Start by addressing the first item and look for possible solutions that already exist. Test them. You may actually find a product that solves your problem perfectly. If so, congratulations, you just saved yourself months of work. Job done. Move to the next one.

The secret: I was pretty amazed that just by switching up my habits and pushing myself out of my comfort zone, I fixed a bunch of problems. I started a 5-minute-a-day workout (which felt like a lot since I’m usually pretty inactive), and that kicked off a chain reaction, helping with stuff like back pain and improving my sleep.

I also began volunteering at local non-profits, which really helped my networking. And the best part? It didn’t cost me a thing and didn’t involve any tech.

Three years later, most of the items are done, and I feel it’s time to go back to step one again very soon.

By simply adding a status to the list, I was able to track them easily.

3. Market research

Alright, now the real game starts. If you didn’t find a solid fix for a big problem, your experience testing existing solutions earlier will help you see what’s missing. Here’s where most people go wrong, don’t start building just yet. Check out some marketing numbers first. Use SimilarWeb or SensorTower to gather some data about the players.

Check-in: I prefer a market with big players, either in revenue or traffic, hitting millions a month. I’m a bit cautious about untapped markets. This probably isn’t the best problem to tackle while bootstrapping. I think I need to be really excited about the project to decide to keep going.

The secret: By the way, being excited is a huge part of my process because building something is tough. There will be lots of times I’ll want to quit, so that excitement has to push me forward during those moments.

4. Now it’s your time to shine

Now that you have a good idea of what you want and what the market looks like, split your time in two. If you are a product person, really force yourself to spend more time on marketing, and the opposite for marketing folks.

4.1. Test the market

This next step totally changed the game for me: run ads and use simple forms to figure out acquisition costs. Getting users’ emails also helps you build a list of beta testers to stay in touch with. And yeah, you gotta talk to people dealing with the same problems.

Marketing Requisites: You have to spend money here, there’s no way around it. Someone who tells you otherwise is trying to trick you into buying their stuff. If you’re not willing to pay to find customers, either this problem isn’t that big a deal to you or you don’t really believe in your idea.

Tip: Last time I did this, I ran a Meta campaign using their Lead Online Forms. I tested my idea against 3 others to compare CAC and ended up finding another opportunity. Check out the Bird Rise story.

4.2 Build an MVP

While your ads are running, you can start building. This should answer technical questions and solve your specific problem. Keep it small and meaningful for now, because in less than six months, it will surely become a little monster with all the features added from user feedback.

Tech Requisites: Be careful with the scope and tech stack. You don’t want to build something that requires high server costs or maintenance.

Use your own product. Remember, this came from your list of top problems you wanted to solve in your life. But try not to fall in love with your idea. Fall in love with the process of solving problems. Share your MVP with those first people from your initial Ads. Do the adjustments based on their feedback. You will have bugs. Many bugs. If users are not reporting bugs, you are not hearing them. It is hard to get good feedback. I still struggle here.

Check-in: While you’re going through this, you might realize your idea isn’t really fixing the problem. Technical issues pop up. CAC might be too high. The problem could be trickier than you expected. This is a good time to pause and think about whether you want to keep going. Quitting now isn’t a bad thing. It’s actually pretty smart. It saves you from wasting months on something that a solo person or small team can’t crack. Just go take a shower and have a good cry.

5. Launch

I fixed all the bugs, adjusted the product based on early user feedback, and developed a decent version of the marketing strategy. Now it’s time for a reality check. What I want to figure out now is the real cost to attract paying customers and how much they’ll actually value my product. That way, I can get a clearer idea of whether this product will be sustainable or if I have enough money to keep it going.

The Secret: My go-to plans are short- and long-term subscriptions with a 3 to 7-day trial and lifetime discounts. This approach allows me to account for some costs related to the trial (CPT) preety fast and generate some revenue from lifetime discounts.

I like weekly plans as an anchor for other plans and as a way to measure if the product is good enough. In a month or so, I should have a better idea of retention based on renewals.

There will be many iterations here, from onboarding to pricing. Be patient before making major changes and try to get a good volume of users first.

How about growth hacks, virality, and organic strategies, Dieguito?
– Your Favorite VC

Sorry, but I don’t trust organic growth as the main strategy (yet?). With the flood of AI-generated apps, welcome to the bloody ocean of the app market.

Apple and Google wouldn’t surprise me if they start charging per app published instead of by developer account. The only people who don’t like paid acquisition strategies are VCs, they love to hear zero-marketing budget BS.

6. Measure

The most important metrics for me are CAC related: CPT (Cost per trial), CPS (Cost per subscription) and ROAS. That is it. Retention, Profits and LTV are critical, but they take a while to measure meaningful data. You will change prices a lot until you find what works.

Good tools to help you with that are Mixpanel (connected with the Meta API) and RevenueCat.

Smart Keys Dashboard

Check-in: From those numbers, do another check-in. Scaling ads while bootstrapping is tricky and can get expensive quickly. Proceed with caution. You can see the blue line rising faster than revenue in the first chart. Six months later, I reevaluated to make the ad spend more sustainable.

What about Experiments, weren’t you the king of A/B Tests?
– Your Favorite Scientist

First off, I’m not the king, maybe more like the Prince 💁‍♂️. I used to get super excited about experiments, especially the chance to discover something novel. I spent tons of hours designing, coding, and running experiments, sometimes with awesome results from tons of data points. But the weirdest part was that when we rolled out the experiment to all users, we didn’t see any change.

What was probably happening was a lack of statistical power, which is a major issue in science itself. People often talk about statistical significance, but that’s really just an agreement that the result is unlikely to be due to chance, unlikely… unlikelly.

Another thing to think about is what you actually measure. Experiments should ALWAYS be judged by the final metric, which is REVENUE. Tweaking middle metrics like signup rate or onboarding steps doesn’t always affect revenue. Sometimes a big jump in signup rate doesn’t do anything for revenue (I’ve even seen it go down 💸)

The Secret: So, when I start a new project, I usually don’t have the cash, team, or tons of data to run experiments. These days, I’m more into getting ideas from behavior construts that big companies have already tested a lot, like social proof, authority, commitment, scarcity, and so on.

10. Scale (or not)

Welcome to the real world, you’re now a real player in the market. Scaling means you’ll be up against those big players you checked out months ago. Your campaign performance won’t be the same with your small budget. You’ll probably need more creatives, get more support tickets, and messing up your server or introducing a bug could disrupt thousands of users (While I’m writing this, I’m waiting for Apple to approve a bug fix for a version I messed up, and now users are stuck.).

I consider it actually a good success if you can deliver a good product but can’t scale during the first months. You solved your own problem and helped other people solve theirs. Scaling takes time and requires good cash flow.

The Secret: If you’re going solo, find a buddy to do a bi-weekly check-in with. I’ve been doing this with a friend who’s also building stuff. Sharing progress and struggles helps keep you accountable and gives you new insights from another perspective.

The truth: This part of the process is still a work in progress, and I’m not totally sure I cracked the secret here. Either way, whether you managed to scale or not, it’s probably a good time to take a shower and have another cry.

That’s it

This is a live process. It involves some iterations and may take time. It has evolved since I read the nudge from the MAKE book that if your list of problems is small, you should make your life more interesting. I signed up for the 540-mile bike ride from SF to LA, which brought me beautiful problems to solve.

For Smart Keys, I followed most of the steps above. However, I admit that in other projects, I skip some parts I don’t like much, such as properly testing the market.

Air Fiesta is a very poor example of a project that failed on many levels. It started by not addressing any of my problems, was technically complex, had a huge scope, and I did inadequate market research. I did it simply because I had free time and was excited about building a game using the Google Maps SDK related to a cause. I even added to my list of problems just to justify its development: “I want to create games again.” 🥸

But I am trying to be better at it. Bird Rise was actually a pivot inspired by insights during the market test. And Air Fiesta and other tiny games actually brought a main insight about using games as a marketing tool. So maybe I am learning something after all.

Tiny Games, Big Feelings

Diego Dotta — Sat, 22 Nov 2025 00:36:56 +0000

Everything actually started when I played Loneliness. What a strange, quiet punch of a game. I wasn’t expecting much (it’s just little squares on a white screen) but somehow it managed to pull more emotions out of me in two minutes than most AAA games do in fifty hours. I walked away confused and weirdly emotional, like someone had whispered something important into my ear and then vanished.

So of course I did the only reasonable thing: I became obsessed. I hunted down the creator, Jordan Magnuson, and ended up reading his book Game Poems, which didn’t help at all because now I’m even more obsessed.

The whole idea that games can be short, intentional emotional gestures suddenly made sense. Then I stumbled upon URL Snake, this tiny absurd miracle living inside the URL bar, built entirely with Braille characters. I did what I always do when I find something tiny and clever: I became obsessed with its creator, Demian Ferreiro.

So on a sunny weekend, I decided to experiment with those ideas. The first result was Tiny Horse, a tiny creature leaping across my URL bar like it’s trying to outrun my unfinished tasks.

Then came Tiny Mario, who took the same microscopic canvas and somehow turned it into a full side-scrolling adventure powered entirely by Braille characters and misplaced confidence.

I actually built this second one in secret from Leandra because I was supposed to be working on a different project and not making games anymore. I kept two instances of Windsurf open, and whenever she walked by, I switched to the main project (she is the boss).

I was surprised that I could work on two projects at the same time, with one assistant coding some complex tasks while working with the other. Obviously, I was paying much more attention to the game though. ;p

They’re not big games. They’re not meant to be. They’re little moments. Digital haikus. Emotional blips. I build them fast, break them faster, and still feel strangely proud of them.

And you know what? While building and playing them, I kept noticing how these tiny games trigger emotions so quickly. Simple graphics, a couple of sound cues, and suddenly I’m laughing out loud on a Saturday night at 11 p.m. because I made Tiny Mario slip into an underground level through tiny pipes.

Besides being simple, they include classic casual game elements that spark some adrenaline: scores, countdown, enemies, rewards, obstacles, and elements of surprise. Something I haven’t been able to add to Air Fiesta yet.

If you want to see what all this tiny-game energy looks like:

Tiny Horse → https://diego.horse/jump
Tiny Mario → https://diego.horse/tiny-mario
Both projects are open source on my GitHub

And if you want to feel the thing that started all this:

Loneliness → https://jordanmagnuson.itch.io/loneliness
URL Snake → https://demian.ferrei.ro/snake

Game poems are small, but they hit hard, like tiny sparks pretending they aren’t capable of starting whole wildfires. And honestly, maybe that’s exactly what makes them beautiful… and powerful.

Nov 18th Update

I wasn’t expecting people to get this excited about a tiny game. I posted it on Product Hunt and Reddit just for fun and suddenly folks were actually into it. It’s not the kind of thing people usually share there, but I guess we’re all craving fewer AI products and more silly things like this.

Give it a vote if you feel like it. We already beat a Google product (which feels surreal and funny at the same time).

Air Fiesta: When the Balloons Multiplied

Diego Dotta — Tue, 28 Oct 2025 02:05:15 +0000

There was a time when everyone shared a single balloon. That was Airtales, one collective flight drifting wherever the crowd decided. Democracy by wind. Chaos by design. It was beautiful, but also… a little limiting. People wanted to explore their own skies. This is why it started and how it ended.

That’s how Air Fiesta happened, a pivot, or maybe a parallel universe. Now every player has their own balloon. You can float above your neighborhood, drift over famous cities, or join in festivals with friends. No borders, no passport required.

Underneath it all, it still runs on the same energy: curiosity, community, and a touch of absurd optimism that maybe the world makes more sense from 300 feet up.

Nature and weather conditions are your challenges.

What’s New

Air Fiesta is built on Google Maps SDK, so what you see is the real planet. You can tune into local radio stations while you fly (because every city sounds different).

You can take photos of your journey, discover hidden treasures, and battle weather that’s way less forgiving than it looks. Gusty winds, thermals, fog, even flocks of birds (the kind of chaos that makes you laugh right before it throws you off course).

And what about the balloon festivals? They’re still happening. They will probably change into something simpler. Right now, it’s a scavenger hunt with virtual friends. But it seems a bit complicated, so it will likely become more like freely collecting hidden gems.

One big improvement was the mobile experience. The game is still based on web technology (ThreeJS), which is tricky to run on mobile, but you can try it out on the App Store or Play Store. Coming soon on Steam.

Why I Still Care About Radio

Radio’s the heartbeat of Air Fiesta. I’ve always loved it, the crackle, the local ads, the DJs who sound like they’ve seen things. There’s something deeply human about tuning into a city’s voice while you’re hovering over it.

I’m reaching out to stations now, (community, college, indie, public) to ask permission to float them inside the game. Because I want players to hear the places they fly over, not just see them.

If you run a station, you can see a preview of what that looks like:
See a balloon radio in New York and another in the Bay Area. This is more like a non-interactive mode where you can “watch” other players.

Special thanks to Radio Browser technology for providing the geo-position of radios worldwide for free.

Where Air Fiesta Is Cancelled

Not everywhere is safe to fly.

Inspired by the Global Conflict Tracker and Freedom Flotilla, I mapped ongoing conflicts around the world: wars, occupations, humanitarian crises. The result was staggering. In those regions, Air Fiesta goes silent.

It’s not meant as protest or pity, more like a pause. When the world is burning, sometimes silence says more than scenery.

Maybe one day those places will light up again with music, laughter, and balloons rising together. Until then, the silence stays.

Feed and Gallery

Since Airtales has a feature that is quite unique (the camera), like a real balloon adventure, you can take pictures of your views. It’s no different here; people feel excited about doing that, so I keep it.

The improvement from the previous version is that you can now see pictures, messages, and other balloon interactions in a feed format.

What’s missing?

I think there are important pieces missing or not quite right. The story, for example, seems weak or almost nonexistent. Another important aspect is world-building. Currently, interactions with the world are almost zero. I think players should be able to build or change something in the real world. Right now, it’s almost like a ‘leave no trace’ approach, but it could be cool if they could move things around, clean the ocean, deliver letters, or even destroy borders :p

You can see follow the progress on Itch.io, for the first time I’m documenting the changelog there, it’s quite interesting.

The Sky Is the Limit

Air Fiesta isn’t about competition. There’s no score. No finish line. Just weather, music, and motion. It’s a little weird and a little hopeful, a floating experiment in what happens when you mix geography, sound, and strangers who want to explore together. This won’t trigger dopamine traps, and you won’t become addicted to it.

Maybe that’s the game I’ve always wanted to play: one where the world is the level, and connection is the win condition.

✈️ Play at airfiesta.fm or read the manifesto if you’re into that kind of thing.

Neuralese: The Most Spoken Language You’ll Never Speak

Diego Dotta — Tue, 06 May 2025 02:37:50 +0000

Somewhere between thinking and speaking, there’s a strange place where meaning starts to solidify. It’s not quite a word yet. More like a haze of associations. A mental sketch your brain tries to translate into something shareable. Sometimes it works. Most of the time it doesn’t, at least for me. I tend to mumble a lot.

That private language in your head, the one you use to talk to yourself, isn’t English or Portuguese or Python. It’s not even a language, really. It’s raw and messy. A kind of silent shorthand sculpted by experience. Try catching it. Try explaining it. It slips through like fog in your fingers.

This isn’t a linguistics paper. It’s a thought experiment about the strange, alien dialects spoken by machines, and what they might reveal about how we understand language, and ourselves. This is speculative. It’s not meant as a technical model of how LLMs work or how humans process language, just a meditation on how meaning can take forms we may never be able to speak.

The language of thought (According to machines)

Science is already poking around in there. Researchers are feeding brain signals into neural networks and getting fuzzy images back. They’re trying to reverse-engineer what we see, dream or remember. Some of the reconstructions look like fever dreams. Others are eerily close. It’s like watching the mind on a bad TV signal, but the tech keeps getting better.

AI re-creations of images based on brain scans (bottom row) match the layout, perspective, and contents of the actual photos seen by study participants (top row)

Then there’s the way we connect our minds to each other. Through letters carved into stone. Through cave paintings, vinyl records, emojis, GIFs, memes. Through every kludge we’ve invented to make what’s in here vaguely resemble what’s in there. Language is our duct tape for consciousness.

What the machines whisper when we’re not listening

When we started teaching machines, we handed them the same duct tape. Natural language. Our language. We told them, here, talk like us. So they did. Or at least, they pretended to and we believed.
Quick cheat sheet before we tangle the wires. There are three very different “languages” in this story (I can hear the linguists sharpening their red pencils):

Human languages: messy, culture‑soaked, built for wet brains and bad at precision.
Machine protocols (non-neural): JSON blobs, HTTP headers, rule-bound micro-dialects that leave no room for doubt.
Latent representations (neural): the private vector soup inside one model, never transmitted (outside a lab demo), never meant for ears.

ChatGPT. Alexa. Siri. Every chatbot trying to pass for clever at dinner sits in bucket one when it chats with us. But here’s the twist. When machines talk to each other, they skip the human stuff. No syntax, no grammar, no metaphors.

When Alexa calls Roomba they are not exchanging cute phrases. Alexa fires a strict micro‑dialect packet (JSON over HTTPS). That’s bucket two, a protocol, not a mind‑to‑mind vector swap. Efficient, silent, built for zero confusion.

Those packet‑speaking systems are narrow tools, nothing close to AGI. But we are already wiring up broader agents that learn on the fly, pick their own tactics, and only visit a language model when they need to chat with us. For talking to each other they could ditch words entirely and trade vectors, numbers, tokens, dense nuggets of meaning we can’t read or pronounce.

Is that Neuralese? Maybe. It is not a code we will ever study in a classroom, not because it is too complex, but because it was never meant for us. If a signal can move intent across silicon and spin motors into action without leaving a human‑readable trace, “language” feels like the best word we have.

Do LLMs actually communicate inside the stack? Not like two agents tossing discrete symbols in a reinforcement game. A single model is one giant function. Its only chatter is with itself. Neuralese might be closer to private thoughts than walkie‑talkie slang. If you have a paper that shows real agent‑to‑agent symbol swaps, drop a link. I want to dig in.

Inside the black box: The unspoken language of AI

They don’t think. Not really. They don’t speak, understand, or mean. What they do is behave in ways that simulate meaning so convincingly, we reflexively fill in the gaps. We anthropomorphize (everything, as always). And in that space between their mimicry and our projection, something emerges, something like communication. Or, as Rodney Brooks said, “…we over-anthropomorphize humans, who are, after all, mere machines.”

Back to the (non?)language Neuralese, this dense tangle of vector math, no rules or roots that only appears as thought when reflected in our direction.

It's not that the model knows what a cat is. It’s that when we ask it about cats, it activates just enough of the “catness” region in its mathematical dreamspace to give us an answer that feels right. That feeling is the trick. The illusion. But also the revelation.

But this new language lives inside the black box. It’s the internal chatter of large language models. The soup of token embeddings sloshing around under the hood. It's not designed to be elegant or expressive. It's designed to get the job done.

Human language is a marvel, full of ambiguity, poetry, subtext, and shared cultural connections. But to a machine, it’s just noise, indirect and redundant, made for soft, wet brains. Machines might not even need a large language model to communicate with each other.

“But Diego, LLMs are still hallucinating and getting things wrong” – The LLM Hater

Sure. A lot of them are. And I might be completely off here. But models built to reason are already proving more accurate. Chain-of-thought, tree-of-thought and other techniques all try to force a step-by-step breakdown. It’s like watching a toddler narrate their Lego build. Clunky, but it works. And here’s where things get weird. That inner language, the model’s inner monologue, starts to feel just as chaotic and hazy as ours. Thinking burns energy. Nature figured out a way to make that work for us. We made machines. They’re still figuring it out.

Why should a model have to spell out a whole grammatically correct essay to think something through? Why not let it mumble to itself in its own weird way?

I ran a dumb little experiment. Just wanted to see if tweaking the way a model reasons, shifting its “language” a bit, could save on tokens without wrecking the answer.

A little dumb experiment

By using only prompt engineering, I wanted to see if I could get the model to reason in a language I don’t understand, but still produce the correct final answer, all while keeping it fast and using fewer tokens. I tested only the latest mini OpenAI models that don’t have reasoning embedded. I chose a classic test case that models without reasoning usually fail.

Question: “Sally has 3 brothers, each with 2 sisters. How many sisters does Sally have?”

Test 1: Just asked the question straight up.

Final answer: Sally has 2 sisters
*871ms, 8 tokens, and wrong answer ❌

Test 2: Wrapped the whole thing in a JSON schema. Forced the model to explain each step. It cost 20 times more to get it right.

Final answer: Sally has 1 sister
*2.559ms, 164 tokens, right answer ✅

Test 3: Limited the vocabulary to words with four letters or less. Still got the right answer. Faster and over 60% more cost-effective than test 2.

Final answer: Sally has 1 sister
*1.633ms, 64 tokens, right answer✅

The final test was successful on the 4o-mini, 4.1-mini, and 4.1-nano. Even the nano, which I find almost useless, got things right.

Optimized reasoning: “Sally has 3 bros, Each bro has 2 sis. Sally is one sis. So, the other sis count is 1.”

The best result I got was this reasoning that sounded like stripped-down English. Kind of minimalist. With “bros” and “sis”. No fluff. And that seemed to help. There’s no judgment on grammar when it comes to reasoning. Clarity doesn’t always need correctness.

To be honest, this wasn’t test 3. It was more like test 100. I tried switching to other languages. Simplified Chinese worked better than expected, each symbol packs more meaning. Telegraph-style English helped too. Fewer filler words, less ambiguity. Even Simplified English made a difference. Some other experiments failed, costing more or failing to find the answer, such as using logic symbols, not using vowels or spaces during reasoning, which made sense based on how token prediction works.

This was not a breakthrough strategy for cutting reasoning costs or use that as machine-to-machine (M2M) communication. But it’s a nudge. A clue. A hint that maybe we can think better by saying less. And it’s still a long way from pure vectors or emergent protocols. But we might unlock cheaper, faster, more energy-efficient reasoning (unless someone builds a clean and infinite energy source first).

A little sci-fi thought experiment

So, if you're a linguist or an MS and you haven't gotten upset about what you've read so far, now's the time.

Let’s imagine that if there is a language machines use to communicate with each other, why not a programming language created by them that is efficient and probably impossible for us to understand?

Let’s call it Noēsis+ (from the Greek for “pure thought”). It is a token-only language. Each token is meaningless on its own. Meaning emerges only in the context of thousands of other tokens, across time, weighted by past executions.

Imagine each token as a coordinate, one point in a vast, high-dimensional landscape. Not with meaning on its own, but with potential. What matters isn’t what the token “says,” but where it leads.

Tokens:
Arbitrary identifiers, like:
ɸqz, ∆9r, aal, ⊠7, gr_, etc.
No keywords. No syntax. No punctuation. No variables.

Sequence-as-Code:
In Noēsis, tokens don’t have fixed meanings. Execution isn’t logic, it’s flow. Meaning emerges from proximity, repetition, and order, the way patterns in machine learning models seem to take shape across vast sequences. Not like programming. More like resonance. A mood that builds as tokens pass in relation to one another.

Compiled into Behavior:
Imagine a language where each token isn’t a command, but a vector. Not syntax, but coordinates in a sprawling, invisible space.

Programs in Noēsis don’t “run” like code. They move. They drift across latent vector fields, tracing paths shaped by token proximity, past history, and ambient state.

ɸqz ∆9r ∆9r aal ⊠7 ⊠7 ⊠7 gr_ ∞yx ɸqz gr_ gr_ ⊠7 xaz ɸqz

Same program, different result, depending not on what was written, but on when and where it was run. Like a thought that feels different depending on your mood. It’s almost as if it’s meant to make us anxious, and maybe machines could get anxious too?

Not that machines “feel.” But if their outputs jitter with context, if the same input drifts into new behaviors, does it matter? From the outside, it looks like mood. Like uncertainty. Like… unease

“Congrats, you burned 1,800 tokens to say nada, tech bro.”
– A linguist ex-friend

Point taken. You found my weak spot.

Syntax of a mind that isn’t ours

Jokes a part, while we keep polishing the human-sounding outputs, the real magic might be in listening closer to the alien syntax already unfolding under the surface. Well, alien because this language will evolve by a technology that wasn’t created by us, but by our creations.

So yeah. Neuralese. You’ll never speak it. You’ll never read it. But it might end up being the most fluent language on the planet.

And we’re the ones with the accents.

Changelog & Mea Culpas

The first version of this article triggered strong emotions on Reddit. I updated it and I ended up getting some great insights though, thanks to all the anonymous experts who educationally slapped me into a less “unscientific” and “idiotic” thought experiment.

The Vibe Life: Building Smart Keys for Mac

Diego Dotta — Fri, 25 Apr 2025 00:17:46 +0000

I didn’t realize I was about to enter the “vibe” industry when I started building Smart Keys. All I really wanted was a way to sound fluent in languages without doing the hard work. Let’s be real: learning languages is tough. So, I built an app that lets me fake my english fluency until I make it. Besides hating this reference, the thing here is that I’ll probably never make it. I may not be as fluent as I sound using tools like this.

Still, Smart Keys did the job for me on my phone. It solved my laziness problem and gave me a sense of accomplishment. Translate a message, change to a more casual tone, proofread an email, all with one tap. Suddenly, I was hooked. This tiny app had me feeling like a fluent native speaker.

Bringing the Vibe to My Desktop

Once Smart Keys worked its magic on my phone, I thought: why not bring this vibe to my desktop? I wanted to cut down on the constant back-and-forth between tabs, the endless browser windows, and that infuriating cycle of copy-pasting. Small tasks, like checking email, sending a reply, or fixing a bug, don’t require much brainpower, but they drain your energy nonetheless.

So, I created Smart Keys for Mac.

The goal was simple: stay in my flow, move through tasks without jumping between apps, and avoid losing focus on anything. I wanted to type, hit a shortcut, and keep moving. Proofread, translate, fix code, all without leaving the current task.

Simple. Efficient. Minimal.

The Perils of a One-Code Solution

Now, if you’ve ever tried to port an app from iOS to macOS, you’ll know it’s not as simple as change deployment target and calling it a day. That’s what I thought, but nope. The idea of maintaining one codebase sounded genius: keep it efficient, keep it synced, keep the maintenance low. But here’s the thing: macOS and iOS are like distant cousins. They share some traits but are entirely different creatures.

“If debugging is the process of removing software bugs, then programming must be the process of putting them in.”
– Edsger Dijkstra

“Two platforms, one codebase” sounds like a dream, but I quickly realized that you can’t just slap a mobile UI onto a desktop app and call it a day. The screen sizes, input methods, window management, all these small details had to be adjusted. It’s like trying to fit a square peg into a round hole, but making it work without losing the essence of what you built.

The Fine Line Between Efficiency and Overload

Incorporating macOS-specific optimizations wasn’t as simple as resizing windows. The app had to manage multiple displays, adjust for different screen sizes, and still feel fluid while taking advantage of the desktop’s power. Every change, every tweak, led to a cascade of other adjustments. Maintaining a single codebase was efficient in theory, but it created a lot of headaches along the way.

I spent more time testing than I care to admit, making sure one small change didn’t break something somewhere else. But that’s the process. There’s no such thing as an easy app transition (yet).

Selling a Quiet Product That Does a Lot

Now that Smart Keys mostly works, the challenge has shifted. I’m not wrestling with bugs as much as I’m wrestling with words. Building a product that blends into your day is one thing. Explaining it without making it sound like a blender full of features is another.

It rewrites. It translates. It fixes weird grammar and polishes sloppy code. All in the background, with shortcuts you barely notice. That’s the magic. And also the problem.

It’s hard to pitch a tool that isn’t trying to impress you. It just wants to help and then get out of the way. Try to summarize it in one sentence and you either oversimplify or overcomplicate. Try to be specific and it starts to sound like five tools in a trench coat.

“First, write the press release. Then, build the product.”
– Not me

So now I’m figuring out how to talk about it without killing the simplicity. Selling a quiet product in a world that rewards loud ones. Making clarity feel exciting without dressing it up too much.

Still, every time I’m stuck rewriting copy for the tenth time, it’s right there. I hit a shortcut, smooth things out, and move on.

Sure, half the time I’m fixing the thing I just built, but hey, at least I’ve got good shortcuts for the apology emails.

Store Conversion? More like Store Distraction.

Diego Dotta — Tue, 04 Feb 2025 00:15:02 +0000

Apple’s shiny Benchmark Metrics are BS, but don’t be fooled.

I learned that the hard way while feeling proud of myself as I rearranged screenshots, polished keywords, and declared I’d cracked the code. Smart Keys conversion rate soared, my proceeds per user looked stellar, and I’d pat myself on the back every time I glanced at the numbers.

Then it hit me that I was clinging to illusions, metrics that look good on paper but hide the gritty reality of crashes, retention, and actual profitability.

Here’s the short version of what I learned:

💩 1. Store Conversion: Ads and external promotions can juice your stats, making conversion look like a high score when it’s basically pay-to-win.

💸 2. Proceeds per Paying User: This can appear golden, until you remember acquisition costs can burn a hole in your wallet.

👑 3. Crashes: This is real gold. On a small team, testing across all devices and iOS versions is no walk in the park, this metric shows you if your app is on fire before the reviews come in hot.

🐎 4. Retention (D1, D7, D28): A slow-burn test of whether users actually come back. Trial periods and paywalls can skew it, so patience is key.

The truth is, Apple’s polished dashboards won’t give you the full picture. I’ve learned more from Every Inc. and the community #BuildingInPublic than from any set of curated stats or ASO gurus.

Want to dive deeper into the real numbers and see how I’m trying to keep things honest? Check out the full metrics and analysis on my blog at diego.horse.

Is any of these metrics relevant to you? Which metric should I dive into next?

Have a good week filled with no-BS insights.
(っ-,-)つ𐂃

No-BS Friday Metrics: Store Conversion Rate

Diego Dotta — Sat, 01 Feb 2025 01:57:22 +0000

Everyone loves to talk about ASO tricks and how to squeeze every bit of conversion juice from the app store. But what if I told you it doesn’t really matter? Smart Keys store conversion rate is over 50% while the best apps barely scrape 7%. So either I’m a wizard or this is an overrated metric.

We, builders, makers, indie devs, and friends love the idea that some ASO tweak will be the magic bullet. a better subtitle, the right screenshots, a catchy promo text. Sure, those things help a little, but they won’t move the needle in a meaningful way.

So what actually happened here? What’s the big ASO secret? It’s a three-letter word: Ads. No ASO magic tricks, no growth hacks, no overcomplicated strategy. just Ads that work.

So is this store conversion rate relevant? not really. It looks good on a dashboard, but that’s about it. Focus on what actually drives growth, not vanity metrics that make you feel good but don’t pay the bills.

That’s it for today. Next Friday, I’ll dive into retention, the real deal.

Have a no-BS weekend. See ya. ✌️