For fifteen years I worked inside product organizations, taking on every possible shape: developer, designer, product manager, CTO, CPTO. And for fifteen years all of those organizations rested on the same premise: building software is hard, slow, and expensive.

Almost everything else follows from that premise. The Product Manager decides what to build, the Designer defines how it should work, the Engineer turns it into software, and so on. The model worked for decades because every step required specialized skills and, above all, because production was the bottleneck of the whole system.

AI is eroding that premise. Not because PMs, Designers, and Developers are becoming useless, but because the cost of turning an intention into something that works is collapsing: a prototype that used to take weeks now gets built in hours; a designer can produce code; a PM can query the data, put together a demo, and test a hypothesis without ever opening a roadmap.

I live this every day, building digital products while personally driving design, product, growth, and distribution, with AI at my side on almost everything. And I live it every day training PMs and engineers inside multinational companies.

Which opens up an organizational question far more interesting than the usual one about which professions will disappear:

How should we organize a team when building is no longer the main bottleneck?

My hypothesis is that the boundaries between Product, Design, and Engineering will become progressively more permeable, and that three archetypes will emerge in their place:

1. Builders: high-agency individual contributors accountable for an outcome.

2. Guardians: specialists who turn their expertise into systems, standards, and guardrails usable by the whole organization (humans and AI agents included).

3. Orchestrators: managers and leaders who distribute context, direction, and decision-making capacity instead of distributing tasks.

And it’s no longer just my hypothesis. A working paper from Harvard Business School and INSEAD (Kim & Koning, AI-Native Firms, 2026) measured AI-native startups against traditional ones: they turn out to be roughly 25% smaller under equal conditions, but with 13% more engineers, flatter hierarchies, and about 15% fewer managers. These are early data points, not definitive conclusions; but the statistical signature is exactly this: fewer people, more capability per head, fewer layers.

The result is not an organization without specialists. It’s an organization in which specialization changes position.

The bottleneck is moving

Every organization is designed around its own constraints. When writing software is expensive, it’s rational to protect engineers’ time with a long decision pipeline: someone gathers requirements, someone studies users, someone sets priorities, someone designs the interface, someone writes a spec detailed enough not to waste development time.

But what happens when production keeps getting cheaper? The bottleneck moves. The question is no longer “can we build it?”; it becomes “should we build it?” and, right after that, “did we build the right thing?”.

The scarce capability stops being the ability to produce software. What becomes scarce is understanding the problem, judgment, taste, the ability to tell signal from noise, accountability for the outcome. In one sentence:

When execution is a commodity, judgment is the real competitive advantage.

Google Cloud’s DORA report on AI-assisted development (State of AI-assisted Software Development, 2025, nearly 5,000 professionals) reaches the same conclusion from another direction: AI adoption among developers sits at 90%, but AI behaves as an amplifier.

AI amplifies the strengths of healthy organizations and the dysfunctions of unhealthy ones: the returns, as a consequence, come not from the tools but from the quality of internal platforms, the clarity of workflows, and the alignment of teams.

This is the starting point of the entire framework.

From specialists in a pipeline to people who own outcomes

The traditional team divides work by discipline; ownership and knowledge are continuously handed off: the PM talks to the user and describes the problem to the Designer; the Designer creates a solution and describes it to the Engineer; the Engineer implements; the PM comes back at the end to check. Every handoff introduces context loss, interpretation, waiting, coordination, meetings.

When production is expensive, this overhead is acceptable. When production becomes extremely fast, coordination risks costing more than production itself.

The alternative is to move ownership toward the individual: the same person moves through discover, define, prototype, build, ship, measure, learn. It doesn’t mean they work alone; it means they don’t continuously delegate responsibility for the problem.

Marty Cagan has been describing this distinction for years: feature teams receive solutions and are measured on output, product teams receive problems and are measured on outcome. The Builder Organization model takes that logic all the way, from the team as the unit to the person as the unit.

The Builder

A Builder is not simply a developer using Claude, and not a PM who knows how to code. They are, first of all, a person who owns an outcome: they receive a direction, a problem, some context, a few constraints, and a definition of success, and they have enough horizontal capability to decide autonomously how to proceed.

For me this is a very concrete figure, because it’s what I do every day: in the same week I analyze a funnel, talk to users, query the database, create a prototype, tweak its interaction, ship the experiment, and decide whether to continue. AI helps me execute almost all of it; my skills serve a different purpose, which is understanding what it’s doing and where it must not put its hands. A Builder with good aesthetic taste and technical fundamentals knows, for example, that the AI can’t touch the database in a certain way. They are horizontal on the product, but able to go deep where it matters.

The resulting profile is not the old T-shape with one deep spike and everything else at zero. It’s a profile with a strong specialist spike and a much higher horizontal baseline: an Engineering-heavy Builder remains far deeper technically, but can’t have Product at zero; they need to know discovery, prioritization, metrics, experimentation. The point is not to make everyone the same; it’s to drastically raise the baseline of adjacent skills.

That this baseline is already rising is suggested by data from the Anthropic Economic Index: it observes that in Claude usage patterns, augmentation (52%) has overtaken automation (45%): a hint, not proof, that AI is amplifying people more than replacing them.

The fundamental capability, though, is not technical: it’s agency. Moving from “what should I do?” to “what’s the outcome we need, and what can I do to get us closer?”. Before, a high-agency person was still limited by their own technical skills; today they can delegate part of production to an AI system. A passive person with AI produces tasks faster. A high-agency person with AI crosses entire disciplines.

AI amplifies agency more than it amplifies technical skill.

The Guardians: an authority for every vertical

The second archetype is the one most at risk of being misunderstood, so let me clarify two things right away. Guardians are more than one, and one exists (or should exist) for every critical vertical in the organization: design, engineering, data, AI, privacy, brand, and so on. Wherever there is deep expertise whose rules must apply to everyone, a Guardian is needed.

The definition is this: the Guardian is the authority of a vertical who codifies their expertise into executable rules, usable by people and by AI agents alike. They don’t take part in every project and don’t approve every single decision; they build the system that makes it hard to do badly in their vertical.

I didn’t deduce the need for this figure from theory: I watched it emerge from a practical problem, and design just happens to be the vertical where I noticed it first. AI in design is extremely powerful: it generates templates, layouts, entire design systems in timeframes that two years ago sounded like science fiction. But after a while you notice: the outputs all start to look alike. If ten Builders generate interfaces autonomously, with no one guarding the identity, the brand dilutes into a statistical average. Hence the Design Guardian: they own the design system, bring it into the shared workspace where people and agents work, and review the Builders’ outputs so that brand, taste, and user experience stay coherent.

The exact same pattern, though, repeats across every other vertical. In practice, today, codifying expertise means shared skills and shared MCPs, and each Guardian writes the ones for their own territory:

• the Design Guardian defines the design system, the skill that governs micro-copy, the skill that structures onboarding flows;

• the Engineering Guardian defines the stack, development rules and limits, which MCPs to connect and how to use them, and what the AI must not touch (the database in a certain way, for example);

• the Privacy Guardian defines the skill that teaches the AI to structure data in a GDPR-compliant way;

• the Data Guardian watches over metric definitions, data quality and semantics, so that two teams don’t call two different things “activation”;

• the AI Guardian watches over model selection, evals, safety, and observability of the agents themselves;

• the Brand Guardian watches over voice, positioning, and message consistency.

And with the rules come tiered permissions: within each vertical, one level of authority gets to make requests on staging, a higher level reaches production. Expertise stops living only in the specialist’s head or in code reviews; it becomes infrastructure.

Anyone who knows Team Topologies by Skelton and Pais will recognize the idea of platform as a product: platform teams that build self-service paved roads to reduce the cognitive load of other teams. It’s the same approach Bending Spoons applies.

The difference, and this is the part I consider genuinely new, is that in the Builders Organization the platform is addressed to AI agents too, not just to humans. The design system stops being a library for designers and becomes the interface through which the organization codifies its own taste: machine-readable documentation, components with clear semantics, tokens, examples, anti-patterns, skills, MCPs.

How many Guardians do you need, and where do they sit? It depends on the scale and shape of the organization. A Guardian can be horizontal, a single authority writing the rules of their vertical for all the Builders across all teams; or per business vertical, when an area is structurally different and its rules need to stay separate. And they don’t even have to be a dedicated person: a Guardian can be a Builder who, on their own territory of expertise, also wears that hat.

The Guardian turns individual expertise into organizational leverage: from specialists as gates to specialists as leverage.

The Orchestrator: context is the new coordination

In the reality I’m building, the Orchestrator is me. I decide what to build, how to prioritize, and under which constraints, based on all the information I have available: market, customers, numbers, relationships. I get AI’s help at every stage, but I don’t hand it the steering wheel of strategy. That’s the point that defines this role: the Orchestrator doesn’t distribute tasks, they distribute context.

Traditional companies invest enormously in coordination: meetings, roadmaps, planning, syncs, tickets, status updates. But a large part of that coordination exists because people hold different fragments of the context. If vision, strategy, current bets, constraints, priorities, evidence, and success metrics become clear, shared, and queryable (by people and by agents), part of the coordination can simply be eliminated.

AI-native organizations replace coordination with context, wherever possible.

The manager, in this model, loses part of the traditional role: they stop collecting updates, coordinating handoffs, and translating between functions, and start designing the system in which autonomous people make coherent decisions. They shouldn’t be promoted for coordinating more people, but for building environments where more people work well without them. The one question I would use to evaluate an AI-native manager is this: how well does your team work when you’re not in the room?

Here too, the early data points in the same direction: in the AI-native firms measured by Kim & Koning, hierarchies are flatter, with roughly 15% fewer managers at equal size. Not because management disappears, but because it changes nature: from routing tasks to designing context.

Hats, not people

Here I have to be honest, because this is where my direct experience refines the framework.

In the reality I’m building, today, I wear almost all three archetypes myself: I orchestrate the strategy, I build as a Builder, and I act as my own Guardian by defining the rules my agents must respect. If the framework required three distinct people by force, my own experience would contradict it.

But the point is another one: Builder, Guardian, and Orchestrator are hats, not people. At small scale one person wears all three; as you grow, they separate. “I do everything myself” is not a thesis: it’s a phase, tied to scale. And I’m already experimenting with how to delegate without creating people who merely duplicate my skills: the value is not in cloning the generalist, it’s in growing real ownership over real outcomes.

The evolution I expect, and that I’m starting to build, is an organization with several vertical Orchestrators; within each vertical, small nuclei of people driving the project forward, guided by the Orchestrator and supported by the Guardians. Some Guardians will be Builders themselves; others will cover the whole company horizontally. An AI-native team around an outcome like “increase activation” might be made of three Builders (one engineering-heavy, one design-heavy, one growth-heavy) with shared access to the design, engineering, AI, and data Guardians. The team isn’t assembled based on the disciplines required: it’s assembled based on the problem.

The risk of speed

The model has an obvious problem, and it’s worth looking at it squarely: AI reduces the cost of building, but it doesn’t reduce the cost of building the wrong thing. If anything, it accelerates it. Before, a terrible idea could die during requirements, design, planning, and estimation; the system was slow, but its slowness accidentally created a filter. Tomorrow the path is: bad idea, AI, production.

Abundance of output is not abundance of results. And it’s exactly why Orchestrators and Guardians are not a luxury, and why the goal is not to increase velocity but to increase validated learning per unit of time.

For the same reason, measuring story points and shipped features in an organization where output has grown tenfold only incentivizes producing more software: metrics need to move toward completed experiments, validated learnings, customer outcomes, and a new question for the career ladder: how big and ambiguous a problem can you own autonomously?

Alongside this dimension a second one is needed, that of leverage: how much you manage to increase the capabilities of others. That’s where a Principal Engineer can choose to become a Guardian instead of a manager, with an impact measured on the quality of the entire organization.

The fundamental principle

The previous paradigm asked: how do we coordinate different specialists to build software? The AI-native paradigm asks: how do we create people capable and informed enough to own an outcome autonomously, and what systems do we need to build so they can do it without sacrificing quality, safety, and coherence?

From these two questions the three archetypes emerge naturally, and the synthesis I’d like you to keep in mind is this:

Builders own outcomes. Guardians own standards. Orchestrators own context. Leaders own direction.

The result is not an organization where everyone does everything, nor an organization without specialists. It’s an organization where many more people can do much more autonomously, and where specialization moves from the production flow to the infrastructure that makes it possible.

And this is probably the real organizational consequence of AI: not just software produced faster, but a radical expansion of the surface of responsibility a single person can own. I’m crossing it firsthand, one hat at a time.

But here's the strange part: while life slowed everything down, under the surface these have been the densest months since I started this journey. Because something happened that I'd been waiting years for: I finally understood which direction to give what I'm building.

And I'll be honest with you…

In a short time I went from three active apps to six apps in the works. In this post I'll tell you what changed, I'll introduce you to the model (which now has a name) and I'll show you the numbers.

Hey, I’m Marco. Welcome to One Million Goal 👋

I left my CPTO job to build a portfolio of AI-native apps toward €1 million in revenue, sharing the real numbers, experiments, wins, and failures along the way.

Revenue to date: €310,419 / €1,000,000

Subscribe now

In the last update I promised you a longer conversation about the direction. Here it is. Three things in this post: first, the @creators model and why it changes everything; second, a tour of the apps on my desk, one by one; third, the numbers with a transparency call I should have made a long time ago.

From three to six apps

Let’s start from the beginning. For a long time I worked with the feeling of moving a lot without knowing exactly toward what. I was building, launching, learning… but the thread was missing.

Then the work with Virginia on Anapana led me straight to a realization. Over these months I understood something that changes everything: building is no longer the bottleneck. With AI at my service I can design, develop, and grow a product on my own, at a speed I would have called science fiction two years ago. What a solo builder always lacks, though, is distribution.

And who has distribution? Creators. Except most of them monetize it in the most fragile way possible: sponsorships, courses, PDFs. Things that live while you post and die the moment you stop.

The direction has a name: @creators

That’s how @creators was born… the venture studio where I build digital products together with creators. The deal is simple: I bring the product building and product growth skills, the creator brings the distribution. Depending on the audience and the work an app requires, we decide how to split the revenue; usually it’s 50/50. No upfront costs, no contract dressed up as a partnership.

But pay attention to one thing, because it’s the heart of the model: the starting point is never the creator. It’s their community. You start by understanding which problems that community actually lives with, and then you build, together with the creator, the right product to solve them. Value for the people first; revenue for everyone else after.

Inside @creators there are three paths.

The first is co-founding: together with the creator, we build the solution to their community’s problem. I build the product and grow it, the creator handles distribution and content. The apps launched under this model so far are Anapana and Finance Interview Prep, built with Marco Lecchi; the third one, with Andrea Passador, is on its way.

The second path is the affiliate program, designed for smaller creators (the ones who can’t yet guarantee co-founding-level distribution): they earn by driving conversions to the apps already in the program. If you have an audience of musicians, for example, you can promote Coco with a discount for your users and a percentage for you.

The third path is consulting: everything I learn in the field goes to work on the digital products a creator already has.

And here’s the part that excites me the most: the portfolio flywheel. Every app I launch is born with all the skills learned from the previous ones. Every app that’s live surfaces new dynamics, strategies, growth loops. And every discovery gets implemented across the whole portfolio, which then grows further.

So basically, I’m not building apps anymore… I’m building the system that produces them and makes them improve each other.

To hold a portfolio like this together on my own, with Anapana, Coco, HeyDoctor, and Finance Interview Prep live today and more on the way, I’m building a lot of automation: development, design, SEO where it makes sense, ASO, Apple Search Ads.

The challenge has always been the same since day one: using AI to maximize the impact I can bring alone, with the skills I built first as a developer, then as Head of Product, and finally as a CPTO.

What’s on my desk

Okay, let’s do the tour of the desk.

Anapana is still the flagship, the one I invest most of my time in. The work here is less visible from the outside, but it’s what holds up everything else. It’s also the prototype of the model: before co-founding even had a name, Virginia and I were already doing exactly this.

Coco is going really well and I’m evolving it: I’m adding translations and, above all, I’m using it as my personal lab to study distribution dynamics in the stores. ASO positioning, ASA spend, growth that comes only from the stores… no social, no content. It’s my toy, in the best sense of the word: what I learn here then travels to all the other apps. The flywheel, again.

HeyDoctor has only been a web application until now, and even so it already has 300 organic registered users, several of whom play almost every day. Translated: people coming back on their own to a product that doesn’t even have an app in the stores. That’s the signal I was waiting for, so I’m converting it into a mobile app: more complete gameplay, more fun, more within reach.

Finance Interview Prep, built with Marco Lecchi, is the first co-founding born inside the @creators model from day one. And with Andrea Passador we’re about to launch the next one.

Last thing on the desk, and it’s not an app: I’m working on a podcast with Matteo Marchesano. The name stays in the drawer for now, but I can tell you the why. Matteo and I use AI every single day and, beyond learning a lot, we’re putting ourselves on the front line to understand what the AI-driven future of organizations will look like. That’s why we want to interview people like us, who can tell us their own way of using AI.

The numbers

And now, the numbers. This time I want to be even clearer than usual, because there are two numbers and they should never be mixed up.

The first one, the Ammesso.it exit: €220,000. That’s the chapter before all of this. The sale of my first side project back in 2021. Ammesso was a project I carried forward as a solopreneur, with a couple of friends lending a hand at a few points along the way. I tell it as context, but it stays out of the goal counter: it’s an exit, not portfolio revenue. And a note of transparency here, because I made a call: until today I had counted this number inside the One Million Goal. I’ve decided to take it out. I want to keep the counts separate and treat as OMG revenue only what is truly generated as a solopreneur, with AI at my side. Yes… the counter drops by €220,000. But I’d rather have a smaller, honest number than a bigger, ambiguous one.

The second number, One Million Goal: €310,491. This is the number that measures progress toward the million. The aggregate revenue of all the apps in the portfolio, added up from October until today. So don’t read it as one month of explosive growth: it’s a change of scope, plus the real progress.

It’s not the million. But the direction is the right one, and for the first time it’s not a single app growing: it’s the system.

Reflections

Let me close with a reflection. I’ve always had a motto: family first. Since Gabriele arrived I work from home every day, I’ve cut my hours and trimmed everything I could trim… this content included. Those of you who are parents know: two small kids at home in August, with every daycare closed, is not a stroll.

The strange part? Fewer hours made me sharper. When time is scarce, bad decisions cost too much; so I stopped chasing every idea and started building the system that keeps working while I’m with my kids. And maybe that’s exactly why the direction became clear.

What’s next

But that’s where we’re at. In the next posts I’ll take you inside three things: the data on how Anapana’s metrics are doing, the tool workflow I use today (constantly evolving) and how I do ASO and Apple Search Ads. Give me time to put them together, though: the priorities today are my family and this business. The rhythm may not be constant, but what I share will always be true.

And before we wrap up, a question for you: if you’re a creator, which of the three @creators paths would you see yourself in? Co-founding, affiliate, or consulting? Drop it in the comments… I read all of them.

Impossible? Maybe... or maybe not.

That’s it for this week.

