Forem: Diego Dotta

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. ✌️