One Million Goal is my public journey to build a portfolio of AI-native products to €1 million in revenue. I share what works, what fails, and the systems behind both.

Subscribe to follow the build. Paid members get the full numbers, deeper breakdowns, and practical playbooks behind my decisions.

Subscribe now

If this post made you think of someone building with AI, send it their way.

Share

See you next week,
Marco

Five months ago, I started building an ear training app. The kind that helps musicians recognize notes, intervals, chords, and scales just by hearing them, so they can pick up a song by ear instead of relying on sheet music.

I shipped a first version. It wasn’t great. In April, I scrapped most of it and rebuilt the app from scratch.

This is the story of what happened in between, and why I now believe I’ve made the ear training app I’d actually want to open every morning.

You can download it here.

How Coco started

It started with a talk in Turin.

I was invited on stage to build an app live in 60 minutes using ChatGPT and Lovable. I wrote about that experience in a previous post. The app I built that day was ChromaKid, a small prototype to teach absolute pitch to kids through color associations.

The idea came from a study I had read by Ayako Sakakibara, a Japanese researcher who showed something fascinating:

Perfect pitch isn’t a talent you’re born with. It’s a skill that can be acquired between ages 0 and 6, through a structured method called the Chord Identification Method.

ChromaKid was a fun stage demo. But I didn’t pursue it.

I have a 2-year-old daughter, and I’m not enthusiastic about putting her in front of a screen. The more I sat with the idea, the more I asked myself a different question.

What if it’s possible to train an adult ear too?

I started reading. The research is encouraging. While true perfect pitch is hard to acquire after a certain age, relative pitch can be improved at any age. With enough focused practice, an adult musician can get remarkably close to the kind of fluency only “naturals” seem to have.

That’s where Coco was born. Not as an app for kids. As an app for the version of myself who was tired of opening every other ear training app and finding the same boring drills.

The first version

I started building Coco at the end of December.

I want to be honest about this part. The first version wasn’t terrible. It just wasn’t different. It was, more or less, a polished version of every other ear training app on the App Store.

The app had two main sections.

Learn was a series of microlearning slides, each followed by a short practice session. Theory first, then drill. It looked clean. It worked.

Practice was a free-form section where users could customize their own training: pick the exercise, the difficulty, the notes, and go.

Sounds reasonable, right? It was. The problem is that “reasonable” doesn’t make people open an app every morning.

By February, I had about 50 organic users from early ASO work on the App Store. I emailed them and asked for honest feedback. The replies were polite, but the words kept circling around the same shape:

“It’s not very engaging.”

“I don’t feel excited when I open it.”

“I don’t think about using it every day.”

The data agreed. A few users genuinely loved the app and used it consistently. Most others tried it for a few days and quietly stopped.

But here’s the moment that actually pushed me to rebuild. I noticed I wasn’t opening it either.

I’m a musician. I have perfect pitch. I’m building an ear training app. And I had no internal pull to open my own product on my own phone.

That was the signal. If the founder is bored by what he’s building, no amount of new features will save it.

So at the start of April, I scrapped the UX, the UI, and most of the logic. I kept the codebase, but I rebuilt almost everything from scratch with one rule:

What Coco is now

The new Coco is built around five sections, each with a clear job.

Daily workout

Daily workout is the first thing you see when you open the app. Every morning, Coco generates a session based on your skill, your progress, and your current level. You don’t have to decide what to practice. The app decides for you. You just open it and play.

Daily challenge

Daily challenge is a global session, the same for every musician on Coco that day. It’s small, but it makes the app feel alive. It’s also the one thing free users can always access, so the streak is preserved no matter the plan.

Games

Games is where the biggest shift happened. Instead of one generic “practice” mode, Coco now has seven different games, each focused on a specific listening skill: notes, ascending intervals, descending intervals, chords, scales, interval comparison, and pitch memory. They have names and personalities. Sonar, Triad, Climb, Fall, Ladder, Span, Pitch.

Practice

Practice is the only section I kept from the old version, refined. Users who want to design their own session can still do it. But it’s no longer the main experience. It’s an option, not the default.

Statistics

Stats and Coco Proficiency Index. Every musician on Coco has a live skill rating between 0 and 5,000, split across notes, intervals, chords, and scales. It rises when you outperform yourself, falls when you stop practicing or underperform. It’s not a scientific certification. It’s a way to make ear training feel measurable, the same way a chess rating makes chess feel measurable.

Sessions are short by design. Around 10 to 25 questions. Time pressure on each answer. Lives. Stars. A real pass/fail threshold. The app rewards consistency, not grinding.

The whole thing went from “a list of things to do” to “a small daily workout I look forward to.”

I notice the difference because I’m one of the users.

How I built it

For the builders reading: the website runs on Next.js, hosted on Vercel. The mobile app is built with Expo. Supabase handles the database, authentication, and edge functions. RevenueCat and Stripe take care of monetization, and Astro powers the ASO work that brought in the first users.

Most of the development happened in Claude Code and Cursor, with Claude doing the reasoning work behind the scenes. The design started as a rough system I sketched myself, then got refined with Claude Design.

The most experimental piece is a self-built agentic system using Claude Managed Agents, plugged into the Ahrefs MCP. It scans for SEO opportunities and drafts content around them, so the site can keep growing organically without me writing every post manually.

I’ll go deeper into all of this in the next piece.

Proof it’s actually working

A few weeks after the rebuild, one of the very first Coco users wrote me this:

That’s the kind of feedback that makes you stop scrolling.

He didn’t say “the UI is nice” or “the streaks are motivating.” He said I’m hearing things I couldn’t hear before. That’s the entire point of the app.

For me personally: I have perfect pitch, but I’ve noticed it needs maintenance, especially as I get older. Coco is helping me keep it sharp. My accuracy is measurably going up. I can feel it when I sit at the piano.

This is the part where the founder bias would normally kick in, and I’d say “and I’m sure it’ll work for everyone.” I won’t. I have 114 users today. That’s not enough to make any kind of universal claim. But it’s enough to know that for the people who stick around, something real is happening.

Where Coco is today

114 registered users, all acquired organically through ASO. No paid acquisition. No LinkedIn pushes. Just App Store keyword work and a bit of word of mouth.

The model is freemium. Free users get a few games per day and full access to the daily challenge, every day, forever. Coco Pro unlocks the entire app, all games, all levels, all daily workouts, all future integrations for €49,99 a year.

It’s currently discounted to €29,99. New users have 48 hours to get the first year at €19,99.

This article is the first time I’m really pushing Coco to my own audience.

Until now, the only people who knew about it were beta users or musicians who happened to type “ear training” into the App Store and find it. From here, I want to see what happens when the people reading One Million Goal also start opening it.

If you’re a musician, a producer, a singer, a guitarist, a piano student, or just someone curious to know what your ear can actually hear, I’d love it if you tried it.

Download Coco

What’s next

In the next few days I’ll publish a separate piece, How I built Coco. The full story behind the workflow. If you’re building something yourself, that one might end up being more useful to you than this one.

If there’s a specific part you want me to go deeper into (design, development, tools, prompts, anything), drop it in the comments. The more I know what you actually want to read, the better I can write it.

Building Coco taught me something I’d been circling for a while.

When building stops being the hard part, what to build, how to build it, and how to design it become everything.

It also reassured me of something else. In an era where everyone with AI can build, our skills and our taste, the years we've spent learning what makes a product worth using, still matter. Probably more than ever.

So, the bold claim from the title.

I think I just made the best ear training app so far.

It was probably too bold. But I do believe this: I made the ear training app I'd actually open every morning.

Easter Sunday. My cousin Mattia, who’s studying Medicine in Trieste, is showing me something on his phone between one slice of colomba and the next.

“Look at this. It’s called Doctordle. It’s all over TikTok.”

I looked. It was a list of symptoms, and you had to guess the diagnosis. Simple. Clean. And honestly... not that impressive.

Because that’s not how medicine works.

A real doctor doesn’t get a neat list of clues. A real doctor sits in front of a person. Asks questions. Listens. Orders the right investigations. Connects the dots. Then, maybe, arrives at a diagnosis.

Doctordle was a guessing game. The real job to be done was clinical reasoning.

That gap stayed with me through the rest of lunch.

The night everything started

That evening, Annalisa and Isabel were asleep. The house was quiet. And I couldn’t stop thinking about what a better version of that game would look like.

Not a list of symptoms. A conversation with a patient. An AI-powered patient who talks like a real person, shares information gradually, and forces you to think like a doctor.

So I opened Claude and started writing a Product Requirements Document. Not a polished spec. More like a structured brain dump: what the core experience should feel like, what the MVP needs to prove, what can wait.

Then I passed the PRD to my agents in Cursor and let them work.

The next morning, I had a working prototype. Two hardcoded clinical cases. One chat interface. No leaderboard, no achievements, no fancy design. Just the core question: does talking to an AI patient feel real?

Mattia and Gabriel

I sent the link to Mattia. He shared it with his friend Gabriel, another med student in Trieste.

Within hours, they were hooked.

Not just using it. Competing. Comparing scores. Challenging each other to solve the case with fewer questions, fewer tests. The gamification layer I hadn’t built yet... they were already creating it themselves.

Their feedback was incredibly useful. The AI patient was convincing, the clinical scenarios felt real, and the overall experience was solid. But they also spotted something I hadn’t anticipated.

The patient was too helpful.

In some conversations, the AI would share information so completely that the diagnosis became obvious after two or three questions. In real clinical practice, patients don’t hand you a textbook presentation. They’re vague, confused, they forget details, they emphasize the wrong things.

So I tuned the prompts. Made the AI patient more human. Less forthcoming. The kind of patient who says “I’ve been feeling tired” instead of giving you a perfect description of their iron deficiency anemia.

That made the game dramatically better.

What HeyDoctor is

HeyDoctor is a daily clinical reasoning game. Every day at midnight UTC, a new case drops. You have 24 hours to solve it.

The experience follows the same logic a doctor would use in real life.

You start by talking to the patient. Ask questions in natural language. The AI responds in character, sharing symptoms, history, and concerns the way a real person would... gradually, sometimes imprecisely, always grounded in a pre-authored clinical case that ensures medical accuracy.

When you think you have enough from the conversation, you can order investigations. Physical exams. Blood tests. ECGs. Imaging. Biopsies. Each investigation has a point cost, because in the real world, ordering every test under the sun isn’t good medicine. It’s lazy medicine.

Then you submit your diagnosis. You get three attempts to pick the correct one from a curated database of over 1,100 conditions across 20 medical specialties.

Your score rewards efficiency: fewer messages, fewer investigations, fewer diagnosis attempts. The best doctors aren’t the ones who order everything. They’re the ones who ask the right questions.

There’s a leaderboard, daily streaks, XP, and achievements. But the real hook is simpler than all of that. It’s the same thing that made Mattia and Gabriel compete: the satisfaction of cracking a case with minimal resources.

How a case is built

This is the part that surprised me most during development. The game feels spontaneous when you play it. The AI patient responds naturally, reacts to your questions, even gets a bit evasive sometimes. But underneath, nothing is improvised.

Every case starts with a real diagnosis. Community-acquired pneumonia. Graves’ disease. Something you’d find in a textbook or encounter on a ward round.

From there, I use AI (acting as a senior clinician, not a chatbot) to generate a complete clinical case dossier. This document contains everything: who the patient is, their background, how they’d describe their problem in everyday words, their medical history, lifestyle, family context, what you’d find on physical exam, and pre-written results for every single investigation the game allows.

That last part is critical. When you order a blood test in HeyDoctor, the app doesn’t ask the AI to invent a result on the fly. It looks up the answer that was already written and validated. This keeps investigations consistent and prevents the case from contradicting itself mid-session.

The AI patient’s first words get translated into four languages (English, Italian, French, Spanish) with the same clinical intent but natural, localized wording. And every generated case goes through a quality checklist: required sections present, patient language believable, diagnosis not accidentally revealed in the opening story.

Then it’s saved as a draft. Publishing is always a separate, deliberate step. The “one new case at midnight” rhythm stays curated and intentional.

I built a full admin panel to manage the whole pipeline: case generation, diagnosis management, scheduling, session review. For building the library faster, there’s also a batch tool that can generate many cases at once from a checklist of diagnoses.

One sentence to summarize the philosophy: cases are written like structured teaching scripts, with every investigation answer decided in advance, so the daily puzzle is fair, consistent, and medically grounded... while the AI patient still feels alive when you talk to them.

The numbers behind the price

Before setting a price, I tracked AI costs across dozens of test sessions. One conversation with the AI patient costs between €0.002 and €0.05, depending on length and complexity.

That data gave me confidence. At €9.99/month, the margins are healthy enough to reinvest in product development and marketing. Free users get one case per week. Pro unlocks every daily case, and full case history.

I didn’t guess the price. I calculated it from actual usage data. That’s one of the advantages of building with AI: you can measure the cost of every interaction before you commit to a business model.

Two weeks

From Easter lunch to a live product with 1,100+ diagnoses, four languages, leaderboards, achievements, streaks, an admin panel, and a case generation pipeline.

Two weeks.

I’m not saying this to brag. I’m saying it because two years ago, this would have taken months. Maybe longer. The tools have changed. Cursor, Claude, the whole agentic workflow... they compress the build phase in ways that still surprise me.

But the insight didn’t come from AI. It came from watching Mattia swipe through Doctordle and thinking: this isn’t how doctors actually work.

The build was fast. The observation was the real starting point.

Try it

If you’re a medical student, a junior doctor, a nurse, or just someone curious about clinical reasoning, I’d love for you to try HeyDoctor.

One new case, every single day: heydoctor.io

And if you play it... tell me what you think. Every piece of feedback from Mattia and Gabriel made this product better. Yours will too.

February was family. No launches, no content, no socials. Just the stuff that matters more than any dashboard.

March was the comeback. Three speeches rescheduled. Two products back on track. One new product coming. One post long overdue.

I missed this. Writing, sharing, thinking out loud with you. So let me catch you up on everything, and then I want to ask you something.

What’s on My Desk

Anapana

The numbers tell the story better than I can.

Over the past few months, we’ve been quietly improving every step of the user journey. Guided meditations, personalized paths, Google and Apple sign-in, a redesigned onboarding, pricing experiments, funnel optimization, win-back strategies.

No single feature drove the results. It was dozens of small, intentional decisions stacking up over time.

Here’s where the funnel sits today:

• Trial Start Rate: 15% (market median: 6.92%)

• Trial to Paid: 55% (market median: 37%)

• Download to Paid: 8% (market median: 2.8%)

• 6-Month Retention: 50% (market median: 18%)

Market medians per RevenueCat industry data.

I had to read those numbers twice when I first pulled them together. Every metric is well above market. Not because we did one clever thing, but because we kept doing small things well.

That’s the lesson I keep relearning: product work compounds. You don’t feel it week by week. Then one day you look at the dashboard and the curve has changed shape.

Revenue remains private (it’s a shared project), but I’ll say this: Anapana is going well.

If you’re curious to try it, the app is available on iPhone and Android. It’s in Italian for now. I created an offer only for you, just open this link.

Coco

Coco launched on February 22nd, about a month late. The delay wasn’t ideal, but the product was better for it.

The launch was quiet. One Reddit post and some ASO work. No paid ads, no big campaign.

The result: almost 100 organic users and growing, without any real push.

I’m deliberately holding back on distribution. I’m still in feedback mode, watching how people actually use the app, reading what they write to me. The early signals are good: people are engaging with the ear training exercises in ways that confirm the core loop works, even if there’s still plenty to fix.

The next release will be a meaningful one. More than that I won’t say for now.

Something New

Right now my full focus is on Coco and Anapana. BabyTales and HeyBloom are paused. I’d rather go deep on what’s working than spread across too many things.

But there’s something else on my desk. An educational game I’ve been working on quietly. I’m not going to say much about it yet, but I think I’ll share something more on Monday ;)

Three Speeches

In March I gave three talks in Milan, Cesena, and Trieste. Same title each time: “Quando costruire non è più il problema” (When building is no longer the problem).

The core thesis: AI has compressed the build phase so much that the real challenges are now clarity, distribution, and taste. The bottleneck has shifted.

During two of those talks, developers in the audience raised the same concern: “What about security? What about GDPR?”

I get the worry. It’s valid. But it also told me something. The biggest risk in 2026 isn’t a fine from the Privacy Authority. It’s not having the AI skills to build at all. The compliance question matters, but it shouldn’t be what stops you from starting.

That said, people were genuinely worried, and that means this needs a proper answer. So I wrote one. A practical breakdown of what compliance actually looks like for solo builders in 2026. Coming soon on One Million Goal.

That said. Thank you again Gerson, Emanuele, and Licia for having me!

Beyond Products

Two other things worth mentioning.

I launched a personal website at marcosantonocito.com. It’s minimal, a placeholder really, but it exists. Sometimes shipping something imperfect beats shipping nothing.

I’m also running a civic innovation lab called “Design the Future” through Civitas in Pordenone. Double Diamond framework, civic context, helping people who’ve never thought in product terms make sense of complex community problems.

Different world from apps and funnels, but the thinking is the same.

Metrics Snapshot

• Anapana: Revenue private. Funnel metrics shared above. Going well.

• Coco: ~100 organic users. No revenue yet (still in feedback/iteration phase).

One Million Goal (Revenue to Date): €220,069.80

Reflections

When you step away from building for a few weeks, you’d expect to come back anxious. Desperate to catch up. I didn’t. I came back clearer about what matters. Two products are working. The rest can wait.

But I’ve also been reflecting a lot about the future of work. Not in the abstract “thought leadership” way. In the practical, what does this actually mean for me and the people around me way.

I’m going to share some open questions here. I don’t have all the answers yet, but I’ll be writing my thoughts about each of them in the next days. For now, I want to put them on the table.

Some context first.

A solo operator can now launch a billion-dollar business powered by AI. The economy’s dividing line is no longer skill or education. It’s will.

Boris Cherny put it well: “AI tools are already pushing engineers into broader builder roles focused on product strategy and systems thinking.”

I completely agree with him. The boundaries between PMs, designers, and developers are thinning fast. What’s becoming more important are hybrid figures: small, fast, multidisciplinary, with high agency.

The questions I keep coming back to.

If one good engineer can now 10x their output, companies will need fewer of them. Which engineers will stay? And what happens to the ones who don’t?

Will Product Managers become less useful or more useful? And what about designers, once AI can generate good UIs? I’ve tested a lot of tools and honestly, we’re not there yet. But we’re getting close enough to ask the question seriously.

How does the future of work actually change? Companies need to free people with extreme agency, but how do you do that in practice? Will there still be a need for middle management, or does that layer just... disappear?

No answers today. Just questions I keep turning over. I’ll be writing about each of these soon. If any of them hit you, reply or drop a comment. I’m genuinely curious what you think.

—

Thanks for being here.

See you in the next one.

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

Picture this: it’s 6am in Melbourne, Australia. A man straps on his work boots, loads a lawn mower into his car, and drives to the first job of the day. He’ll mow lawns until 6pm. Then he’ll go home, sit at his desk, and write code until midnight.

He has $200,000 in debt. His web agency has collapsed. His cars were repossessed. And every morning, he chooses the lawn mower over the blanket.

That man is . And the reason I wanted to write about him isn’t because of where he ended up… it’s because of what he figured out while he was still at the bottom.

The Rise and the Collapse

For a few years, things were going well. Adam had built a web development agency in Melbourne that, at its peak, was generating around $300,000 in profit per year. No co-founders. Just him, some clients, and a growing reputation for getting things done.

The problem is that the web agency business in the mid-2010s was sitting on a fault line. When Wix and Squarespace arrived in earnest, the market for custom-built websites didn’t just shrink… it evaporated. Almost overnight, Adam could no longer charge $10,000 for something a client could build themselves for $10 a month. He tried lowering prices, working more hours, grinding harder. That just meant more burnout for less money.

Eventually he couldn’t even sit at his desk. The debts mounted. Everything started falling apart slowly, then all at once.

What he was left with, after the cars were taken and the accounts frozen, was $200,000 in debt and nothing else.

Most people would have taken that as a signal to go find a steady job. Adam, somehow, read it as a signal to start building apps.

The Lawn Mowing Route App

There’s a beautiful irony in how Adam found his next idea. He’d started mowing lawns, literally, to rebuild his confidence and make ends meet. And while driving between jobs one day, trying to figure out the most efficient route, he asked some of the other lawn-mowers how they organized their work.

A piece of paper, one guy told him. Names and addresses on one side for week one, flip it over for week two.

No app? Adam asked.

No app exists, the guy said. Someone should make one.

So Adam spent six months building a lawn mowing route management app. He launched it. It flopped completely.

I’ve thought about this story a lot. Because on the surface it looks like a failure, and it was. But it also forced Adam to ask a question he’d been avoiding: why would an app with a clear use case, a clear audience, and a clear need just... not work?

He didn’t have a good answer. So he decided to learn by doing, at volume.

One app per month. Every month.

Volume as a Learning Strategy

The one-app-a-month challenge sounds exhausting when you describe it. In practice, Adam found it clarifying. Building fast forces you to strip away everything that doesn’t matter. You can’t spend six weeks perfecting onboarding when you’ve got a deadline in three weeks. You ship something real, you see if anyone cares, and you move on.

A tweet he posted in the middle of his journey captures this better than I can:

Most of the apps went nowhere. But one didn’t. One started generating around $11,000 per month. And one day, somebody reached out offering to buy it for two times annual revenue: $224,000.

Adam took the deal. That money paid off enough of the debt to keep the collectors at bay, and kept him out of bankruptcy court, which would have ended his developer career entirely.

But more than the money, the sale changed how he thought about what he was doing. An app generating $11,000 a month sells for $224,000. That math reframes everything. Instead of thinking “I need to build something massive,” he started thinking: I need to build a portfolio of small, stable things… and let the aggregate do the work.

He sold eight apps over two years, using each exit as runway to fund the next experiment. Building, selling, building again.

The Pepsi Max Moment

There’s a scene Adam has described in interviews that I keep coming back to. He was out for dinner with his family, a rare small luxury during a hard period. He wanted a Pepsi Max. He looked at the price. He couldn’t afford it.

He sat there and thought: what am I doing?

The build-and-sell model was working, technically, but it wasn’t building anything durable. Every time he sold an app, he was back to zero. The runway would run out eventually, and he’d be right back where he started.

That night, he decided to change the model. Instead of building to sell, he’d build to keep, and he’d charge subscriptions instead of one-time fees. That way, the portfolio would compound. Each app would add a small monthly amount that never went away.

The timing was fortunate. ChatGPT had just become broadly available, and Adam challenged himself to build ten apps in a single month using AI assistance. He managed nine. He pushed his portfolio to over fifty apps and watched the aggregate subscriptions climb to a level where he could finally stop selling.

He paid off all $200,000 of debt in the summer of 2023.

The Paywall That Changed Everything

Most people, when they hear Adam’s story, focus on the volume. Fifty apps. Nine apps in a month. One per month for years. It sounds like a relentless production line.

But the moment that actually changed the revenue trajectory had nothing to do with volume. It was a paywall.

Adam had distribution. His apps were getting downloads. But the revenue wasn’t reflecting the attention. So he redesigned the onboarding and paywall experience across his portfolio, more intentional conversion flows, better-structured trial offers, and his monthly revenue went from around $10,000 to $50,000 essentially overnight.

He tweeted about it the day he hit $800,000 in cumulative sales:

He talks about this distinction often, and it’s one of the most useful things he’s put into words: distribution and monetization are separate problems. Most indie developers try to solve them simultaneously, which means they solve neither well. Adam spent years solving distribution through volume and ASO. When he finally turned his attention to monetization, the existing distribution made every improvement compound faster.

He shared this publicly… including the specific paywall design that drove much of the jump, the exact numbers, the actual screens. Not a cleaned-up version of events.

This is the kind of thing that makes his YouTube channel worth watching and his Twitter feed worth following. He’ll show you what actually happened.

A Rising Tide Lifts All Boats

That line is Adam’s motto, and it explains a lot about why he’s built an audience of 47,000 followers on X and runs a YouTube channel that I genuinely think has some of the best practical indie dev content available.

He shares everything. Revenue milestones, failed experiments, apps that earned nothing, the paywall that started getting rejected by Apple. He doesn’t curate a highlight reel or more accurately, he curates the failures just as much as the wins, which creates something unusual: a builder people actually trust.

When he crossed the $1M milestone, the tweet he posted wasn’t a celebratory launch post. It was almost an afterthought:

That’s the whole brand right there. Self-aware, a little dry, and honest about where the doubts came from.

He also open-sourced his core reusable components (onboarding flows, paywall screens, OpenAI wrappers) because if everyone can build faster, the ecosystem gets richer and so does the opportunity for all of them.

This isn’t a calculated content strategy. It reads more like someone who genuinely believes that sharing what he knows costs him nothing and helps others. That the community formed around that kind of honesty is worth having.

Why This Story Matters to Me

Reading about Adam while I’m building Coco and working on Anapana, a few things land differently than they would have a year ago.

The first is the sequencing. Adam didn’t solve distribution and monetization at the same time. He committed to distribution first (built the portfolio, learned ASO, accepted modest revenue for a long time) and only then optimized for conversion. Most builders try to do both simultaneously and wonder why neither works. There’s something uncomfortable about that sequencing because it means accepting a long period where you’re getting downloads but not the money you think you deserve. But the discipline of it is real.

The second is what “volume“ actually means in practice. People hear “fifty apps” and imagine a factory. What it actually is, I think, is a method for reducing the emotional weight of any single bet. When one app doesn’t work, there are forty-nine others. The portfolio isn’t just a revenue strategy, it’s a psychological one. It keeps you moving when individual things fail, which they often do.

Adam posted something during his quieter years that I think every builder going through a slow period should save somewhere:

He was right. Though you can’t know that until after it happens.

The third is the lifestyle decision underneath all of it. Adam has five kids. He’s not building toward some future state where he’ll finally have freedom. He’s building to have freedom now, within constraints that are real and present. The lawn mowing, the coding at midnight, the fifty apps… none of it was hustle for hustle’s sake. It was a father trying to work out how to provide for his family without sacrificing the things that actually matter.

He crossed $1M in cumulative App Store sales not long ago. He’s working out of Melbourne, in whatever hours make sense for a family with five children.

That’s not a footnote to the story. That’s the point of it.

If you’re building something too, what’s your Pepsi Max moment? The one where you looked at what you were doing and realized the model was wrong… not the product, not the execution, but the fundamental logic underneath it?

Sometimes you need to get there before anything else changes.

Thanks for reading One Million Goal. If this was useful, forward it to one person who’s thinking about building apps solo.

Share

Founders connect their Stripe accounts and the numbers show up live. It’s one of those ideas that sounds obvious in hindsight.

So I pulled the full dataset. 986 startups, scraped and cleaned, with fields covering MRR, profit margins, country, category, founder audience, pricing model, and more. Then I started running the numbers.

What I found is not what the timeline would have you believe. But before we get into the data, there are three things worth saying upfront — because they change how you should read everything that follows.

Three Layers of Bias (Read This First)

Layer 1: Marc Lou’s audience.

Marc Lou is French. And his audience is disproportionately French and European. This matters because TrustMRR's user base reflects his reach, not the global distribution of indie hackers. France is second in the database with 97 startups, behind only the US at 273. Marc himself tweeted about this dynamic when he ranked countries by revenue generated on TrustMRR — France punches well above its weight, which he celebrated. But it's worth keeping in mind as a systematic skew.

Layer 2: Self-selection for transparency.

The startups on TrustMRR are the ones whose founders cared enough about building in public to connect their Stripe accounts live. That's already a filtered group… more motivated, more community-oriented, more likely to be intentional builders. The true median indie hacker, including the person who tried something quietly for three months and got zero revenue, isn't here.

Layer 3: TrustMRR is also a startup marketplace.

This is the most underappreciated bias, and the one that changes the most about how you read the numbers. TrustMRR isn’t just a leaderboard. It’s a platform for buying and selling indie businesses. About 38% of the core projects are actively listed for sale.

Think about what that means. If you had a project growing 30% month-over-month, generating real income, and exciting you every morning, would you list it on an acquisition marketplace right now? Probably not. The projects that end up for sale tend to be the ones that have plateaued (decent revenue, but the founder has lost energy, or the growth has stalled, or they simply want to move on).

The data confirms this exactly. For-sale projects have a median MRR of $727, higher than the not-for-sale median of $319. But their average 30-day growth rate is just 119%, versus 651% for the projects not listed for sale. The plateau-ers get sold. The rockets get kept.

So the database you’re looking at is disproportionately populated by three kinds of projects: very early-stage startups, projects that have stagnated, and founders who joined the platform for community reasons rather than marketplace ones. The genuinely thriving, fast-growing projects are likely underrepresented.

With all of that in mind, here’s what the data actually shows, and what I think it really means.

The Real Picture

I split the dataset into two groups: a core and an outlier set.

For the outliers, I used a standard statistical method (the IQR rule) to identify projects that sit far enough above the rest to be a genuinely different category of business. That threshold landed at roughly $16,400 MRR. Everything above it, 103 startups, I analyzed separately. Everything below, 528 projects with positive revenue, is the core dataset.

The median MRR in the core group is $445 per month.

About 27% of these projects make under $100 a month. Projects like Supaframe, a tool for embedding Supabase data into Notion, at $88 MRR, or JobBoardSearch, a job board aggregator, at $99. They exist. They have real users. They’re making almost nothing yet.

More than half of the core make under $500. Only 13% have crossed $5,000 MRR.

Marc Lou shared his own read of the TrustMRR data recently, and some of his stats look more optimistic: “81% made $1+, 44% made $1,000+, average time to first $1: 5 months.” These are live numbers from the platform, slightly different from my snapshot, but the order of magnitude is the same.

Now layer the three biases on top of this. The $445 median already looks low. But remember: it’s calculated on a dataset that skews toward stagnating projects (the for-sale ones), that excludes the true failures (who never joined), and that over-represents a community where transparency is a cultural value rather than a business outcome. The real distribution of all indie hacker projects ever attempted would look considerably more bottom-heavy than this.

That’s the reality check part.

But here’s where it gets genuinely interesting.

The Structure Is Actually Good

When I looked at profit margins, something shifted. Among the 464 startups that reported margin data, the median was 81%. The average was 78%. About 80% of them run at margins above 70%.

Think about that for a second. A traditional business (a restaurant, a service company, a retail shop) would celebrate 20% margins. These projects, even the ones making $445 a month, are keeping most of what they earn. The cost structure of a one-person software product is genuinely different from almost every other kind of business humans have built.

So yes, $445 median MRR sounds small. But $445 at 81% margins, with zero employees and a laptop you already own, is a very different animal than $445 in a traditional business.

And here’s the thing about the margins: they don’t drop much between the for-sale and not-for-sale groups. The plateau-ers have a median margin of 85%. The growing projects: 80%. The economics of the business model are sound at almost every level. What varies is growth, not structure.

The failure mode for most of these projects isn’t bankruptcy or debt. It’s “I made $445 a month for a while and then stopped.” That’s a strange kind of risk to be afraid of.

The Ladder Effect

Here’s what I think is the most underappreciated insight in the data. Look at the distribution again.

About 51% of the core projects are under $500 MRR. But once you zoom into the $1,000 to $5,000 band, something shifts. There are 122 startups there, a real cluster.

Projects like Guidejar, which helps teams create interactive product walkthroughs, at $4,874 MRR. Or TranslateMom at $4,788. Then 42 more between $5,000 and $10,000, like Prymatica at $9,926 or AgentGPT at $9,827. And 28 more between $10,000 and $16,000.

The taper is gradual. It’s not a cliff at $1,000 where almost everyone falls off. It looks more like a ramp, with meaningful numbers at each level.

And remember the bias: the not-for-sale projects in this range have a 651% average 30-day growth rate. The ones you don’t hear about, the ones whose founders are heads-down building rather than listing for acquisition, are growing fast. The ladder effect is real, and it’s probably more pronounced than the data suggests, because the rockets aren’t on the marketplace.

The hard part isn’t climbing from $5,000 to $10,000. The hard part is getting to $1,000 in the first place. The projects that make it there tend to keep moving.

There’s something worth sitting with here. If you’re at $200 MRR, you’re not halfway there. You’re still in the hardest part of the climb. That’s not a reason to stop. It’s a reason to not mistake early traction for momentum.

The Outlier Tier

Now the 103 startups I set aside. Their median MRR is $37,000. Their average is $102,000.

At the top: Stan at $3.5M MRR, a creator monetization platform. Then Rezi, an AI resume builder at $287,000 MRR. Cometly, an ad analytics platform, at $234,000. And Editee.com, an AI image editing tool from the Czech Republic, at $169,000.

These aren’t really indie hacker projects anymore, at least not in the sense most people mean. They’re real businesses that happen to have started with a single founder. Marc himself noted the milestone when TrustMRR crossed “$1B of startup revenue now verified”… impressive, but worth remembering that the top handful of projects account for a disproportionate share of that number.

What’s interesting is that even in this outlier group, the categories are familiar: software, AI tools, content creation, analytics. The difference isn’t that they found some exotic niche nobody had thought of. They built something in a crowded space and found distribution that compounded. PROSP, a French B2B prospecting tool at $128,000 MRR, is a good example: a familiar category, executed well, with a clear audience.

US dominance is much stronger in the outlier tier. Most of the top 15 named outliers are American, regardless of the France bias in the overall database. The really large outcomes are still largely American. That gap hasn’t closed yet.

What the “For Sale” Numbers Are Actually Telling You

Let me come back to the 38% of core projects listed for sale, because I think there’s more signal here than just a marketplace stat.

The median asking price in the core group is $30,250. For a project at $500 to $2,000 MRR, that’s a reasonable outcome for something that might have taken three months to build. The math often works. But the reason these projects are for sale matters.

The data shows that for-sale projects have higher median MRR ($727) than the not-for-sale ones ($319), but dramatically lower growth (119% vs 651%). These are plateau projects. The founder built something, got it to a certain level, and then either hit a ceiling or simply got bored and wanted to move on.

There’s nothing wrong with that. Building something small, selling it, and reinvesting the capital and learnings into the next project is a legitimate arc. I know something about that personally. But it does mean you should read the overall database numbers knowing that a significant portion of what you’re looking at is “projects whose founders have decided they’ve done what they can with them.”

The healthy, growing, exciting projects are mostly somewhere else — heads-down building, not listed for sale.

What I Take From This

The honest read of TrustMRR is that it shows you a particular slice of indie hacking: projects that are public, somewhat connected to Marc Lou’s community, and either early-stage or past their growth peak. It’s a useful slice, but it’s not the whole picture.

Within that slice, two things stand out.

First, the median is lower than most people think, and probably lower than even TrustMRR’s own numbers suggest, once you account for the biases. $445 is the median of a self-selected, transparency-oriented, partially plateau-ed group. The true median of all indie hacker attempts ever made would be much closer to zero.

Second, and this is what I find genuinely encouraging, the business structure is remarkably good. Median margins of 81%. Low overhead. No inventory. Global distribution from day one. Even the stagnating projects keep most of what they earn. That’s not the case in almost any other category of small business.

Marc Lou told the story of living in a centipede-infested apartment in Osaka in 2018, paying rent with acting gigs, feeding himself with cup ramen after two years of building and making $0.

He’s now making $94,000+ per month across his portfolio, with TrustMRR itself generating $31,000 in January 2026 alone. That arc is real. It’s also not the median. It’s the outlier who built the platform the rest of us are analyzing.

But here’s what I think the data is actually saying, if you read it charitably and honestly: most people who try this will struggle, but the ones who find something that works end up with a business structure that’s better than almost anything else available to an individual without capital. And the projects that make it to $1,000 MRR, past the hardest part of the climb, tend to keep moving.

Most of the projects in this dataset are less than two years old. A lot of them haven’t had time to compound yet. The for-sale ones have plateaued. The not-for-sale ones are growing at 651% per month on average.

The rockets aren’t on the marketplace. They’re still being built.

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

Somewhere in Singapore, a software engineer is sitting at his desk earning $105,000 a year. Safe job, respected company, good life by any measurable standard.

And he’s miserable.

Not dramatically miserable. Not “I hate my boss” miserable. More like “is this it?” miserable. The quiet kind that builds slowly, that you try to rationalize away, until one day you can’t anymore.

That’s where was in 2021. And what he did next is the reason I wanted to write about him.

He quit.

Not with a plan. Not with a product already making money. Just with two years of savings, a laptop, and the vague conviction that building things for himself would feel different than building things for someone else.

It did. Though not in the way he expected.

The Six Months That Taught Him Everything

Before Tony built anything successful, he failed spectacularly at something that looked responsible.

In early 2020, during the pandemic lockdowns, he decided to build a Log Viewer app for macOS. Beautiful design. Rich features. Ninety-five percent test coverage. He spent six months on it, working nights and weekends, doing everything right by any engineering standard.

He never launched it.

Not because something went wrong. Because nothing went wrong except the thing that mattered most: he’d been building in the dark for half a year, with no validation, no users, no feedback, nothing. By the time he looked up from his code, the idea felt stale and the motivation had drained away.

Zero revenue. Six months gone.

Most people would have gone back to the safe path after that. Tony decided to learn the opposite lesson.

Two Weeks vs Six Months

A month after abandoning the Log Viewer, he built DevUtils. An offline toolbox for developers: JSON formatter, hash generator, text encoder, all in one place. Things he used every day and kept opening different browser tabs to find.

He finished it in two weeks.

It wasn’t perfect. It wasn’t trying to be. He put a $9 price tag on it, posted it on Hacker News, and watched it hit the front page for a few hours.

His first internet money.

When he talks about this moment in his book, you can feel the weight of it. Not because of the amount (it wasn’t life-changing revenue), but because something clicked. The difference between six months of building and two weeks of building wasn’t quality. It was feedback. DevUtils shipped and immediately told him something. The Log Viewer never had the chance.

That lesson became the spine of everything Tony built after.

Building in Public, the Actual Way

By 2021, Tony made a strategic decision that looks obvious in hindsight but takes real courage to execute: he started sharing everything.

Not a curated version. Everything.

Revenue numbers. New features. Things that weren’t working. The slow months. The milestone tweets that look celebratory but are always followed by “here’s what I had to figure out to get here.”

He grew his Twitter following from nearly zero to 97,000 in two years, but that wasn’t the interesting part. What’s interesting is why it worked. His audience grew because they trusted him. And they trusted him because he’d been honest with them, consistently, before he had anything impressive to show.

This is a thing most people get backwards. They think you share publicly when you’ve earned the right to, when the numbers are big enough, when the story has a clean arc. Tony shared from the beginning, when the numbers were small and the arc was nowhere in sight, which is exactly what made people care.

BlackMagic: A $14K MRR Business You Can’t Control

In May 2021, Tony built something as a joke. A script that put a progress bar around his Twitter profile picture showing how close he was to his next follower milestone.

People lost their minds over it.

So he turned it into a product. BlackMagic became a full SaaS for Twitter creators, packed with analytics, CRM tools, thread scheduling, a Chrome extension. He went from $0 to $300 MRR in three months, then kept going. By mid-2023, it was at $14,000 per month.

Then Twitter changed its API pricing. Overnight, the cost to run BlackMagic went from manageable to $42,000 per month. That’s not a business problem, that’s an extinction event.

He’d turned down a $500,000 acquisition offer months earlier. Now he had two weeks to find a buyer before the whole thing became worthless. He sold for $128,000.

I’ve thought about this a lot. Because it would be easy to frame it as a disaster, and in some ways it was. But Tony processed it differently. He’d built something from nothing, grown it to meaningful revenue, and exited with cash. The ending wasn’t what he planned, but the business worked. And the lesson it taught him about platform dependency shaped everything that came next.

TypingMind: One Day to $22K in a Week

March 1, 2023. OpenAI releases the ChatGPT API.

Tony had been using ChatGPT obsessively, frustrated by the interface every single day. The moment the API dropped, he registered TypingMind.com.

He built the first version in one day.

Not “one day” as a polished way of saying “a very fast sprint.” Literally one day. A better ChatGPT interface: faster, with persistent history, search, proper organization. He launched it, tweeted about it, and went to bed.

By the end of the week, he’d made $22,000.

The price was $9. He raised it to $39 within days. By mid-2023, TypingMind was doing $30,000 per month. By the end of 2024, including enterprise deals and B2B contracts, he was clearing around $83,000 in a single month with margins of 85%.

The product wasn’t revolutionary. The execution was. He saw the window, understood what frustrated users, and moved before the moment closed.

This is the thing that people miss when they look at Tony’s success. They see the revenue numbers and think he got lucky. But he’d been building for three years before TypingMind existed. He’d shipped, failed, iterated, built an audience, learned how to move fast, understood what his users needed. The “overnight success” was built on years of quieter work.

What’s Actually in the Book

In 2025, Tony published My Indie Book, a collection of seventy-something lessons from his journey. He sold 1,700 copies in pre-order at $19.

I’ve read through it. And what strikes me isn’t the tactics, though those are useful. It’s the tone. Tony writes like someone who’s genuinely trying to save you the mistakes he made, not like someone performing humility while telling you how to be more like him.

A few things that stayed with me:

He talks at length about the danger of building something nobody is waiting for. Not as an abstract concept, but as something he lived through. Six months of his life are the cautionary tale.

He’s honest about what distribution actually means. Having 97,000 Twitter followers didn’t make him successful. Deciding to build an audience before he needed one did. Those are different things.

And he’s clear that most of his products failed. Out of ten or more things he built, four generated real revenue. He doesn’t hide the failures in footnotes. They’re part of the story because they were part of the process.

The Pattern Underneath It All

If I had to distill what makes Tony’s approach different from most indie hackers I’ve read about, it comes down to this:

He builds for the smallest useful version, ships it before it embarrasses him too much, and then lets real users tell him what to do next. Every single time. DevUtils, BlackMagic, Xnapper, TypingMind. Each one started somewhere that felt too simple to be worth charging for, and each one grew because he was in contact with reality from day one.

Compare that to the Log Viewer, where he spent six months in his own head, optimizing for an imaginary user who never showed up.

The gap between those two approaches is everything.

There’s also something worth noting about his lifestyle philosophy. Tony works roughly four hours a day on what he finds interesting. He delegates the rest. He’s not trying to build a company that takes over his life. He’s trying to build a life that has a great business inside it. For a long time, that looked like a tradeoff. Now it looks like the point.

Why This Story Matters to Me

Reading about Tony while I’m on my own journey with Anapana, Coco, and everything else on my desk, a few things hit differently than they might have a year ago.

The first is how long the quiet period is. Tony went public with his decision to quit in September 2021. TypingMind, the product that changed everything, came in March 2023. That’s eighteen months of building things, learning, being transparent about the slow growth, not knowing if any of it would compound into something real.

Eighteen months of trusting the process before the process gave him anything dramatic back.

The second is how specific his problems were. Every successful product he built started as a personal frustration. Not a market opportunity he identified. Not a gap in a competitive landscape. Something that annoyed him enough to fix. That specificity is what gave each product its clarity, because he understood the problem better than anyone.

The third is how he handled the bad stuff. The Log Viewer. The API pricing disaster. The two products in 2022 that generated basically zero. He didn’t pretend those things didn’t happen. He wrote about them, talked about them, and kept going. That’s the version of persistence that I think actually matters: not the kind that ignores failure, but the kind that metabolizes it.

Tony didn’t build a billion-dollar company. He built a life that most people in tech would quietly trade theirs for. He crossed $1 million in total earnings in 2025, working twenty hours a week, from wherever he wants to be.

Not a bad outcome for someone who once sat in a Singapore office wondering if this was it.

—

If you’re building something too, what’s your Log Viewer? The thing you’ve been working on in the dark, without feedback, hoping it’ll be ready soon?

Maybe it’s time to ship it.

Thanks for reading One Million Goal. If you found this useful, forward it to one person who’s thinking about building something solo.

Share

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

Early supporters get everything: templates, step-by-step guides, and exclusive content. First year is totally free.

Get 100% off for 1 year

For years, I had the same problem every builder has.

Too many ideas and not enough clarity about which ones to build.

I’d get excited about something, start working on it… Then, three weeks later, I’d wonder if I’d picked the wrong thing.

Or worse: I’d forget ideas completely.

At some point I realized I didn’t need more ideas.
I needed two things:

• A way to capture every idea, without losing it

• A way to decide which one actually deserved my time

So I built a system.

From a Moleskine to Notion

I carry a Moleskine everywhere. When an idea hits, I write it down immediately.

The notebook is my thinking tool.

But every idea that survives the first spark eventually moves to Notion.

Notion is my working database. It’s where ideas become structured, queryable, comparable. It’s where I can access them from anywhere, filter by category, sort by priority, and actually make decisions.

The notebook captures.
Notion organizes.

The System

My system has three stages:

Capture → Evaluate → Commit

Stage 1: Capture

When an idea shows up, I add it to my Inbox.

Just two fields:

• Name. What I’m calling it

• Description. One sentence: what is this and for whom?

If I can’t describe an idea in one sentence, it’s not clear enough yet.

Stage 2: Evaluate

Once a week, I open the Inbox and start to answer reflection questions:

1. What’s the problem?

2. Who needs this?

3. What’s the biggest risk?

4. What could be the first move?

These four questions map to the four ways ideas fail:

• No real problem

• No real user

• Unexamined risks

• No clear starting point

If an idea survives all four, it earns the right to be scored.

If it doesn’t, I move it to Parked.

Stage 3: Commit

Only ideas with status Ready get scored.

Three dimensions, each from 1 to 5:

• Feasibility. Can I actually build this?

• Revenue Potential. Will it make money?

• Speed to Market. How fast can I ship v1?

Score = (Feasibility + Revenue Potential + Speed to Market) / 3

Then there’s one final check:

• Excitement (🔥 High / 👍 Medium / 😐 Low)

Excitement doesn’t go into the formula. It’s a tiebreaker.

If two ideas score 4.0, I pick the one that makes me want to open my laptop at night.

Coco: the system in action

Here’s a real example.

PitchPlay (now called Coco) is an ear training app for musicians.

I captured it in Inbox, then moved it to Evaluating and answered the four questions:

• What’s the problem?
  Musicians struggle with pitch recognition. Most apps are just random quizzes with no structure.

• Who needs this?
  Adult musicians who want to develop better relative pitch.

• What’s the biggest risk?
  Download, try once, never come back. Retention will make or break this.

• What could be the first move?
  Research ear training methods. Talk to 5 musicians about their struggles.

The idea survived.

I scored it:

• Feasibility: 4

• Revenue Potential: 3

• Speed to Market: 4

• Excitement: 🔥 High

Total score: 3.7/5

It ranked #2 in my list.

Then I did what I always do after scoring.

I validated.

I talked to musicians. I checked Reddit threads. I researched keyword demand. I read papers on pitch training.

Everything pointed to the same conclusion: this was the right idea to build.

So I built it.

Today, Coco is in beta, tested by 30 users, and launching publicly soon.

The weekly rhythm

I don’t touch the database on a schedule.

I add ideas whenever they show up. Sometimes daily. Sometimes once a week.

But when I’m deciding what to build next, I open Notion, sort by score, and look at the top five.

Then I ask:

• Do I have validation data for this?

• Is the timing right?

• Can I start this now without abandoning something else?

The system doesn’t think for me. It just gives me clarity.

Instead of drowning in possibilities, I’m looking at a shortlist of ideas that already passed the first filter: feasibility, revenue potential, speed, spread, alignment.

From there, the decision becomes easier.

What this system does for me

1. Nothing gets lost. Every idea has a home.

2. I don’t waste time scoring garbage. Only ideas that survive evaluation get scored. Cuts my scoring time by 80%.

3. I can move faster. When I finish a project, I have a Scoreboard of Ready ideas waiting.

Download

You can download the template here:

Download for free

What’s your system for managing ideas? Reply and let me know.

Want to follow my journey from zero to one million? Subscribe to get real numbers, lessons learned, and the behind-the-scenes story of building in public.

Subscribe now

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

I’m currently working on two projects: Anapana, the Italian meditation app, and Coco, my ear training app for musicians. Add to that a 2-year-old daughter who’s discovered the word no and you get the picture.

The only moments I have to experiment on things that aren’t urgent are lunch breaks.

Sometimes that means 60 minutes to test a new feature. Sometimes it’s scrolling through design inspiration while eating Tagliatelle al Ragù (my favorite!). And sometimes, like last week, it means accidentally redesigning your entire Substack brand.

In this post, I'm sharing the exact Midjourney prompts, the visual direction I found, and the complete workflow I used to rebrand onemilliongoal.com… so you can steal the process for your own newsletter.

But… I’m using this post to test a new funnel here. You can get all the premium posts 100% free for 1 year.

Get 100% off for 1 year

It started with Midjourney

I opened Midjourney during lunch with a simple goal: improve the header image on onemilliongoal.com.

I started browsing the Explore section, looking at what other people were creating, and I kept stopping on this one particular style. Clean. A bit editorial. Strong use of color but not overwhelming. The kind of visual that makes you want to read whatever comes after it.

I saved a few examples and started playing.

Finding the prompt

The first few attempts were… fine. But fine doesn’t cut it when you’re building a brand.

I kept iterating, adjusting, trying different angles. And then I found it, the prompt that actually worked:

Read more

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

Picture this: you’re a Stanford student, it’s Wednesday afternoon, and your professor just handed you an envelope.

Inside: five dollars ($5).

Your assignment: once you open the envelope, you have two hours to generate as much money as possible. You have until Sunday night to complete the challenge. On Monday, you’ll present your results to the class in three minutes.

What would you do?

This was the challenge Tina Seelig gave her students at Stanford’s Hasso Plattner Institute of Design in 2009.

Before you keep reading, pause for a second.

Actually think about it.

Five dollars. Two hours. Maximum profit. What’s your move?

The Obvious Path (That Nobody Took)

Most of us would probably think: “Five dollars… I could buy something cheap and resell it. Or invest it somehow. Or use it as seed money for a quick service.”

We’d open the envelope and start planning.

But here’s what happened: The teams that made the most money never opened the envelope.

They realized that focusing on the five dollars framed the problem too narrowly.

Instead, they asked a different question:

“What would we do if we started with nothing?”

And that changed everything.

What Teams Actually Did

Team 1: The Restaurant Reservation Arbitrage

One team identified a common problem in college towns: long, frustrating waits at popular restaurants on Saturday nights.

Their solution was brilliantly simple.

They spent the week making reservations at the busiest restaurants in town. Multiple reservations. Different times. All the good spots.

Then, as Saturday approached, they started selling those reservations.

$5 to skip a 45-minute wait. $10 for prime dinner time. $20 for the most popular spots.

People paid happily.

But the team didn’t stop there. They observed and optimized:

Discovery 1: Female students were better at selling the reservations than male students. Customers felt more comfortable being approached by them.

Decision: The men ran around town making more reservations. The women stayed at the restaurants, selling spots in line.

Discovery 2: The whole operation worked better at restaurants using pagers (those vibrating devices that buzz when your table is ready). The physical exchange made customers feel like they were getting something tangible for their money.

Decision: They focused their efforts on those restaurants.

By the end of the weekend, they’d turned human attention and a bit of hustle into real revenue.

Team 2: The Bike Tire Stand

Another team took an even simpler approach.

They set up a stand in a park and offered to check bicycle tire pressure for free.

If the tires needed air, they charged $1 to inflate them.

Most people paid.

Here’s what they discovered:

Discovery 1: Even though cyclists could inflate their tires for free at any bike shop, they felt grateful for the convenience and paid willingly.

This is the principle of reciprocity in action. When you give something first (even something small like checking tire pressure), people naturally want to give back.

Discovery 2: Halfway through their two hours, they stopped asking for a fixed price and started asking for donations instead.

Revenue immediately jumped.

A suggested price creates resistance. An open donation creates generosity.

Team 3: The Three-Minute Masterstroke

But the team that generated the most profit, $650, did something completely different.

They never used the five dollars. They never used the two hours either. They looked at the entire assignment and asked:

“What’s actually the most valuable asset we have?”

The answer was the three minutes of presentation time on Monday in front of a room full of Stanford students. So they sold it.

They created a three-minute recruitment video for a company that wanted to hire Stanford students, and they played it during their presentation slot.

While everyone else was explaining what they did with five dollars, this team was running an ad.

They recognized a resource nobody else even noticed: attention.

A room full of smart, ambitious students, all focused on one screen for three minutes.

That’s worth a lot more than five dollars.

The Lesson I Keep Coming Back To

I’ve thought about this story a lot over the past few months.

Because when you’re building solo, constraints are everywhere.

Limited time. Limited money. Limited attention. Limited reach.

It’s easy to fixate on what you don’t have.

But here’s what the $5 Challenge taught me:

The constraint you think you’re facing is rarely the real constraint.

Those students weren’t limited by five dollars.

They were only limited by five dollars if they chose to frame the problem that way.

The moment they stepped back and asked “What do we actually have access to?” the problem transformed.

• Team 1 had time and effort. They turned that into restaurant reservations.

• Team 2 had a service people needed and a psychology principle. They turned that into donations.

• Team 3 had three minutes of attention in a valuable room. They turned that into $650.

None of them were limited by the five dollars.

They were limited by how they saw the problem.

There’s Always a Path

When I’m stuck on a product decision or frustrated by what I can’t do as a solo builder, I try to remember this:

There’s always a path forward. It’s just not always the obvious one.

Maybe you can’t afford ads, but you can write in public.

Maybe you can’t hire a designer, but you can study design systems and build taste.

Maybe you can’t raise funding, but you can talk to users every single day and build exactly what they need.

The path reveals itself through experimentation.

Not through planning. Not through waiting for the “right” resources.

Through trying, observing, adjusting, and trying again.

So here’s my question for you:

What constraint are you fixating on right now?

And more importantly:

What resource do you already have that you haven’t noticed yet?

Maybe it’s not the five dollars in the envelope.

Maybe it’s something else entirely.

Thanks for reading One Million Goal. A special thanks to Irene for sharing the original article with me.

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

Every night looks the same lately. Put Isabel to bed. Clean up. Open the laptop. Check the metrics. Read the feedback. Plan tomorrow.

Tonight I’m doing something different: actually stopping to write down what happened this month.

I spent January listening.

Anapana had thousands of active users telling us what worked and what didn’t through app reviews, support messages, and behavior patterns we couldn’t ignore.

Coco had 30+ beta users sending detailed feedback: memory leaks, missing play states, courses that were too long before the exercises started.

Every message was either “this broke” or “I didn’t understand this.”

Both were equally useful.

That’s what this month was about: people helping me build something worth using.

What’s on My Desk

Coco Ear Training

Coco is finally ready.

Well, almost.

I spent January fixing everything that feedback revealed:

• Bugs: Memory leaks, crashes, performance issues that only showed up when real people used it in ways I hadn’t imagined.

• UX improvements: Theory lessons are now shorter and tighter. People wanted to get to the exercises faster, so I restructured the entire learning flow.

• Audio engine rewrite: This was the big one. I had over 400 audio files per instrument (one file for every note, chord, interval). It worked, but it was bloated and slow. Now I have 32 files per instrument and generate everything on the fly by playing multiple notes together. A chord is just three notes played at once. Obvious in theory. Not so obvious to code, even with AI helping.

• New features: You can now change instrument sounds and practice with scales exercises.

Right now, Coco has two complete courses:

• Relative Pitch: Learn to recognize notes by comparing them to a reference.

• Perfect Pitch: Train your ear to name notes without any reference.

What’s left before launch? Four more courses:

• Melodic Intervals

• Harmonic Intervals

• Chords

• Scales

Once those are in, I’m going public. Target: next week.

I’ll also publish a full “How I Build” deep dive on the entire process… from research to launch. If you want to read it, subscribe.

Subscribe now

Anapana

Product

January was about fixing some frictions. We were tracking user behavior and discovered a problem: passwordless authentication was creating drop-off.

The flow seemed simple to us: enter your email, get a code, paste it, you’re in.

But users were getting stuck. Some never received the code. Others didn’t understand what to do next. A few just gave up.

So we added Google and Apple sign-in. One tap, you’re in. No codes, no waiting.

Registration is now faster, simpler, and way less frustrating.

We also shipped:

• Fixed track playback and completion tracking (community-reported issues that were breaking sessions)

• Redesigned the practice UX to feel more fluid and natural

• Added filters and search (lots of users asked for this, turns out scrolling through 200+ meditations isn’t fun)

Behind the scenes, we started building personalized paths… custom meditation journeys based on your goals and progress. Not released yet, but coming soon.

Instead of throwing 200+ meditations at you and hoping you figure it out, we’re going to guide you.

Here’s how it works: during onboarding, we’ll ask you 10 questions to understand your goals, experience level, and what you’re struggling with. Then we’ll generate a custom path just for you… specific practices, in a specific order, designed to help you build a real habit.

No more choice paralysis. Just clarity.

Growth

We spent January building organic and paid acquisition channels from scratch.

The big focus was ASO (App Store Optimization). Last Friday we released a major update:

• Changed the app name from “Anapana Studio” to “Anapana Mindfulness Studio”

• Updated the subtitle to “Meditazione in italiano”

• Rewrote the description

• Created new screenshots

The results were immediate:

• Keyword: Mindfulness. Before: Position 141. After: Position 66.

• Keyword: Meditazione. Before: Not ranked. After: Position 161.

• Keyword: Respirazione. Before: Not ranked. After: Position 124.

It usually takes 2-3 weeks to see the real impact, so we’re still monitoring. But early signs are promising.

I’ll write a dedicated post soon about everything I learned this month on ASO.

We also launched the Anapana Mindfulness Journal, a Substack blog to support SEO and content-driven growth.

And we’re starting to experiment with performance marketing on Meta to test paid acquisition alongside organic channels.

February is when we shift from foundations to growth.

Babytales

Still on hold while we sort out the printing provider situation.

Substack

One Million Goal reached 514 subscribers (+39 since December).

This month I posted less frequently and the growth reflected it. The numbers don’t lie: consistency drives growth.

So February is going to be an experiment:

• 2 posts per week

• 5 notes per day

I want to see if volume and frequency actually move the needle or if it’s all noise.

I also completely restyled the blog this month. New logo, new style, new images. What do you think?

And I activated the paid subscription tier this month. Not because I have a paid content strategy yet, but because I’m curious if having that option changes how Substack positions the newsletter algorithmically.

Will it impact discoverability? Recommendations? I have no idea. But the only way to find out is to test it.

Metrics Snapshot

• Anapana: Revenue metrics remain private (shared project), but we’re profitable with healthy margins and reached break-even months ago.

• Babytales: €0

• Coco: €0 (not launched yet)

• HeyBloom: still in private mode

One Million Goal (Revenue to Date): €220,069.80

Reflections

Last week I had a call with a friend.

We talked about growth strategies, specifically the kind of creative, organic tactics that actually work without burning money on ads. Things like UGC farming and TikTok research loops.

I’ll share more on this soon. For now, I’m just absorbing and thinking about how to apply it to Anapana and Coco.

The theme of January, though, wasn’t strategy. It was community.

I’ve spent years building products inside companies where feedback came through layers: PMs, user research teams, support tickets filtered and summarized.

Building solo is different.

When someone sends you a message saying “this crashed” or “I don’t understand this part,” you feel it directly. There’s no buffer. No one to delegate it to.

It’s a gift. The people who take time to tell you what’s broken. They care. They want you to succeed. And that’s worth more than any feature roadmap.

What’s Next

• Anapana. Shifting to growth mode in February after a month of foundational work.

• Coco launch. Next week. Finally.

• Events. Two speeches coming up:

  • February 10th – Trieste: “Sviluppiamo un’app in 60 minuti con l’AI” (building an app in 60 minutes with AI, live on stage). Here’s the link.

  • February 19th – Milan: “Quando costruire non è più il problema” (when building is no longer the problem: a talk about how AI changed product development in 2026). No link yet but drop a comment, I’ll answer it as soon as the link is available.

• Substack. Experiment with 2 posts per week and 5 notes per day.

Thanks for reading One Million Goal.

If you are building something, here’s a little reminder:

Ask for feedback early. Ask for it often. And when people give it to you, actually use it.

The gap between “I built something” and “I built something people want to use” is just that: listening.

Have a good month!

Marco Santonocito

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

Years ago, I thought I’d follow the classic path.

Build a startup.
Raise money.
Grow a team.
Scale to dozens of people.

To understand that world, I stepped fully into it.

I spent years as a C-level, working alongside incredible CEOs.
I read everything about leadership.
I learned how to build organizations, how to design teams, how to make companies scale.

And somewhere along the way, I found my style.

I’ve always believed one thing deeply: a company can only grow if the people inside it grow.

In one of the final episodes of Ted Lasso, the coach of Manchester City tells Ted:

The whole series revolves around that idea.
If the people around you get better, everything else follows.

I felt the same spark when I read an interview with Giorgio Locatelli, the Michelin-starred chef behind Locanda Locatelli.

He once said his success isn’t measured in stars or revenue, but in how many chefs he’s helped grow beyond him.

That hit me hard.

Because while working in different companies, I also saw the other side.

What it really takes to build big organizations.
Hundreds of employees.
Investors.
Board meetings.
Quarterly targets.
Endless alignment.

I saw how the constant need to answer to scale creates its own gravity.

How solving problems created by scale slowly pulls focus away from what actually matters.

That’s when I started exploring a different path.

And actually, I’d already proven it could work. Years earlier, while still employed, I built a side project called Ammesso.it, an app to help students prepare for university exams. It grew through word of mouth to 120.000 users, got featured by Apple three years in a row, and I eventually sold it for €220,000.

That exit wasn’t life-changing money. But it was life-changing proof. Proof that I could build something real, on my own, and that people would pay for it.

It planted the seed. The corporate years gave me the skills, the perspective, and the patience to know what to do with it.

Indie hacking.
Solopreneurship.

Building products alone, or in very small teams, with the goal of creating value and real impact.

That’s how One Million Goal was born… not from zero, but from that first exit, those years of learning, and the quiet conviction that there’s another way.

And yes, the name can be misleading.

The goal isn’t “to reach a million.”

The goal is to prove to myself, and to anyone watching, that there’s another way to build something meaningful.

With ambition, yes. But without drifting away from what really matters.

If, along the way, this small blog inspires someone to start their own journey, to define their own One Million Goal… I’d already consider this a success.

Because this was never just about numbers.

It’s about believing in your values. About proving you can build something important without losing yourself in the process.

One Million Goal is a compass.

And the direction it points?

Toward a life where ambition and integrity aren’t opposites.
Where growth doesn’t mean sacrifice by default.
Where you can build something extraordinary and still be there for dinner.

That’s the real goal.

So now I’ll ask you… What does your One Million Goal look like?

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

This year I left my job.

I stepped away from a comfortable role, a clear title, and a predictable path to continue the journey I started years ago, when I sold my first product and realized I could make money doing what I love.

December 2025 is the moment where that decision stopped being theoretical and started to feel real. One product is scaling. Another is about to launch. And for the first time in a long while, I feel fully responsible for every next step.

This post is a snapshot of where things stand, what I learned, and how I’m thinking about what comes next.

What’s on my desk

Anapana

Anapana is no longer in the “does this work?” phase.

It works. It’s growing. And that changes the kind of decisions you need to make.

December wasn’t about chasing shiny features. It was about building foundations for the next phase.

We shipped:

• Deeper analytics, so we can observe real behavior instead of relying on assumptions,

• Anapana Wrapped, which helped organic distribution,

• More meaningful streaks, shifting the focus from binary completion to actual time spent practicing,

• Apple Health integration, embedding meditation into users’ broader wellbeing routines,

• A more intentional onboarding, designed to understand users’ goals and needs,

Individually, none of these features are game-changers. Together, they created context. That context led to a clear insight.

Most users start Anapana with the 30 Days of Meditation program. It works. They complete it. Engagement is high.

Then something changes.

Once the introductory program ends, users are faced with more than 200 meditation tracks. What should feel empowering becomes overwhelming. Abundance turns into paralysis.

Users told us this directly:

“I don’t know what to do next.”

The problem wasn’t content. It was choice.

That’s why we’re introducing Meditation of the Day. A shift from catalog to guidance. A Home centered on today, not on everything you could do.

When users open Anapana, they see one clear proposal for the present day.

This is the direction Anapana is taking into January 2026.

If you’re curious to experience the app, you can download it on your phone (the app right now is only in Italian 🇮🇹):

• Anapana Studio for iPhone

• Anapana Studio for Android

Take the 7-day trial and see how the practice feels for you… and please send me any feedback you have, it helps us a lot.

Coco

Coco is almost ready to launch, but the real win didn’t come from shipping features faster. It came from structuring a repeatable way to build.

I used Coco as a deliberate testing ground to consolidate my end-to-end workflow: from idea to distribution. The goal wasn’t just to ship a product, but to prove to myself that I can consistently build high-quality apps in a short time, without sacrificing clarity or code quality.

The workflow starts far from code.

It starts with a problem, usually observed in real life. From there, I translate that problem into one or more ideas and move into research. For Coco, this meant mapping competitors across mobile and web, doing deep analysis with tools like ChatGPT and PeterAI, and collecting everything inside a structured Notion database.

Those insights then feed into a first MVP draft, again using ChatGPT. Not as a spec to blindly follow, but as a way to pressure-test assumptions early.

Only then do I move to design.

I use Figma to define the main screens and a lightweight design system. The goal isn’t perfection, but consistency.

Development happens in Cursor, with a clear sequence:

1. Build design-system components one by one;

2. Assemble pages using those components;

3. Implement core functionality (backend + mobile);

4. Publish early on TestFlight and collect honest feedback;

5. Add the paywall and start monetizing as soon as possible;

This process is now solid enough that I plan to write a dedicated post about it, including prompts, tools, and Notion templates.

⚠️ If you’re curious to try Coco early, you can join the beta by filling out this short form (3 mins).

Metrics snapshot

Here’s a transparent snapshot at the end of December:

• Babytales: €0. Still blocked by an unresolved issue with the printing company.

• Coco: €0. Not launched yet.

• HeyBloom: still in private mode.

• Anapana: 24,981 registered users.

One Million Goal (Revenue to Date): €220,069.80

This Substack has 471 subscribers total (+77 this month).

Reflections

When you’re building with a small team, shipping fast becomes a responsibility, not a side effect.

In the AI era, super-builders make this possible: people who can think strategically, design intuitively, and execute technically without waiting for permission.

But agency is fragile. It doesn’t come from tools alone, it comes from clarity. When direction is missing, people slow down not because they lack autonomy, but because ambiguity forces them to pause and ask what to do next.

That’s why we formalized Anapana’s vision, mission, and North Star. Not to add structure, but to establish clear direction.

As Anapana started to grow and a micro team formed around it, I felt a familiar tension. Not chaos yet, but the early signals of it. The kind that doesn’t break things immediately, but slowly erodes speed and confidence if left unchecked.

I’ve seen this before.

In many companies, I’ve seen smart, motivated people get stuck not because they lacked skills, but because direction from founders or managers wasn’t clear enough. Decisions slowed down. Alignment moved to meetings. Agency turned into permission.

I didn’t want to repeat that mistake.

This time, I wanted alignment to be explicit, not assumed. Something stable enough that people could use it to decide without asking.

That’s why we clearly defined:

• Vision: To make mindfulness a daily, practical skill accessible to everyone. Not a luxury. Not a monk’s ritual. A habit for navigating modern chaos.

• Mission: To provide guided, personalized, and accessible tools to improve psychophysical wellbeing, day after day.

• North Star Metric: Daily active users who complete at least one conscious action.

This isn’t about control. It’s about freeing agency.

In many ways, this reflection is also about me. After years as a CPTO, being fully hands-on again reminded me how costly misalignment is… and how powerful clarity can be.

What I’ve been reading

For a long time, I optimized my reading for usefulness.

Business books. Product books. Frameworks.

In 2025, I realized that this habit was narrowing my thinking. I wasn’t just learning how to build better products. I was training myself to see the world through a single lens.

So this year I made a deliberate shift.

I didn’t stop reading to get better at business. I started reading to get better at being human.

Some books that stayed with me:

The End Is My Beginning by Tiziano Terzani

This is not a book you read quickly. It’s a conversation about life, death, curiosity, and meaning.

Terzani’s calm perspective puts ambition back into context. Especially when you’re building, it reminds you that urgency is often self-imposed, and that a wider view makes better decisions possible.

The Science of Meditation by Daniel Goleman

A grounding read for anyone working on mindfulness without wanting to drift into mysticism.

It connects inner practice with neuroscience and measurable effects, reinforcing the idea that awareness is not abstract, but trainable. Reading this while building Anapana felt particularly aligned.

Trillion Dollar Coach by Eric Schmidt, Jonathan Rosenberg, Alan Eagle

Less a leadership manual and more a portrait of how trust scales.

Bill Campbell’s influence came from caring deeply about people while holding them to high standards. It resonated with my desire to build small, high-agency teams without heavy process.

Let My People Go Surfing by Yvon Chouinard

This book quietly challenges the idea that growth requires compromise.

It’s about building a company that reflects a way of living, not the other way around. A strong reminder that values are not something you add later, they’re something you design early.

Tools of Titans by Tim Ferriss

Not a book to read cover to cover, but to browse.

What it reinforced for me is that there’s no single path, routine, or formula. People who do interesting things tend to design lives that fit them, not templates they found online.

Bonus: Blue Giant by Shinichi Ishizuka

I’ve always loved manga, and this one genuinely surprised me.

It’s a story about obsession, discipline, and showing up every day for your dream, even when no one is watching. It captures something deeply familiar if you’re building anything long-term: the loneliness of practice, the repetition, and the quiet belief that consistency compounds.

Reading it reminded me that progress often looks boring from the outside, and that commitment matters long before results do.

What’s next

The first priority is Anapana.

Meditation of the Day is ready to become the new center of the experience. It’s the natural consequence of everything we learned this year: less choice, more guidance, more continuity. I’m excited to see how users respond once the app starts answering a single question clearly, every day.

At the same time, I’m preparing to launch Coco. Not just as a new mobile app, but as proof that the workflow I’ve been refining actually works end to end.

Coco is the result of a more structured way of building: clearer research, tighter design systems, cleaner development, and earlier monetization. Launching it feels less like a leap and more like the next logical step.

On the content side, I’m deliberately keeping things simple. I’ll stay active on Substack and LinkedIn, and resist the temptation to expand further for now. Focus is fragile, and I’d rather compound a few channels than dilute my attention across many.

January will be dense, but intentional. Two launches. Real feedback. Fewer abstractions.

As always, I’ll keep sharing the process.

Let’s see where this goes.

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

A few days ago I read a post by titled “The science of helicopter parenting and what happens when parents overhelp.”

It’s one of those pieces that stays with you, not because it tells you something radically new, but because it gives words and structure to a tension you already feel.

The core idea is simple:

When parents overprotect, overguide, and overhelp, they unintentionally prevent children from developing autonomy. Growth requires friction. Remove all of it, and you don’t get safety. You get fragility.

Reading it brought me back to a concept I first encountered years ago, while working as Head of Product at Talent Garden. It was introduced to me by , our CDO at the time, and it’s called the Productive Zone of Disequilibrium.

The uncomfortable space where growth happens

The term comes from Ronald Heifetz, professor at Harvard and co-creator of the Adaptive Leadership framework.

At its core, the idea is this:

People grow not when they feel perfectly safe, and not when they feel overwhelmed, but in the narrow band in between.

Leadership, according to Heifetz, is about helping people navigate adaptive challenges: problems with no known solution, where learning and experimentation are required.

To do that, leaders must create what psychologists call a holding environment. A space that is both:

• Safe enough that people don’t panic or shut down;

• Uncomfortable enough that they can’t stay exactly as they are;

Donald Winnicott, a pediatrician and psychoanalyst, used this idea to describe good parenting long before it entered leadership theory.

Think of a child learning to ride a bike.

The parent runs next to them. The child does all the work: balancing, pedaling, steering. They wobble. They struggle. They might fall.

But they also know someone is there.

If the parent holds the bike the entire time, the child never learns.
If the parent lets go completely, too early, the child panics.

The holding environment is that subtle, dynamic balance.

The Productive Zone of Disequilibrium

Heifetz visualizes this with a simple mental model.

On one axis, you have time. On the other, the level of disequilibrium or stress a person experiences.

There are two key thresholds:

• A threshold of change: below this, nothing happens. People are comfortable, competent, and static.

• A limit of tolerance: above this, people freeze, panic, or disengage.

The space between these two lines is the productive zone of disequilibrium.

That’s where creativity happens.
That’s where people experiment.
That’s where learning sticks.

When someone is below the threshold, they raise the temperature: more responsibility, a harder problem, a new constraint.

When someone is above their limit, they lower it: structure, guidance, reframing, support.

Not by giving answers, but by helping people find their own.

Why this suddenly feels very personal

Here’s the interesting part.

Reading about helicopter parenting, and thinking again about the productive zone of disequilibrium, made me realize how closely this applies to my current phase as a founder.

There’s no manager setting the temperature now.
No organization acting as a holding environment.

It’s just you.

And the temptation is the same one described in parenting:

• Either overprotect yourself, staying in safe territory, polishing what already works

• Or push too hard, stacking too many bets, too much pressure, too fast

Both are forms of miscalibration.

Founders, much like leadership, is a continuous act of self-regulation. You are constantly asking:

• Am I bored or avoiding discomfort?

• Or am I overwhelmed and pretending it’s “just hustle”?

Progress doesn’t come from eliminating disequilibrium.
It comes from learning to stay inside it, deliberately.

A useful question to keep around

So here’s a question I’ve started asking myself more often, and one I think applies equally to leaders, founders, and solo builders:

Am I below my threshold of change, or above my limit of tolerance?

If you’re below it, you probably need a bigger challenge.
If you’re above it, you probably need more structure, not more pressure.

Growth lives in between.

And maybe that’s the real job, whether you’re leading a team or yourself:
not removing friction, not glorifying stress, but learning how to tune the temperature.

Because nothing meaningful grows in comfort.
And nothing grows in panic either.

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

A week ago I was in Turin at a Product Heroes event and I… may have made a questionable life choice.

I walked on stage and decided to build a brand-new product live, in front of lots of people, starting from absolute zero, using only ChatGPT and Lovable… and to launch it before the meetup ended.

Yes, I know. High-risk. Low-sanity. But that’s exactly why I wanted to do it.

Here were my rules:

1. Start from zero. Okay okay… I did prep a couple prompts beforehand; because honestly, no one deserves to watch me stare silently at a blank screen, pretending to “think deeply.”

2. Ship something real. No fake screens. No prototypes. A working product with real UI, real logic, and real constraints.

3. Landing page + paywall included. If people can’t pay for it, it’s not a product… it’s a school project.

4. Launch it live. No backstage fixes. No “I’ll finish it tonight.” What ships, ships.

It could have been a huge win.
It could have been a hilarious disaster.
Either way, everyone in the room would see everything… in real time.

This post is the full story: the idea, the workflow, the prompts, the research, and how I used AI as a full product team to design, build, and deploy an MVP in under 60 minutes.

The Idea

Let me start from something personal.

I’m a musician. I play the piano. For years I even had a jazz band… then life happened, as it always does, but I never lost the passion.

And there’s another detail: I have perfect pitch.

As a kid, I genuinely thought it was some kind of superpower.
No one in my family played music.
Yet I could recognize every single note instantly, as if they had colors or flavors attached to them.

For most of my life, I believed it was a gift.
Something you’re born with.

Then a few years ago I read Peak, the book by Anders Ericsson, and came across a research paper that completely flipped that belief upside down.

It was a longitudinal study by Ayako Sakakibara, a Japanese music psychologist who followed 24 children aged 2–6 and trained them using a specific technique called the Chord Identification Method (CIM).

And the results?

22 out of 24 children successfully acquired perfect pitch after structured, daily micro-training sessions (but 2 of them left the study earlier).
A 92% success rate.
Zero “gifted” kids.
Just a method.
Just consistency.
Just early learning.

Here’s the study, in case you’re curious.

What blew my mind is how simple the training actually was:

Step 1: Associate each chord with a color

Sakakibara used 9 major triads (the “nine white chords”).

Each chord always had the same color (e.g., C–E–G was red, C–F–A was yellow, etc.)

No note names.
No theory.
Just color.

Step 2: Tiny sessions, many times a day

Children trained in 2–5 minute sessions, repeated 4–5 times per day, for a total of about 100 chord trials per day.

This structure allowed them to stay focused, avoid fatigue, and build the skill almost subconsciously.

Step 3: The magical shift: height → chroma

This is the most important part… the “aha” moment of the entire study.

At first, children don’t understand chords. They only recognize pitch height: “this one sounds higher,” “this one sounds lower.”

But after a few weeks, something clicks.

They move from identifying height to identifying chroma, the pitch category which is exactly what perfect pitch is.

This transition is documented across multiple pages where Sakakibara analyzes how children’s errors change over time.

This shift is the foundation of perfect pitch.

And it happens consistently.

So I asked myself: what if we turned this into an app?

Ever since I discovered this research, I’ve had this obsession:
One day, I want to build an app that helps kids develop absolute pitch.

A playful, science-backed app for children aged 2–6 that helps them train absolute pitch with:

• Tiny daily chord games

• Bright color cards

• Simple auditory feedback

• Zero music experience needed

• And a method validated by a 2-year study

An app that feels like a game… but is powered by real cognitive science.

That’s how ChromaKid was born.

And that’s the idea I decided to build live on stage.

The Plan

When people imagine AI development, they picture someone opening Lovable and typing:

Hey Lovable, build me an app.

Nope. That’s a guaranteed way to suffer.

Before touching Lovable, my process always starts with one phase, the most important one: Planning.

Lovable is execution.
ChatGPT (or your favourite model) is everything before that.

Here’s how the dance works… not as a list, but as a flow.

Step 1: Give ChatGPT the real context

I don’t just drop the idea.

I tell it:

• why I want to build this

• for whom

• the educational goal

• time constraints

• what MVP means in this specific case

• what success looks like

• what cannot go wrong

If the AI doesn’t understand the context, it can’t make good decisions. Simple as that.

Step 2: Feed it the raw material

A few days before the live building, I sat down with ChatGPT and uploaded the Sakakibara study.

This thing is 26 pages long, super technical, full of cognitive theory, error charts, chord tables… the kind of paper you read once and think: “Ok cool… and now what?”.

So I asked ChatGPT to do something very specific: turn the research into a real MVP. Not just “explain the study.” But translate it into an app.

This was the prompt:

I’m sharing with you the full research paper by Ayako Sakakibara (2012) about how children aged 2–6 can acquire absolute pitch through daily training based on chord identification.

Using the insights, methodology, and findings from this study, help me design a complete, science-based product plan for an MVP called “ChromaKid”: a responsive web app that helps young children develop absolute pitch. 

Your plan should:
1. Extract the key principles of the training method (frequency, chord sets, chroma vs. height, learning progression, plateau/doldrums, feedback style).
2. Translate these principles into a modern, digital, child-friendly experience.
3. Outline the core features required for an MVP (educational flow, exercises, UI, progression system, parent involvement).
4. Describe the ideal training protocol (session length, repetitions, how to simulate the Eguchi/Sakakibara method digitally).
5. Propose an exercise structure that replicates the acquisition process observed in the study.
6. Define the success metrics for the MVP (learning outcomes, engagement, parent retention, etc.).
7. Ensure everything is grounded in the evidence and constraints of the study. Be extremely concrete, structured and detailed.

Don’t be generic. Build the plan as if we were about to start development today.

Step 3: Define the MVP

ChatGPT decomposed everything into a real MVP but it was too complex, now it’s my turn.

With ChatGPT, I strip the idea down to the essentials: what must exist?

Thank you! I’d like to develop only the training engine for Phase 1, it should be structured in this way:

Homepage with a list of all the Levels (from 2 to 9 chords):
- Higher levels should be showed with a locker and they activates only when the children reach a 100% accuracy for 7 days;

Training Page, structured in this way:
- identification trials counter (should be 20 per session)
- back button (if children needs to interrupt a session)
- chord played repeatedly with an animation
- Cards of different colors, children should choose the correct one.
- Immediate feedback: If correct → “Success animation + next trial”. If wrong → “Incorrect, try again” + replay chord + highlight correct card after repeat.

Step 4: Deep Dive

Before submitting the prompt I ask ChatGPT an important question. Maybe the most important.

Ask me all the questions that you want but one at a time.

This is the real cheat code.

For ChromaKid, it asked me 24 questions. Brilliant questions.

It clarified audio looping, session resets, level unlocking behaviour, streak logic, onboarding, UX constraints, database schema, error states, feedback animations, analytics, parent vs child roles,…

By the end, it understood the product better than I did.

Step 4: Write the final prompt for Lovable

The Lovable prompt is not a prompt. It’s a document.

It includes:

• context

• constraints

• pedagogy

• user flow

• UI decisions

• backend rules

• the cognitive science behind the method

• what to build

• what not to build

ChatGPT helps me craft the cleanest possible version, the one Lovable can understand without guessing.

Here’s the prompt:

Develop a scientifically grounded responsive web application called ChromaKey that allows children aged 2–6 to train absolute pitch through the digital replication of the Eguchi/Sakakibara Chord Identification Method (CIM).

1. Product Overview
The MVP must deliver a fully functional training engine, which includes:

- Authentication using Supabase
- A system of Levels from 2 → 9, where each level corresponds to the exact number of active chords available.
- Daily 20-trial training sessions that the child must complete in one sitting.
- Chord playback engine that plays a selected chord repeatedly every 2 seconds until a card is tapped.
- Full feedback loop: success animation for correct answers, error animation + forced correction tap for wrong answers.
- 7-day streak system that unlocks the next level only after 7 consecutive days of perfect sessions.
- Automatic daily reset at midnight, which starts a new training day.

Everything must be implemented with extreme simplicity and reliability. The user is a toddler; the parent is the one monitoring progress.

2. Core Concepts
This section defines the educational rules the application must obey.

2.1 Levels
Each level contains a fixed number of chord–color cards:
- Level 2 → 2 cards
- Level 3 → 3 cards
- …
- Level 9 → full set of 9 white chords 

Lovable must treat levels as states, not optional exercises. Children are always locked into the current level until streak completion.

Unlock Requirements:
To unlock the next level, the system must check:
1. Has the child completed one full 20-trial session today?
2. Was accuracy 100% (20/20)?
3. Are the last 7 days all perfect sessions?

If all conditions are met, the system must:
- Increase currentLevel by +1
- Show a small banner on Home: “New Level Unlocked!”
- Update child’s state immediately

No animations or intro screens needed for the MVP.

2.2 Chords & Color Mapping (Eguchi Standard)
Lovable must hardcode this mapping into the app:

| Chord | Color |
|-------|--------|
| CEG | Red |
| CFA | Yellow |
| BDG | Blue |
| ACF | Black |
| DGB | Green |
| EGC | Orange |
| FAC | Purple |
| GBD | Pink |
| GCE | Brown |

These color assignments must never change, and must always stay consistent throughout the experience.

2.3 Sessions
A session is a sequence of 20 trials, each consisting of:
- Random chord selection from currently active set
- Repeated playback every 2 seconds
- Child selecting one card
- Immediate feedback

Important Rules:
- Only the first session of the day counts toward streak.
- Session ends only after 20 valid trials.
- Exiting early causes full session reset.

3. User Flows

3.0 Authentication screen
Lovable must build a simple authentication screen with signup and login. 
- In the signup page user should add his first name, email and password. In the login page only email and password.
- User should be able to reset his password

3.1 Home Screen (Progression Path)
Lovable must build a simple home screen containing:
- A vertical or horizontal “path” of Level tiles from Level 2 to Level 9
- Current level stands out visually
- Locked levels must display a lock icon and be unclickable
- Unlocked levels must be clickable
- Only for authenticated users

Below the path, display a small parent-only text:
- “Streak: X/7 days”

Behavior:
- Tapping an unlocked level triggers navigation to the Training Session.
- When streak reaches 7, backend updates currentLevel → UI reflects change instantly.

3.2 Daily Training Session
Entering a Session:
- User selects Level → sees a Start Session button
- No warm-up sequence. Session begins at Trial 1.
- Only for authenticated users

Session UI Components:
Top Bar:
- Back button → exits session and resets it
- Trial counter (e.g., “Trial 7/20”)

Center:
- Pulsating circle (animated with scale or opacity)
- App must trigger chord playback every 2 seconds until the child taps

Bottom:
- Adaptive layout of color cards:
  - 2–3 cards → 1 row
  - 4–6 cards → 2 rows
  - 7–9 cards → 3 rows

The cards are large, simple, solid colors.

Trial Logic (Lovable must implement):
- Select 1 chord randomly from active chords, equal probability
- Play the chord immediately
- Continue playing every 2 seconds
- Wait for card tap

Feedback Logic:
Correct Answer:
- Display a simple success animation (e.g., brief glow or bounce)
- Move to next trial

Incorrect Answer:
- Show a red “error” animation (shake, flash, etc.)
- Replay chord
- Highlight correct card subtly (not too revealing)
- Require child to tap correct card → then treat as a correct completion

End of Session Logic:
After Trial 20/20:
1. Show confetti animation
2. Display strict summary:
   - “You completed all 20 trials!”
   - “Accuracy: X/20”
   - Perfect session = green banner
   - Otherwise neutral banner
3. Button: Go Home

Streak Logic:
- If accuracy 20/20 → increment streak
- If not → reset streak to 0

4. Unlocking Logic
Lovable must implement a daily streak system:
- Day resets at 00:00 local time
- Child must complete one full 20-trial session
- Accuracy must be 20/20

After 7 consecutive perfect days:
- Automatically trigger level unlock
- Display a small banner on the Home Screen

No animation or modal required.

5. Audio Handling
Audio Requirements:
- There will be MP3 files for each chord (ceg.mp3, cfa.mp3, etc.)
- Do NOT alter audio: no normalization, no trimming, no processing

Playback Behavior:
- On each trial: play chord immediately
- Repeat chord every 2 seconds
- On incorrect answer: replay immediately

Lovable must ensure precise timing.

6. Data & Logging
6.1 Data Stored Per Session:
- session_id
- child_id
- date
- level
- accuracy (0–20)
- counts_for_streak (boolean)
- new streak value

6.2 Data Stored Per Trial:
- trial_id
- session_id
- trial_number
- chord
- selected_color
- correct/incorrect
- wrong_selection
- confirmed_correct_tap
- timestamp

6.3 Stored State:
- currentLevel (integer)
- currentStreak (integer)

Lovable must keep these in a relational structure.

7. UI Specification
Home Page:
- Level path UI
- Level tiles
  - Unlocked tile: high opacity, tap enabled
  - Locked tile: dimmed + lock icon
- Parent streak text under the path

Training Page:
- Back button + Trial counter at top
- Pulsating circle centered
- Grid of color cards at bottom

Color Rules:
All colors follow Eguchi’s mapping exactly.

Animations:
- Pulsating circle = chord playback
- Small success animation per correct answer
- Error animation + highlight for correct card
- Confetti only at session end

8. Error Handling
Audio Load Failure:
- Show modal: “Sound issue. Please check your connection.”
- Retry button

Mid-Session Exit:
- Back button returns user to Home
- Restart session from Trial 1 next time

9. Technical Architecture (High Level)
Frontend:
- Responsive web app
- React/Next.js suggested
- Local state for session logic
- Timers for repeated playback

Backend:
Endpoints needed:
- POST /session
- POST /session/trial
- GET /level
- POST /level/unlock
- GET /streak
- POST /streak/reset

Database Tables:
- users
- children
- levels
- sessions
- trials
- streaks

Lovable must generate these according to the logging rules.

10. Success Criteria
Functional Criteria:
- Daily session runs correctly every time
- Chords loop with perfect timing
- Streak logic is accurate
- Level unlocks happen exactly on rule
- All session/trial logs are reliable

UX Criteria:
- Toddlers can complete sessions with minimal guidance
- Parents understand unlocking and streaks immediately
- Visual difficulty increases gradually and predictably

Step 5: Open Lovable

Not before.

Once the plan is solid, Lovable becomes a superpower. It turns the entire strategy into a working product.

And that’s when the fun begins.

Development

At this point, the entire product existed in my head and in ChatGPT’s head, but nowhere else.

And this is the moment I opened Lovable.

There’s always a small thrill (and a bit of fear) when you paste a massive prompt into Lovable… especially live in front of a lot of other people.

You never know if it’s going to generate a masterpiece, a good first draft… or a glowing pile of HTML spaghetti.

So I pasted the entire specification and I hit Generate.

And honestly?

The first output was shockingly good.

Iterating in Real Time

This is where the game begins.

You suddenly have a product, a real one, in less than ten minutes.

Now you can play with it.

You test it.
You tap through the levels.
You start a session.
You listen to the chord loop.
You pick a color.
You see the feedback.
And instantly, you know what needs to be added, fixed, or improved.

And here comes the beauty:
every time you need a tweak, big or small, you just switch back to Lovable, drop a prompt, and rebuild.

No friction.
No waiting for sprints.
No “can we fit this into the roadmap?”
Just: update → generate → done.

And every single time, Lovable answered like an engineer who never sleeps.

These are some of the real prompts I used to improve the product during the live session. And one thing is important:

I always refine each prompt with ChatGPT before sending it to Lovable.
ChatGPT is where clarity happens.
Lovable is where execution happens.

Here’s how that looked in practice:

Child Profile

I wanted the app to support multiple children, each with their own training progress.

Add a mandatory onboarding flow after authentication where the parent must create a child profile before accessing the Home screen.

The child profile must include the following fields:
- Child Name (string, required)
- Birth Date (date, required)
- Gender (dropdown: Male / Female / Other, required)
- Already had music training? (boolean, required)

After submitting the profile, save it in the database linked to the authenticated user (user_id → child.user_id).

Redirect the parent to the Home / Levels screen, using this child as the active child.

Also create a Child Selector. On the Home screen, display the active child’s name (e.g., “Training for: Sofia”). When tapped, open a modal listing all children belonging to the user. Each item in the modal allows:
- Selecting a child (sets this child as the active profile)
- Adding a new child profile (same form as onboarding)

Ensure all training sessions, levels, streaks, and analytics are always linked to the active child_id.

Here it is:

Analytics for Parents

Then I asked for analytics. I wanted parents to be able to see the progress of their children.

Add a new bottom navigation tab called “Analytics”. This screen should show analytics for the currently active child.

Display the following analytics components:

1. Current Streak:
   - Large number display, e.g., “🔥 Streak: 4 days in a row”.

2. Current Level:
   - Badge element showing the child’s current level, e.g., “🎯 Current Level: 4”.

3. Accuracy History:
   - A Line Graph showing the accuracy percentage over the last 7–30 days.
   - X-axis: dates
   - Y-axis: accuracy (%)

4. Total Sessions Completed:
   - Stat card, e.g., “📘 Total Sessions: 42”.

5. Best Streak Ever:
   - Stat card, e.g., “🏆 Best Streak: 9 days”.

6. Errors (Last 7 Days):
   - Stat card, e.g., “❌ Errors (last 7 days): 12”.

7. Chord/Color Accuracy Radar Chart:
   - Radar chart with 9 axes, one for each chord in Phase 1:
     CEG, CFA, BDG, ACF, DGB, EGC, FAC, GBD, GCE.
   - Value for each axis: accuracy (%) for that chord-color pair.

Ensure the chart reads from the training logs associated with the current child_id.

Here it is:

Training Flow

I noticed that the session was starting without giving children the possibility to listen to the target chords. But this is strictly required by the CIM protocol:

In every session, a child begins by repeatedly listening to one chord represented by a small colored flag.

So, here’s the prompt.

Add a mandatory pre-session listening phase before every training session, following the official Eguchi/Sakakibara Chord Identification Method (CIM).

Goal:
Before the session begins, the child must repeatedly listen to the target chord(s) and optionally tap the color cards to hear their associated chords. Only after this grounding step can the actual 20-trial session begin.

This is STRICTLY required by the CIM protocol:
“In every session, a child begins by repeatedly listening to one chord represented by a small colored flag.” — Sakakibara (2012), p. 90

## Feature Requirements

1. Replace the current “Start Session” behavior with a new two-step flow:
A) Pre-Session Listening Phase
B) Actual Training Session (20 trials)

The Training Session should not start automatically.

## Pre-session listening phase

When the parent taps the Level to train:

1. Show the colored cards for the active level (e.g., 2–9 cards).
2. Each card must be tappable.
   - When tapped, the chord corresponding to that color plays once.
   - This lets the child preview / recall the chord template.
3. Above the cards, add a simple instruction:
   - “Tap the colors to hear the chords. When you’re ready, press Start Session.”
4. Add a “Start Session” button at the bottom.
   - Disabled state until all cards are tapped.
   - Then becomes enabled.

5. The child can tap the cards to explore the sounds as long as they want.

6. When the parent/child taps “Start Session”, navigation moves to the actual training session screen.

## Actual Training Session

Start the 20-trial session exactly as before:
- Random chord selection from active set
- Repeated chord playback every 2 seconds
- Feedback logic for correct/incorrect answers
- End-of-session summary and confetti

No changes to the training logic itself.

Here it is:

Adding Payments

Lastly I made a commitment. We needed to add payments before launching our little product. Here’s the prompt.

Add support for paid plans:
- Yearly: €29.99/year
- Lifetime: €69.99 one-time payment

Use Stripe or the payment provider supported by Lovable.

Store in the database whether the user is:
- free
- yearly subscriber
- lifetime subscriber

Add a new “Upgrade” section inside the Profile screen.

The Upgrade screen must list all premium features:
- Unlimited training sessions per day
- Full access to Analytics
- All future updates included

Include buttons to purchase:
- “Buy Yearly – €29.99”
- “Buy Lifetime – €69.99”

You need to have a Stripe profile to be able to integrate payments because Lovable is going to ask you for the Stripe API key.

Here it is:

As you can see:

The distance between “idea” and “working feature” has collapsed.
It’s now measured in minutes, not weeks.

Learnings

1. AI doesn’t replace you, it amplifies you

ChatGPT didn’t invent ChromaKid. Lovable didn’t “magically” build the app.

I brought the idea, the insight, the constraints, the context, the science.

AI simply amplified that clarity.

It’s the difference between playing an instrument… and playing that same instrument with an orchestra behind you.

2. Planning is 90% of the work

The biggest misconception about AI development is that the hard part is getting the code.

It’s not.

The hard part is knowing exactly what you want the code to do.

If you can articulate:

• why you’re building something

• who it’s for

• what should happen

• how it should behave

…AI becomes unstoppable.

Most bad AI output is the direct result of bad input.

As someone said… garbage in, garbage out.

3. Speed changes the entire psychology of building

When a feature takes 3 weeks to implement, you overthink everything.

When it takes 3 minutes, you suddenly become incredibly bold.

You try things.
You adjust on the fly.
You break, fix, improvise, and iterate without fear.

Speed is not just a productivity multiplier.
It’s a confidence multiplier.

4. A solo founder today is a micro-team

This is the part that still feels unreal.

During the live session, I wasn’t working alone.
I was working with:

• ChatGPT → product strategist + PM

• Lovable → engineering team

• Supabase → backend + auth

• Stripe → payments infrastructure

One person + one laptop = four roles, zero overhead.

We are entering an era where a solo founder can operate like a small startup.
And this changes everything.

5. Save your credits

This one came from the Q&A, and it’s important.

Every prompt you run in Lovable costs credits. If you’re not planning well, if your prompt is unclear, if you keep trying random iterations, you’re basically burning money.

Good planning = fewer iterations = fewer credits.

And you have a trick to save even more: connect Lovable to a GitHub repository.

⁉️ What’s a repository?

A repository (“repo”) is simply a public or private folder where all your project’s files live, with version history included. Think Google Drive, but for code... with superpowers.

Once your Lovable project is connected to GitHub, every time it generates code, you can open that code in Cursor, or Claude’s “Projects”, or GitHub’s code reader, or any AI tool you prefer… and ask that tool questions for free or cheaper, instead of burning Lovable credits.

One attendee in the audience said:

My cofounder keeps asking Lovable questions to understand the code, and he’s burning my credits.

Solution?

Export to GitHub, open in Cursor/Claude, chat with the code. Zero credits wasted, only $20/month.

This simple workflow can save a lot of money for early founders.

6. Avoid vendor lock-in

Someone else asked:

Why not use Lovable Cloud instead of Supabase?

Because I want the freedom to switch tools the moment the project gets more complex.

⁉️ What is Supabase?
An open-source backend: Postgres, auth, file storage, APIs (no lock-in). I can take my database anywhere.


⁉️ What is Lovable Cloud?
A managed environment from Lovable where everything runs automatically, but you’re tied to their deployment, you rely on their stack, you can’t easily migrate away, and you may hit limitations later.

For an MVP → Lovable Cloud is fine.
For a product that could grow → I prefer Supabase.

Freedom > convenience.

7. “When should I use Lovable?”

This was another real question I’ve received after the event:

How is Lovable? A friend recommended it over Bubble. But I’ve tried other AI builders and I’m scared it will burn credits endlessly without producing a solid app.

Here’s my honest take:

These tools all have limitations. They are not magic. They won’t build a perfect, enterprise-ready platform for you.

But they are extraordinary at one thing:

Reducing development cost and time-to-market to almost zero.

If you have an idea and you want to test it, validate it, and gather feedback.

Start here.

Move fast. Iterate with AI. Find your Product-Market Fit. Improve your Time-To-Value. Measure conversions. Observe usage. Ship again. And again.

Once you hit traction, once the tool starts feeling tight, that’s your signal:

• dump the code into GitHub

• bring in a real developer (even part-time)

• keep using AI as support

But don’t start with a big engineering effort.

Start with speed. Start with iteration. Start with learning.

That’s what Lovable is for.

Final Thoughts

I didn’t do this challenge to show off how fast AI can build things.

I did it because something fundamental is shifting.

When I look around, I see thousands of people with incredible ideas but they’re blocked by one of three things:

• no time

• no team

• no technical firepower

AI doesn’t magically solve every problem. But it removes all three of those blockers at once.

This experiment in Turin wasn’t about an app. It was about proving something bigger:

If you can describe what you want precisely, you can build it.
If you can build it, you can launch it.
If you can launch it, you can learn.
And if you can learn… you can win.

The gap between I have an idea and I launched something is disappearing.

The only real bottleneck now is clarity, and courage.

Clarity to describe what you want.
Courage to press “Generate.”
And the willingness to look a bit crazy while building something live.

ChromaKid is just one example.
A small MVP built in under an hour.
But it represents something much bigger happening right now:

The rise of the solo builder.
The return of high-agency creation.
The era of those who actually take action.

If this resonates with you, you might be one of them.

And if you’re reading this… I hope you become the next person who stands up, opens a blank project, and says:

Let’s build something, right now.

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,069 / €1,000,000

Subscribe now

November wasn’t about shipping fast.
It was about slowing down enough to understand who I’m becoming.

I rediscovered old habits (meditation, sport), built new ones (networking again!), and had the kind of deep conversations you can only have when your brain finally gets some oxygen.

This month wasn’t just about projects.
It was about identity, and the person I’m growing into while chasing the One Million Goal.

What’s on My Desk

Fractional CPTO

I’m still supporting Testbusters as fractional CPTO, but November made something very clear: if I truly want to build the next chapter of my life, I need to protect my time.

So for a while, I’m reducing my fractional hours.

Not because I’m stepping away but because I’m stepping towards something else: the space to think, create, and experiment again.

The silence I found this month is rare.
And I don’t want to lose it.

Babytales

November forced us to make a tough call:
we temporarily stopped development on BabyTales.

Why? Printing.

Gelato, our current provider, kept losing orders. One lost in October. Three lost in November while sending books to influencers (we are trying to promote it through some UGC).

We love this project too much to let the customer experience depend on luck.
So we’re stepping aside, fixing the foundations, and finding a partner who can match the care we put into every story.

Sometimes building also means admitting that something isn’t working, and choosing the slower, better path.

HeyBloom

Not much to announce yet: I’m still using HeyBloom only for myself.

But even in this tiny private beta of one, it’s already saving me a lot of time, and that’s usually a good sign.

More soon.

Anapana: Stealth Project Revealed

Time to share something I’ve been quietly working on for months.

Back in June, a friend sent me a story from Virginia, an Italian creator talking about psychophysical well-being. She was looking for a cofounder for her mobile app.

She wrote me: “You would be perfect working together.”

I was already thinking about quitting my job and starting something on my own or in micro teams, so I sent her an email.

A few days later, we met for a coffee in Milan. She had already shipped the first version of Anapana, and it was doing well. But she needed someone who could take care of product, tech, and growth, and she was looking for a real cofounder.

And here’s the truth:
I didn’t say yes because of the idea.
I said yes because of the person.

We talked about mission, values, purpose… and we realized we were incredibly aligned. Just a couple of hours after that coffee, we both texted:
“I’m in.”

That’s when Anapana officially started for me.

We relaunched the app in August, and now we’re entering a phase I love the most: the deep product work.

We’re refining the product based on data and user behavior (retention loops, activation paths, content structure,…). You’ll hear more about this soon.

Revenue will remain private because this is a shared project, but I’ll share all the other important metrics.

If you’re curious to experience Anapana, you can download the app on your phone:

• Anapana Studio for iPhone

• Anapana Studio for Android

Take the 7-day trial and see how the practice feels for you… and please send me any feedback you have, it helps us a lot.

Metrics Snapshot

• BabyTales: €19.90 (–60%). Printing issues hit hard.

• HeyBloom: €0. Still in private “Marco-only” beta.

• Anapana: 21,100 registered users 🤓

One Million Goal (Revenue to Date): €220,069.80

Revenue on new projects didn’t grow this month, but my understanding of what I’m building did.

One Million Goal passed 394 subscribers this month (+74 in November, +23%).

Here’s the breakdown:

• LinkedIn posts: +29

• Substack recs: +28

• Daily notes: +10

• Google SEO: +5

• Claude: +1

• Instagram: +1

• Twitter: +0 (even with 2–3 tweets/day… the algorithm said “nope”)

So far, the winners are LinkedIn, Substack and daily notes. Now I just need to fine-tune the daily notes format until it feels natural and consistent.

Reflections

Conversations that changed the month

November gave me something I hadn’t felt in years: the mental space to listen again.

I found myself having long, meaningful conversations, the kind you normally postpone because life is too loud.

I talked with Matteo, a good friend from my Talent Garden days, about purpose and identity, and how social media gently pushes us toward versions of ourselves that don’t always match who we really want to be.

I talked with Carlo, whom I met at CES years ago, about how meditation changed him on a deeper level, and why he decided to build a consistent practice. His story landed exactly at the right moment.

Then there was Fabio, who made me rethink what it really means to be an indie hacker. We spoke about micro-teams, about working on multiple things at once, and why that’s not a flaw but a feature.

And in Turin, during the event, something unexpected happened: I went there to talk about AI, but instead people ended up asking me about courage, agency, and why someone would choose the solopreneur path. Their curiosity made me reflect more than they probably realized.

All these conversations had a common effect: they helped me see how much of the world I hadn’t been listening to.

When you’re a C-level, your world becomes narrow: colleagues, meetings, decisions, 1:1, product reviews, strategy,... It’s a beautiful bubble, but still a bubble.

November broke that.

What I’ve Been Reading

I didn’t read much this month. November was more about talking, thinking, and studying. But I revisited two books that hit differently this time.

Peak, secrets from the new science of expertise - Anders Ericsson

I went back to it because I used one of the studies during the live-build in Turin. Still one of the best books for understanding how skills are actually formed.

The Surrender Experiment - Michael Singer

A friend recommended it. Singer’s story about letting life unfold instead of forcing everything… I’m halfway through. More thoughts next month.

Elena Verna Meetup by Learnn

I also listened to a meetup with Elena Verna, organized by Learnn and it was one of the best crash courses in modern growth I’ve heard in a while. Luca Mastella shared a great recap, and here are a few highlights that stayed with me:

• In AI, you need to rediscover product-market fit every 2–3 months. User expectations evolve faster than your roadmap.

• Time to value is collapsing: from 20 minutes → to 30 seconds. If users don’t feel a “wow moment” instantly, they’re gone.

• Distribution > building. If you don’t design distribution into the product on day zero, you might never see traction.

• Build in public is becoming essential. People buy the team, not just the product.

• Shipping speed is the new moat.

• Vibe coding is now an actual job role at Lovable (!!).

• The rise of “Mom & Pop SaaS”: you don’t need to build a unicorn; a small, profitable SaaS can be a great life.

• Freemium in AI = marketing budget, not expense.

• And this one hit me hard: context switching is a competitive advantage in fast-evolving environments… not a flaw.

Honestly… listening to her felt like she was describing exactly what solopreneurs and indie hackers are already practicing every day, for years.

Distribution, build in public, shipping fast, vibe coding, small profitable SaaS, context switching… these aren’t just trends. They’re the toolkit of our generation of builders.

What’s Next

• This Wednesday, I’ll be interviewed by Marco Imperato on the Product Heroes podcast (🇮🇹) .

• Keep working on Anapana: growth, retention, and activation.

• Fix the Babytales printing provider situation.

• Share more about my product approach for Anapana.

• Keep experimenting: this is still the beginning of the OMG journey.

Closing Thoughts

November made one thing very clear: the part of me that’s growing is not the one sitting in meetings, writing strategic plans, or running 1:1s.

It’s the part of me that wants to build again. To get my hands dirty. To learn by shipping, not just by thinking.

During my talk in Turin, I shared this slide… and it still captures exactly how I feel right now:

“It was obvious that the part of me that was growing wasn’t the one in the trenches of strategies, 1:1s, and product reviews… but the part that wanted to get my hands dirty again.

I knew that only by doing that I could build new skills, and:
– if it goes well → it will bring me closer to the One Million Goal
– if it goes badly → I’ll become a better CPTO

In both cases… I win.

That’s the mindset I’m taking into December: stay curious, stay brave, keep building.

See you in the next update 👋

Marco

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,049 / €1,000,000

Subscribe now

Every product lives in a market… even when its founder pretends it doesn’t.
And the market, at its core, only asks two questions:

1. Are you better?

2. Are you cheaper?

Everything else is noise.
Everything else is storytelling.

For solopreneurs like us, this is even more true. We often build fast, ship faster, and hope that traction will magically follow. But no matter how much we hustle, how many nights we spend tweaking the UI, or how many features we stack on top of each other, one thing is certain:

If you don’t know where your product sits on the map, you’re building blind.

That’s why I want to revisit one of the simplest, yet most powerful, frameworks for understanding how products grow: the Growth Strategy Matrix, created by Tony Ulwick.

This matrix helps you answer a fundamental question:

Given the job your customers are trying to get done, and the cost they’re currently paying to get it done, which strategy gives your product the highest chance of success?

Before we dive in, a quick note.

A while ago I wrote an article about Jobs To Be Done, the idea that people don’t buy products, they “hire” products to help them make progress. If you want a refresher, you can read it here → Observe.

For now, let’s jump straight into the matrix.

What the Growth Strategy Matrix Really Shows

The Growth Strategy Matrix is built on two variables:

1. How well a product helps customers complete their Job To Be Done (better or worse).

2. How much it costs compared to current solutions (more expensive or cheaper).

From these, four quadrants (plus a “limbo”) emerge:

• Better & More Expensive

• Better & Cheaper

• Worse & Cheaper

• Worse & More Expensive

• Same price / same quality (the limbo zone)

Each of these leads to a specific strategy.

Here’s the visual layout:

The Differentiated Strategy

Better & More Expensive

This strategy targets customers who are underserved: people who are currently using a solution that doesn’t fully meet their needs. They want something better, and they’re willing to pay more.

Typical pattern:

• Enter a market dominated by established companies

• Deliver something dramatically superior

• Charge a premium

• Capture profit rather than market share

Think of:

• Nespresso: premium coffee experience

• Nest: a thermostat seven times more expensive than the market average

• Dyson: vacuum cleaners priced like luxury goods

• Tesla: early Roadster days, ultra-premium EV

Nest is one of the clearest examples.

They entered a boring, saturated market… and blew it open by making a thermostat intelligent, beautiful, and desirable. Their product was €250 when the market averaged €35, but they owned around 25% of profits with less than 10% of the market.

Differentiation is profitable, but it’s hard.

You must:

• deliver true, perceived superiority

• find a niche that deeply cares

• justify a high price

👉 For solopreneurs?

This quadrant is possible, but demanding. It works if:
- you’re serving a high-value niche
- your users have urgent unmet needs
- you can deliver 10x performance through design or tech

But in most cases, solo builders don’t start here.

The Dominant Strategy

Better & Cheaper

This is the holy grail.

You outperform the competition and cost less. When this happens, the old guard usually can’t defend itself.

• Netflix vs Blockbuster

• Uber vs taxis

• Google Search vs everything before it

• Shopify vs custom-built ecommerce platforms

Netflix is the perfect example. Before streaming:

• you rented DVDs,

• paid per movie,

• or subscribed to expensive cable bundles.

Then suddenly: unlimited content → €7.99/month and way more convenience.

Data suggests that to win with a dominant strategy, a product must:

• improve customer outcomes by at least 20%

• reduce price by at least 20%

This is brutal for established companies: they can’t drop prices without destroying their margins.

👉 For solopreneurs?

This strategy is appealing… but also the hardest. Competing as “better & cheaper” usually requires:
- serious automation
- economies of scale
- strong brand trust
- or infrastructure-level innovation

Still, it’s the dream quadrant. When companies get here, they win markets.

The Disruptive Strategy

Worse & Cheaper

This strategy targets:

• overserved customers: people using overkill solutions

• nonconsumers: people priced out of the market completely

This is where many startups originate.

You build something that helps people do the job, even if it’s not as powerful — because they don’t need all the power.

Examples:

• Canva vs Photoshop

• Google Docs vs Microsoft Word

• Duolingo vs expensive language schools

• Coursera vs universities

• Fiscozen (Italy) vs traditional accountants

If you compare Canva to Photoshop, Canva loses. Badly. But Canva wasn’t trying to win that fight.

It targeted:

• people who needed simple graphics

• people who found Photoshop overwhelming

• people who couldn’t afford Adobe’s pricing

And it grew into a giant.

There’s also a process here:
Start at the bottom → serve simple use cases → improve over time → eventually threaten the established companies.

This is Clayton Christensen’s classic “disruption curve”.

👉 For solopreneurs?

This is the most accessible quadrant.You don’t need to beat the market — you need to serve people who are currently ignored.

This is where most indie hackers win.

The Discrete Strategy

Worse & More Expensive

This sounds insane, but it happens whenever the customer is trapped, when alternatives are limited or unavailable.

Examples:

• Motorway service station (in Italy are called Autogrill)

• Airport shops

• Stadium bars

• ATMs in remote areas

You pay €4 for a bottle of water not because it’s good, but because you have no choice.

This is not where you want to build your product… unless you’re in a genuinely constrained market (rare for SaaS).

👉 For solopreneurs?

Avoid this entirely. Your users always have alternatives. Always.

The Sustaining Strategy

Slightly better or slightly cheaper

This is the middle zone, the limbo.

Your product is similar to existing solutions, maybe 5% better or cheaper.

This strategy:

• works for established companies

• kills new entrants

Why? Because customers rarely switch for tiny improvements. Changing tools costs more, emotionally and practically, than the 5% gain you’re offering.

👉 For solopreneurs?

If you’re launching something new: Avoid sustaining improvements. No one will care.

If you’re an established player, it helps you maintain position… but it’s not a growth engine.

How to Actually Use the Matrix

You can’t choose a strategy without understanding your customers’ JTBD and whether they’re:

• underserved → want much better, willing to pay

• overserved → want simpler and cheaper

• nonconsumers → can’t afford the current solution

• stuck → can’t switch easily

• satisfied → don’t want change

Some examples:

• If customers are overserved, a Differentiated Strategy will fail: you’ll build something more complex and expensive for people who actually want the opposite.

• If customers are underserved, a Disruptive Strategy will fail: no one wants “worse and cheaper” when they are begging for “better”.

Everything depends on what progress they want to make.

Putting the Strategies Into Motion

Differentiated Strategy: When to Use It

Works when:

• customers are extremely underserved

• you can deliver a truly superior solution

• you can justify a premium price

Apple used it with the first iPhone. The industry laughed (“$500 for a phone???” - Steve Ballmer)… but the device was radically better.

Once Apple scaled, they moved toward the dominant quadrant with products like the iPhone SE.

Differentiation → then expansion.

Disruptive Strategy: When to Use It

Perfect when:

• the market is over-engineered

• customers are overwhelmed

• pricing excludes many people

The disruption process:

1. Enter with something simple, inferior, cheap

2. Serve ignored users

3. Improve the product

4. Move upward

5. Replace established companies

Most solopreneurs thrive here. It’s the most realistic path from zero.

Dominant Strategy: When to Use It

Hardest to pull off.

To win:

• +20% performance

• –20% price

• exceptional distribution

Startups dream of this. Big players fear it. But it’s rarely the first move for a solo builder.

Discrete Strategy: When to Use It

Use only when:

• the context literally blocks alternatives

• switching is impossible

• urgency is extreme

In software, this is nearly never the case.

Sustaining Strategy: When to Use It

Works for:

• established companies defending market share

• products already adopted

• brands with loyal customer bases

If you’re launching a new SaaS:

Don’t build a sustaining product. No one needs a 5% improvement from a stranger.

So… Which Strategy Should Solopreneurs Choose?

Let’s end with two builders you know well: Marc Lou and Pieter Levels.

Their stories demonstrate how solopreneurs naturally fit into specific quadrants.

Marc Lou

Marc Lou is a great example of how solopreneurs naturally start in the disruptive quadrant, not by outbuilding big competitors, but by serving ignored segments with simple, fast, and emotionally resonant products.

Between 2022 and 2025, Marc built dozens of products. Many failed, but each one taught him something and helped him identify overserved or overpriced markets.

Some of his early experiments included:

• Mood2Movie – viral movie recommendations based on mood

• Habits Garden – a gamified habit tracker (~$500/month)

• Books Calculator – a simple reading progress tool that went viral

• Decision Game – a small web game to help people stop overthinking

None of these were “better than the established companies”. They were simpler, cheaper, and good enough — classic disruptive strategy.

His breakthroughs came when he doubled down on this approach:

• ShipFast – a fully packaged starter kit for developers, born from his own repeated pain building infrastructure

• CodeFast – an AI-powered coding course for founders who want to build SaaS in 14 days

• DataFast – a real-time traffic globe that turned analytics into a game

• TrustMRR, IndiePage, BioAge, ZenVoice, and more — all small but highly focused tools

Marc didn’t create the “best” design platform or the “best” analytics tool.
He created tools for people who felt the alternatives were:

• too complex

• too expensive

• or simply not built for them

This is disruption in its purest indie-hacker form.

Pieter Levels

Pieter is the king of starting simple.

Nomad List began as a spreadsheet.
RemoteOK was a job board with a basic UI.

Levels doesn’t try to be better than giants. He tries to be faster, simpler, and accessible.

Again: Disruptive Strategy.

His playbook:

• identify an underserved or ignored niche

• build a focused product fast

• price transparently

• improve based on usage

• compound over years

He never tries to win the “dominant” quadrant from day one. He enters through the side door.

The Solopreneur’s Takeaway

Most solo builders won’t start with:

• Differentiated (too expensive and complex)

• Dominant (too demanding in cost + performance)

• Discrete (almost never applicable)

• Sustaining (not attractive enough)

The realistic quadrant (the one where your unfair advantage is speed, simplicity, and focus) is:

The Disruptive Strategy

Serve people who don’t need everything.
Serve people who can’t afford the alternatives.
Serve people who are ignored.

Build fast.
Start simple.
Grow upward.

That’s the solopreneur path.

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,049 / €1,000,000

Subscribe now

For the past few months, I’ve been chasing ideas.

Every day, I’d wake up thinking, “this could be the one.” A small spark, a half-written prompt, a few lines of code, and off I’d go, building something new.
But deep down, I knew I was just trying to fill the silence.

As a product person, I’ve always preached one thing: observe before you build. Understand the people, their problems, their tiny frustrations that quietly ask to be solved.

But now, as a solopreneur sitting alone in front of my screen, I’d somehow forgotten my own advice. The pressure of not having “the idea” was loud enough to drown everything else.

So I wrote code. I built prototypes.

I convinced myself that progress meant pushing commits. But the truth is, I wasn’t building for anyone. I was just building to escape the discomfort of not knowing what to build.

A few weeks ago, I decided to stop.

No more code. No new projects. Just me, a notebook, and the world outside my window. I started observing again — people, conversations, patterns.
And something shifted.

When I was feeling stuck, one former manager, Alessandro, once told me:

“When you don’t know where to go next, restart from the foundations.”

When you slow down enough to see, you start to notice how many problems are silently waiting for someone to care. Some are small annoyances nobody has fixed yet. Others are completely new, born from the confusion and friction that AI has brought into our lives.

Now I’m not hunting ideas anymore.

I’m studying the world like I used to — not to copy it, but to understand it.

The milkshake lesson

A few days ago, I was watching a keynote by Clayton Christensen — entrepreneur, professor at Harvard Business School, and one of those rare thinkers who can make you see the obvious in a completely new way.

He was telling the story of how McDonald’s tried to improve the sales of their milkshakes.

At first, they did what any company would do: segment the market, run surveys, ask people what they wanted. “More chocolate? Less sugar? A bigger size?”

They gathered tons of feedback, iterated endlessly, and nothing changed. Sales stayed flat. So McDonald’s brought in Christensen’s team, who decided to do something radically different.

Instead of asking people what they wanted, they decided to observe.

They spent 18 hours sitting in a restaurant, simply watching. Who bought milkshakes? At what time? Alone or in groups? With food or on their own? Did they stay or take it to go?

They noticed something strange. Half of the milkshakes were sold early in the morning — to people who were alone, wearing office clothes, ordering nothing else, and leaving right after.

The next day, the team started asking them:

“Can you tell me what job you’re hiring this milkshake to do for you?”

People looked confused, so they rephrased it:

“When you’re in the same situation but don’t buy a milkshake, what do you do instead?”

And that’s when the pattern emerged.

These people all had long, boring commutes.
They weren’t hungry yet, but knew they would be later.
They wanted something to keep them occupied, something that would last for a while, something easy to consume with one hand while driving.

Bananas? Gone in two minutes.
Bagels? Dry, messy, and dangerous while driving.
Donuts? Sticky fingers, sticky steering wheel.
Chocolate bars? Guilt.

The milkshake was perfect: thick enough to last the whole ride, clean, and satisfying.

That’s when they realised the milkshake wasn’t competing with other milkshakes. It was competing with bananas, with bagels, with boredom.

This insight changed everything.

McDonald’s stopped thinking about demographics and started thinking about jobs to be done — the real progress people were trying to make when they bought something.

When I heard that story, I smiled.

Because in a way, I’ve been that consultant — adding more “chocolate” to my milkshake, thinking it would make it better.

I used to sit at my desk, tweaking features, polishing UIs, trying to invent something people would love. But I wasn’t watching the world outside my screen.

Now, when I go for a walk or sit in a café, I try to look differently. I ask myself: What job are people trying to get done right now?

The woman juggling her laptop and her coffee in the morning.
The father scrolling on his phone while his kid waits for the bus.
The student switching between ten AI tools, trying to make sense of all the noise.

Each of them is doing something — hiring tools, habits, and hacks to make progress. And somewhere in there, hidden between gestures and frustrations, is the next idea worth building.

I don’t know what I’ll build next. But I know how I’ll find it. By observing, quietly and patiently, until the problem shows itself.

Because maybe that’s what being a builder really means:
Not to chase, but to see.

I build in public toward €1M, and you get to watch and steal everything I learn. You can read more about me and my project here.

Revenue to date: €220,049 / €1,000,000

Subscribe now

Picture this: You’re 28 years old, living in your parents’ basement in France, clinically depressed, and your last business venture made exactly $4 selling PDFs about male bladder control through ads on adult websites.

Most people would call this rock bottom. Marc Lou called it Tuesday.

Today, Marc generates $125,000+ monthly from a portfolio of digital products he builds alone from his hammock in Bali. He surfs every morning, documents every business decision publicly, and has turned transparency into his most profitable competitive advantage.

But here’s what makes Marc’s story different from every other rags-to-riches entrepreneurial fairy tale: he documented the entire journey in excruciating detail. Every failure. Every breakdown. Every pivot. The actual numbers, not the sanitized highlights.

His story isn’t about luck. It’s about iteration, identity, and the courage to keep shipping.

The Education of a Serial Failure (2016-2021)

Marc Lou’s entrepreneurial education cost him five years and nearly his sanity. The curriculum? Learning what doesn’t work.

Chapter 1: The Zuckerberg Delusion (2016-2017)

Fresh out of computer science school, Marc watched “The Social Network” during a hungover Sunday morning and experienced what he now calls “the most expensive epiphany of my life.” He decided he was the next Mark Zuckerberg.

His billion-dollar idea? Tinder for sports lovers.

For an entire year, Marc lived with his parents, worked as a waiter for $10/hour, and built an app that... never worked. Users couldn’t even sign up. He was literally the only user of his own product. The app was so broken that after 365 days of development, he threw away all the code in 24 hours.

💡 The lesson: Ideas are worthless without execution, and execution is worthless without market validation.

Chapter 2: The Seoul Mirage (2017-2018)

Determined to prove himself, Marc moved to Seoul with a friend who promised to raise $100,000 from VCs for an AI startup. They did raise the money. They built a product. They found zero customers.

After nine months, the company shut down with nothing to show for it. Marc hit rock bottom so hard he started smoking again.

💡 The lesson: Great products without customers are just expensive hobbies.

Chapter 3: The Korean Glove Fiasco (2018)

Broke and desperate, Marc saw a Facebook ad for couple gloves—mittens that let couples hold hands together. Genius, he thought. He partnered with a Korean grandmother who knitted 50 gloves. The Facebook ads failed. They ended up selling gloves in the street during Seoul’s freezing winter, getting drunk to stay warm.

They barely broke even.

But something clicked: Marc had made his first dollar online. It was proof the solo business model worked.

💡 The lesson: Revenue, even tiny revenue, validates more than any pitch deck.

Chapter 4: The First Real Success (2018-2020)

A marketer named Andre gave Marc advice that changed everything: “Sell it before you build it.”

Marc created GameWidget, a gamification tool for escape room businesses. Instead of building first, he sent cold emails describing the concept. During a 42-minute call with an Australian business owner, he made his first sale before writing a single line of code.

GameWidget grew to $4,000 monthly recurring revenue. Marc moved to Bali, learned to surf, and thought he’d finally made it.

Then COVID-19 hit. Escape rooms closed. Revenue went from $4,000 to $0 in 24 hours.

💡 The lesson: Even successful businesses can be fragile if they depend on a single industry.

Chapter 5: The Breakdown (2020-2021)

Back in France, living with his parents again, Marc spiraled into depression. One morning, while making coffee, he started crying for no reason. Later, he punched holes in his bedroom wall four times before his parents intervened.

He took a job with influencer Tai Lopez making $9,000/month—more money than he’d ever seen. For the first time in years, he had a sense of purpose and structured time off. He started reading books, working out, and prioritizing sleep.

Then Tai Lopez fired him.

💡 The lesson: Rock bottom can be a foundation if you use it to rebuild your fundamentals.

The Build-in-Public Revolution (2021-2025)

That’s when Marc discovered something unexpected: success isn’t built in silence. It’s built in public.

Marc’s breakthrough came from discovering a tweet by Pieter Levels about building startups in public. This transparency-first approach would become his secret weapon.

The New Rules (December 2021)

With $20,000 in savings and a Korean wife who believed in him, Marc returned to Bali with five non-negotiable rules:

1. Prioritize sleep no matter what

2. Share everything transparently on Twitter

3. Ship the smallest possible version of every idea

4. Always launch and market aggressively

5. Focus on process goals, not outcome goals

The Rapid Launch Phase (2022)

Marc built 20+ products in 12 months. Most failed, but each taught him something:

• Mood2Movie: Movie recommendations based on mood (viral on Reddit)

• Habits Garden: Gamified habit tracker ($500/month MRR)

• Books Calculator: Reading progress tool (went viral)

• Naval 25: Collection of Naval Ravikant quotes

• Decision Game: Web game to stop overthinking

The strategy wasn’t to hit home runs—it was to get at bat repeatedly and learn from each swing.

Revenue Growth Timeline:

• 2021: $0 (living with parents)

• 2022: ~$2,000/month (experiments)

• 2023: $263,000 total revenue (breakout year)

• 2024: $50K-100K+ monthly

• 2025: $125,000+ monthly with 92% profit margins

The Breakthrough Products

ShipFast: The Accidental Goldmine

By mid-2023, Marc realized he was rebuilding the same infrastructure for every project: authentication, payments, database setup, email integration. He spent a week consolidating this into a reusable codebase.

Then he had an idea: What if other developers would pay for this?

He packaged his internal boilerplate into ShipFast—a Next.js starter kit that lets developers “ship your startup in days, not weeks.” Launch price: $199.

The results were immediate:

• First 48 hours: $6,000

• First month: $40,000

• Peak monthly revenue: $65,000

• Total revenue by 2024: $300,000+

• Customers: 7,680 developers and counting

CodeFast: Teaching What He Learned

In 2024, Marc launched CodeFast, an AI-powered coding course teaching entrepreneurs to build SaaS products in 14 days. Unlike typical programming courses aimed at job-seekers, CodeFast targeted people who wanted to quit their 9-5 jobs.

Peak performance:

• November 2024: $88,500 revenue

• January 2025: $82,600 revenue

• Launch weekend: $92,000 in 48 hours

DataFast: Turning Analytics Into a Show

While most analytics dashboards feel like spreadsheets in disguise, Marc wanted something fun—something people would actually want to share. So he built DataFast, a real-time analytics platform that visualizes website traffic on a glowing 3D globe.

It started as a weekend experiment to track visitors on his own sites, but the visuals went viral on X. Indie hackers began posting their live traffic globes, tagging Marc for credit. Within weeks, what began as an internal side tool became a $15K/month product.

The magic wasn’t in the data—it was in the emotion. By turning analytics into a game, DataFast made growth feel exciting again.

• January 2025: $1,400

• October 2025: $16,500

The Supporting Portfolio

Marc’s ecosystem includes:

• TrustMRR: The database of verified startup revenues (~$12,000/month)

• IndiePage: Portfolio builder for indie hackers ($700/month)

• BioAge: Your biohacker dashboard (~$600/month)

• ZenVoice: Stripe invoicing tool ($300/month)

• LaunchViral: Course on creating viral launch videos ($200/month)

• ByeDispute: Payment dispute prevention (~$100/month)

The Method Behind the Madness

Philosophy: Speed as Strategy

Marc’s entire approach centers on velocity over perfection. His mantras:

“Building a successful startup is a repetition of tiny failures.” “Ship the 24-hour version of your idea.” “Every startup has a weekend version—find it.”

This philosophy emerged from painful experience. His early failures came from spending months perfecting products nobody wanted. Now he ships within days and iterates based on real user feedback.

Tech Stack: Boring and Profitable

Marc deliberately uses a simple, repeatable tech stack:

• Frontend: Next.js + React + TypeScript

• Backend: Node.js + MongoDB

• Payments: Stripe or LemonSqueezy

• UI: Tailwind CSS (core utilities only)

• Hosting: Vercel

• AI Tools: GPT-4, Cursor AI for coding assistance

The philosophy: Use proven technologies, avoid shiny objects, focus on shipping products rather than learning new frameworks.

Marketing: Transparency as Competitive Advantage

Marc’s marketing playbook breaks every traditional rule:

🎯 Radical Transparency: Monthly revenue reports with actual screenshots. Sharing failures alongside successes. Livestreaming product development in real-time.

🎬 Viral Content Strategy: Marc creates hilarious demo videos where he deepfakes himself into movie scenes. His ByeDispute launch video featuring him as Leonardo DiCaprio’s sidekick in Wolf of Wall Street went viral and drove significant sales.

👥 Community-First Approach: Rather than interruption marketing, Marc builds relationships. He has 215,000+ Twitter followers who literally watch him work. When he launches something, thousands of potential customers are already invested in his journey.

🔄 Cross-Pollination: Every product footer links to his other products. Customers who buy ShipFast discover CodeFast, ZenVoice, and IndiePage. This ecosystem approach maximizes customer lifetime value.

📺 Content as Product: Marc’s YouTube channel (133K+ subscribers) and newsletter (42K+ subscribers) aren’t just marketing—they’re products that drive revenue directly while building audience for everything else.

The Numbers Game: Revenue Breakdown

💰 October 2025 Monthly Revenue: $65,700

• CodeFast: $21,300

• ShipFast: $17,400

• DataFast: $16,500

• TrustMRR: $8,600

• Other Products: $1,856

🚀 Business Model Innovation:

• One-time purchases instead of subscriptions (reduces churn anxiety)

• “Popcorn Pricing” psychological pricing that feels like an impulse buy

• No refund policy (increases commitment, reduces support overhead)

• 92% profit margins due to digital-only products and solo operation

⚙️ Operational Efficiency:

• Zero employees

• ~$4,000/month in business expenses

• Fully remote, location-independent

• Automated systems handle most routine tasks

The Psychology of Success

Failure as Education

Marc reframes failure as tuition payments in the university of entrepreneurship. Each failed project taught specific lessons:

• Tinder for sports lovers: Ideas need market validation

• Seoul AI startup: Products need customers, not just investors

• GameWidget: Single-industry dependence is risky

Process Over Outcomes

Instead of “lose 10 pounds,” Marc sets “work out every day.” Instead of “make $10K this month,” he focuses on “ship one product every month.” This shift removes anxiety about results he can’t directly control and creates momentum through consistency.

Identity-Based Habits

Marc doesn’t just build products—he’s built an identity as someone who ships fast and shares transparently. This identity becomes self-reinforcing. When faced with decisions, he asks: “What would someone who ships fast do?”

Why Marc Lou Matters for OMG

Marc Lou represents the archetype that One Million Goal aims to showcase and multiply. Here’s why his approach matters:

✅ Proof of Concept: He demonstrates that one person can build a million-dollar business using modern tools and transparent practices. No venture capital, no team, no traditional business model required.

📚 Replicable Methodology: Unlike many entrepreneurial success stories that rely on unique circumstances or hidden advantages, Marc’s approach is systematically documented and teachable.

📈 Real Numbers, Real Process: In an industry full of guru mythology and vague success stories, Marc provides actual revenue screenshots, detailed explanations of his methods, and honest assessments of what worked versus what failed.

🔄 Modern Business Model: Marc has created what amounts to a one-person media company that happens to sell software. His personal brand, educational content, and product portfolio work synergistically to create multiple revenue streams and competitive moats.

🤝 Community Over Competition: Rather than hoarding knowledge, Marc actively shares everything he learns. This abundance mindset creates network effects that benefit everyone in the ecosystem.

🌴 Sustainable Lifestyle: Marc has achieved what most entrepreneurs claim to want: complete creative and financial freedom, location independence, and work that energizes rather than drains him.

The Marc Lou Blueprint

For OMG members, Marc’s journey provides both inspiration and instruction manual:

📍 Phase 1: Foundation Building (Months 1-6)

• Choose a simple, proven tech stack

• Start building in public immediately

• Launch small experiments monthly

• Focus on learning, not earning

🎯 Phase 2: Audience Development (Months 6-18)

• Share transparently on social media

• Document your process, not just results

• Solve your own problems first

• Build relationships before pitches

🚀 Phase 3: Product-Market Fit (Months 18-36)

• Test multiple products with your audience

• Double down on what works

• Kill what doesn’t work quickly

• Reinvest profits into growth

💼 Phase 4: Portfolio Expansion (Year 3+)

• Create ecosystem of complementary products

• Cross-promote within your portfolio

• Build recurring revenue streams

• Scale through systems, not staff

Marc Lou cracked a code that many entrepreneurs miss: in the attention economy, transparency is the ultimate differentiator.

While others obsess over stealth mode and competitive advantages, Marc builds his moat through radical openness. His customers know exactly how much money he makes, which products are struggling, and what he’s working on next. This vulnerability creates trust, and trust creates sales.

His technical approach—boring stack, fast shipping, solve your own problems—isn’t revolutionary. His marketing approach—build audience first, share everything, create helpful content—isn’t new either.

But combining transparent personal branding with rapid product iteration while building for a specific community? That’s the alchemy that turns a depressed waiter into a millionaire solopreneur.

Marc didn’t just build startups — he built a new archetype for the solo age.