Hyper Reality: five million pesos in ninety days. ₱5M in /90 days

I'm planning to run a 90-day experiment where the goal is to try and generate ₱5,000,000 (85K USD), and I'm going to be documenting the thinking publicly as I go.

Straight away, a couple of caveats. This is not advice. This is not me saying everyone should try this. And this is definitely not me saying it's easy, or even that it's going to work.

It's just a way of forcing clarity.

When goals are vague, like "I want to make more money" or "I want to build something meaningful," it's very easy to avoid the hard questions. But the moment you put a specific number and a specific timeline on the table, you're forced to actually think.

That's really what this is about.

If you strip business right back to its simplest form, revenue really just comes down to two variables: how many people are buying something, and how much they're paying for it. That's it. There's obviously loads of complexity layered on top, but at the core, it's just people times price.

So once you say, "Okay, the target is ₱5,000,000 in 90 days," you can start playing around with the combinations. You could sell something very expensive to a small number of people, or something much cheaper to a lot of people, or something in between. On paper, all of those look equally valid.

But in practice, they really, really aren't.

One of the biggest mistakes I see beginners make, and this is something I definitely believed early on as well, is assuming that cheaper things are easier to sell. We all buy cheap stuff all the time. Coffee, books, apps, subscriptions. So it feels intuitive that selling a lot of low-priced things should be easier than selling a few high-priced things.

But what you quickly realize when you actually try to do it is that volume is brutally hard.

The moment your plan depends on hundreds or thousands of people saying yes, everything gets more complicated. You need distribution. You need attention. You need systems to handle support, payments, onboarding, questions, and all the unusual situations you didn't plan for. All of that complexity compounds really fast, especially in a short time frame.

By contrast, selling something more expensive to fewer people often turns out to be simpler, even though it feels scarier at first. Fewer conversations. Fewer variables. More focus on actually solving a real problem for a specific person.

This is where pricing becomes interesting. Price isn't really about worth or confidence or trying to be fancy. It's more like a filter. Higher prices tend to attract people who have a clear problem, a clear budget, and a willingness to decide. Lower prices tend to attract more people, but also more hesitation, more noise, and more operational load.

Neither is inherently good or bad. But you really need to be honest about what kind of complexity you're signing up for.

Another big piece of this is the focus on services rather than products, at least at the start. Products are great, and obviously very scalable, but they usually require either a big audience, a lot of capital, or a long runway. Services, especially done-for-you services, give you much faster feedback from reality.

When you offer a service, you're essentially saying, "I'm responsible for the outcome." And that responsibility forces learning very quickly. You find out what actually works, what people actually care about, and what they're actually willing to pay for.

In a short experiment like this, learning speed matters way more than elegance or scalability.

Something else becomes obvious once you think about it carefully: people are much more willing to pay meaningful amounts of money for problems that are concrete and measurable. Saving time, making money, reducing costs, removing operational headaches. These problems aren't always exciting, but they're easy to explain and easy to justify.

More abstract outcomes, like mindset, confidence, fulfillment, can absolutely be valuable, but they're much harder to price at higher levels unless they're clearly tied to something tangible the person already cares about.

I also want to be really clear about what this whole thing actually is. This is not execution. I'm not claiming that talking about this magically makes it happen. This is more like a firmware update. A way of upgrading how I'm thinking about trade-offs, constraints, and reality before getting lost in tactics.

A lot of people don't fail because they're lazy or incapable. They fail because they choose a game where the odds are stacked against them from the start, and then they blame themselves when it doesn't work out.

Before you start playing any kind of game, business, money, creativity, you need to be clear about the one you're actually stepping into. Different games come with different expectations. Pick the wrong one, and working harder doesn't necessarily help.

So in a way, this whole experiment is just me trying to choose the game before I start playing it.

If the goal is ₱5M in 90 days, volume-based ideas are out. High-ticket services are the only path that holds up mathematically, especially the ones tied to clear, measurable outcomes.

Over the next 90 days, I'm not going to prove that this works. The goal is to see what reality says when you stop hiding from the numbers.

The math narrowed the direction. High-ticket services tied to measurable outcomes were the only model that made sense. Everything else needed more time, more attention, or more luck than I'm comfortable assuming upfront.

That part felt relatively clear.

What wasn't clear is what measurable really means in practice. It's a word that sounds obvious until you try to apply it to a real decision.

When people talk about business ideas, especially online, they describe outcomes using words like impact, transformation, confidence, clarity, fulfillment. I don't think those things are fake or unimportant. They clearly matter to people.

But those kinds of outcomes are quite hard to price on their own.

People seem much more willing to pay meaningful amounts of money when the problem already shows up somewhere concrete in their life. Something that affects their calendar, their inbox, their revenue, or their costs.

So I'm using a narrower definition than I normally might. When I say measurable, I'm talking about problems a person or a business already tracks, budgets for, or worries about regularly. Things that come up in meetings or spreadsheets without anyone having to translate them.

That usually means revenue, costs, time, delays, errors, or operational friction. Not the most exciting problems to talk about, but very easy to understand. And people don't feel awkward spending money to make those problems smaller.

This is also where I've been rethinking the usual advice around passion.

I don't think "follow your passion" is bad advice. I just think it's often misunderstood, especially early on. A lot of people treat passion as something you're supposed to start with, like a compass that tells you which direction to go in. But in my experience, passion tends to show up after you've found something that works, not before.

It's easy to feel excited about an idea when you're imagining it. It's much harder to stay engaged once you're dealing with real clients, real constraints, and the less glamorous parts of the work.

So I'm deliberately starting somewhere less romantic. Instead of asking what I feel most excited about, I'm asking what people are already paying to fix.

That doesn't mean passion doesn't matter. I'm treating it as something that tends to show up later. If something creates real value and fits my skills reasonably well, there's a good chance enjoyment follows over time.

Founder fit still matters here, just not in the aspirational sense. I'm not trying to reinvent myself or chase a new identity. I'm looking for areas where I already understand the mess better than average. Industries I've seen from the inside, problems I've personally dealt with, situations where I can have a serious conversation without feeling like I'm pretending.

That overlap, between measurable pain and earned familiarity, feels like the only place this experiment has a realistic chance of working.

So I'm deliberately not trying to build anything yet. No offer. No packaging. I'm really just trying to check whether the problem itself is solid enough to be worth spending real time on.

The way I'm doing that is fairly straightforward. I write a list of problems that businesses already pay to solve, and I describe them in really simple terms, basically how people talk about them when they're actually dealing with them.

Then I talk to a few people who deal with these problems day to day and ask a really simple question: roughly speaking, what does this cost you in a typical month? Money, time, mental load, whatever feels most obvious to them.

I'm not trying to steer the conversation or pitch anything. I'm mostly paying attention to how easy it is for them to answer.

If someone has to think for a long time, or keeps hedging, that's actually useful. It usually means the problem is real, but it's not something they've ever tried to put a number on. When people can answer quickly, even with a rough estimate, that's a very different signal.

For a high-ticket service to make sense in this window, "measurable" can't just mean "important." It has to mean something the client already recognizes as a cost. Something hitting their time, their money, or their operations in a way they can actually point to.

And if you can't point to it, it gets very hard to price it.

A definition is one thing. What people actually say when you ask them is another. So I stopped designing the idea alone and went looking for it in conversation.

The most useful progress started coming from conversations rather than isolated thinking. Once people knew what I was exploring, it felt natural to ask where work slows down, where things get repeated, or which parts of the business feel heavier than they probably should. There wasn't much resistance. People mostly talked about things they were already thinking about.

Around the same time, a few real projects came in. Clear timelines, reasonable deadlines, a straightforward exchange of time for money. The sort of work I'd usually say yes to without much hesitation. In some cases, I did.

But having the experiment running in the background changed how those decisions felt. It became obvious how easy it would be to just carry on as normal. The projects themselves were fine. The problem is that they fill the week in a way that makes the experiment feel optional. And the whole reason for putting a number and a time limit on this was to stop letting it stay optional.

So I started using a different filter.

Instead of asking whether something is a good project, I'm noticing whether it helps the experiment move forward, or whether it mostly just keeps me busy. Some work does the first. Some does the second. Both are fine, but they don't have the same effect.

The understanding hasn't come from sitting down and thinking harder. It's come from hearing the same themes surface across different conversations. Similar issues, described in slightly different ways, by people in different situations. The most useful conversations don't really feel like pitching. They feel like sharing what I'm exploring, asking a few questions, and listening carefully to what comes back.

I keep circling the same kinds of problems. Manual steps that probably shouldn't exist anymore. Systems that don't quite talk to each other. Small inefficiencies that add up over time. I'm not pushing in that direction on purpose. It just keeps showing up.

What's becoming harder to ignore is that this can't stay a solo effort for very long. If the next phase is about having more of these conversations and letting patterns emerge faster, then everything can't go through me. At some point, progress depends less on how much I can personally do, and more on how much surface area the experiment has.

"Tall hot Americano for Dover."

What I got was a tall burnt Americano. And yet, here I am again. Still not Dover.

The Starbucks is packed. Every table taken. There's even a line. Anyone familiar with the brand's history knows their real product isn't the coffee.

Which made me wonder what mine actually is.

This experiment, 90 days, ₱5M, has reached a point where I need to turn what I'm seeing into a clear offer. I ruled out volume. I spoke to around a hundred business owners and tested whether the pain was real. Some of those conversations turned into real, paid projects. They weren't enough to meaningfully move the ₱5M target, but they were enough to be distracting in a very specific way. Work that creates momentum and revenue without really moving the experiment forward.

At one point, someone asked me to put together a ₱5M proposal.

I froze.

That moment clarified the problem. The conversations are useful, and they do lead to opportunities. But if I'm going to make progress here, I need to get much clearer on what I'm actually offering, and I need to do that quickly.

And I can't figure that out on my own.

So I started scouting. That mostly meant paying closer attention to people I already trust. Clients, operators, business owners. The ones who live inside the problems I keep hearing about. Around the same time, I found someone curious enough to join the experiment. The plan was simple: keep talking to people while I slowly shape what this could become.

What I didn't expect was how much that would change my thinking.

When I work on my own, I tend to jump ahead. I hear about a broken process and my mind immediately starts sketching fixes. Tools, dashboards, automations. It feels efficient. It feels like progress. But it's also a shortcut. You end up solving things before you're fully sure what the problem actually is.

Having someone else in the room makes that harder to do. You notice when you're filling in gaps too quickly. You catch yourself smoothing over uncertainty instead of sitting with it. Conversations slow you down because you have to explain what you mean, properly, to another person.

I had to say my thoughts out loud, and that exposed how unfinished some of them still were. There were moments where I'd hear myself explain an idea and realize I didn't fully believe it yet.

Without anything to sell, conversations went places I didn't expect. People stopped summarizing and started describing. The pain showed up in small details. Handoffs that don't quite work, steps no one questions anymore, workarounds everyone actually resents.

One conversation even led to someone talking about a death in the family.

That doesn't usually happen when there's someone selling.

That's why I think of this as reconnaissance. Seeing the terrain clearly matters more than moving fast. I'm treating that as non-negotiable. Which is exactly the part I have to guard, because I enjoy building things. The technical work here is familiar. I know how to map processes. I know how to turn them into dashboards. I know how to automate the boring parts. I could easily slip into execution mode and stay busy for weeks.

But doing that too early would flatten the learning.

A branding workshop put a name on the trap. They ran an assessment on how you tend to work. Mine came back: Magician.

One part of the description stuck. It pointed out that this way of working can tempt me into rushing ahead or overbuilding before the problem is fully understood.

That felt accurate. It sent me back to the conversations with a bit more restraint.

I should also admit I'm biased here. I've spent a few years paying attention to how time gets used at work. At some point that curiosity turned into a small project of its own, mostly because I wanted to understand why simple things felt harder than they should. So when the same complaints kept coming up, work taking longer than expected, the same manual steps every week, checking multiple tools just to see if something had moved, following up because no one was quite sure who owned the next step, it was hard to ignore.

When I asked what that looked like in practice, people usually talked about time. Time spent checking. Time spent fixing small mistakes. Time spent chasing updates.

That's where the offer started to take shape. And I'm testing it now.

I've started working one-on-one with a business on a single workflow. One place where things slow down more than they should, or where a lot of checking and following up has become normal. I'm paying attention to whether making that one part of the work easier to see changes anything. Whether people spend less time checking. Whether fewer things get stuck. Whether the day feels a little lighter once that piece is clearer.

I'm keeping the scope small. If too many things change at once, it's hard to tell what actually made a difference.

I also shared my pitch at one point.

Someone yawned.

That was useful feedback. It's why I've stopped keeping all of this in private conversations. One-on-one is comfortable, but it makes it easy to keep adjusting the idea without really committing to it. So I'm starting to share this more openly. What I'm noticing, what I'm trying, what seems to help and what doesn't.

Bringing other people into this hasn't sped things up. If anything, it's slowed me down just enough to see what's already in motion. Which problems repeat. Which frictions refuse to disappear. Which conversations deepen even when there's no promise of a solution at the end.

Left on my own, I default to momentum. Fixing things. Shipping things. Progress that looks good from the outside.

Working with others changes the beat. You pause more. You listen longer. You let the problem sit on the table before touching it.

Things still move. Just more deliberately.

It was Christmas, with family dinners and the usual end-of-year noise. Writing can sometimes feel like progress, even when the harder work hasn't been done yet.

At one of those dinners, my mother-in-law asked me if I could define reality.

It caught me off guard. It wasn't something I expected to be asked at the table, especially on Christmas. I answered, though I don't remember exactly what I said. Then she gave her own definition:

Reality is what has happened.

That definition stayed with me. This experiment has been running long enough that explanations matter less than what actually exists.

I've explored a lot of projects over the years. Some out of curiosity, some to learn by doing, and some because I haven't yet landed on something that compounds. The pattern is that I learn a lot early, but very little gets time to fully play out.

I don't have a dramatic success story yet. But I do have a growing understanding of why certain things didn't work. It's often better to understand why you failed than to stay ignorant of why you happened to succeed.

This feels like the point where that learning needs to turn into action. To stop adding context and start finishing something specific. To solve one real problem properly and have something concrete to show for it, rather than another well-reasoned explanation.

If I'm going to claim I can remove friction or recover value, then something observable has to change.

The numbers help clarify it.

In a business with around 20 to 30 people, losing even 30 minutes a day per person to rework, waiting, or unclear responsibility adds up faster than it sounds. That's roughly 10 to 15 hours a day, or about 200 to 300 hours a month.

At ₱700 to ₱1,000 per hour once salary and overhead are included, a single recurring inefficiency can cost ₱140,000 to ₱300,000 every month. Most businesses have more than one of these.

Seen that way, the idea of recovering or creating ₱5M in value stops feeling abstract. It's the result of fixing a small number of problems and not letting them slide again.

This is where the idea of a Grand Slam Offer starts to make more sense to me. Making an offer that's hard to refuse can sound aggressive on the surface. In practice, it removes pressure. You're no longer trying to convince someone. You're presenting something that's obviously useful and letting them decide.

That confidence comes from having done it enough times. From having tried things, gotten them wrong, adjusted, and seen what actually drives real progress.

Right now, I don't have a clean result to point to. No finished case, no clear before-and-after. Mostly conversations, encouragement, and "I'm rooting for you bro." I appreciate that, but I'm also aware that it isn't evidence.

That's uncomfortable to admit publicly. It's also accurate.

I reread $100M Offers and noticed the same thing again. The examples that worked didn't need much explanation. The result was obvious.

I've done enough circling. What's missing is actually finishing something and letting that speak for itself.

According to my mother-in-law, reality is what has happened. So the task now is to make sure that, when I look back at this, there's something real to point to.

I've spent a lot of time looking at what slows businesses down once they reach a certain size.

Different symptoms show up. Overworked founders, missed handoffs, slow decisions. But underneath many of them is the same issue: delegation.

This is why I started calling myself an Escape Artist. It's my shorthand for the work I'm trying to do now: helping founders get out of the way so their business can run without them.

Most founders already know delegation matters. They just don't think it's realistic.

A lot of business owners spend time building systems. They write SOPs, design workflows, document processes. But even with systems in place, many founders are still being pulled into everything. They delegated tasks, but still answered constant questions. They handed work off, but still fixed mistakes themselves. The business still depended on them.

Eventually, some concluded that delegation just wasn't possible for their business.

In most cases, the issue wasn't the team. The issue was that tasks were being delegated without clearly delegating the system those tasks belonged to. Delegation was happening reactively, often when the founder felt overwhelmed, instead of being done deliberately.

The founders who handle this well do it differently. They don't delegate randomly. They don't offload work just to feel less busy. And they don't assume their team will "figure it out."

Here's the structure I now use to make delegation actually work.

Step 1: Map the systems.

Instead of starting with tasks, start with systems. I usually break a business into four areas:

• Marketing: generating leads
• Sales: converting leads
• Operations: delivering the product or service
• Finance: protecting cash flow and profitability

Every task belongs somewhere inside one of these. Once tasks are organized this way, founders stop trying to keep the entire business in their head. The work becomes easier to see, and delegation becomes less abstract.

Step 2: Assign ownership.

For each system, ask a simple question: who owns this? Not who helps with it. Not who touches it occasionally. Who is accountable for the outcome.

Once this is clear, trade-offs become easier to see. Sometimes the founder is holding work that doesn't need them. Sometimes a team member is stretched thin. Sometimes the gap points to a hire. There isn't a perfect answer. The point is to make the situation visible enough to decide.

Step 3: Use the RAI method.

This is where delegation usually breaks. Work gets handed off without context. Responsibility exists, but there's no clear way to tell if things are going well. Nothing is connected to how people actually spend their time. So the work returns to the founder.

RAI helps prevent that.

Responsibility means explaining where the work fits and why it exists. It means owning the outcome, not just completing a task.

Accountability means each system has a small set of measures. The person responsible tracks them, and the team reviews them briefly each week. This removes guesswork and reduces the need to chase updates.

Integration means placing the responsibility into the calendar. Day, time, and frequency. If it isn't scheduled, it usually doesn't happen.

Step 4: Reduce the questions.

Many founders unintentionally train their team to depend on them. A few simple rules help change that: update SOPs whenever a new question comes up; use a 1–3–1 rule when problems are escalated; set specific times for questions instead of responding immediately. Over time, fewer questions come through, and the system improves.

Step 5: Don't break the rules.

This is the hardest part. Every time a founder steps in too quickly, fixes something themselves, or bypasses the process, they reinforce the dependency they're trying to remove. The founders who succeed here are consistent. They let the system do its job.

When delegation works at the system level, many other issues become easier to handle. Work moves without constant checking. Decisions happen closer to where the information lives. Cash flow becomes easier to manage.

Most of the value shows up here.

And when a service reliably produces these outcomes, the pricing conversation changes. People stop asking whether it's cheap and start asking whether it works.

Clear value comes from solving a problem in a way that isn't easily swapped out. For many growing businesses, delegation sits at the center of that problem.

I was sitting on a monoblock chair, holding a warm beer, in a bar beside Shakey's in QC.

"So why are we doing this, again?" I asked my business partner.

"For the girls," he said, then laughed. "World domination."

I remember staring.

Is he serious?

"Cool," I said.

It was 2010-ish. About 500 years ago. I was young, trying to be an adult. Back then, asking why felt like the adult thing to do. That was the advice everywhere. Start with why. Purpose. Meaning. All that.

So yeah, thanks, Simon Sinek.

But if I'm being honest, no thanks.

I'm not anti-purpose. It just didn't help me decide what to actually do. I'd ask why, and the answers would keep expanding. You start with a reason, then you end up talking about impact, then values, then how you want to change lives. And suddenly everything feels important, but nothing concrete.

And when nothing is concrete, you don't make clean decisions. You're stuck. You don't know what to build first, who to spend time on, or what to ignore.

I didn't really understand that until much later, when I got involved in BNI.

BNI is all about referrals. One of their rules is closed classification. That means you have marketing exclusivity. If you're the button seller in a chapter, no other button sellers are allowed in.

At first, that rule feels great. It feels like protection. Then the chapter tries to grow and things get uncomfortable. People start guarding their classifications. They don't say it out loud, but you can feel it. "If someone like me joins, that's fewer referrals and less business for me."

Honestly, you can't really blame them. That fear makes sense.

Most chapters treat classification as a label. Once you're in, you stick with it. You repeat it every week. You assume clarity is handled.

Then referrals slow down. Not because people don't want to help you. Because they're unsure. They hear your name come up and hesitate. They're not sure if this situation really fits you. And because they're busy, they move on.

That hesitation adds up.

I saw a very different approach when I looked at how BNI India operates. They're bigger. More mature. And because of that, they get much more specific. You'll see chapters where there are multiple businesses that look similar on the surface. Same product. Same industry.

Different classifications of buttons in one chapter shouldn't work. It does, because they're not chasing the same buyer or the same problem.

One member designs buttons for factories that kept failing safety audits because labels were unclear or missing. Another supplies fashion trims for garment exporters dealing with rework and rejected shipments. Same product category. Very different failure.

Now when something comes up in conversation, no one has to think very hard. The situation points straight to the person. Once you see what actually fails in each situation, it stops feeling like competition.

Once I saw that, a lot of other things made sense to me, especially pricing.

Here's the same service, sold to different targets:

If you sell a time management course to people who feel busy, it gets treated like self-help. Helpful, sure. But optional.

If you sell it to salespeople, it starts to connect to follow-ups and activity and deals that are back-logged. If you sell it to owners doing outbound, now it's tied to pipeline and consistency. If you sell it to creative agency owners who rely on B2B sales, missed follow-ups don't stay theoretical for long. You see it in stalled growth, then in cash flow.

The work is mostly the same. What changes is how expensive it gets when it breaks. Sometimes that cost is irritation. Other times, it shows up directly in revenue.

People pay more when the cost of getting it wrong is obvious.

Looking back, that's why starting with why never helped me. It made everything feel big and abstract, when what I needed was something smaller. Specific enough that I'd know it when I saw it.

Most of the time, a target isn't a group of people. It's a moment where a problem becomes expensive enough that someone wants it gone.

If you don't choose that deliberately, the market chooses for you. And the market usually chooses cheap.

When the target is clear, decisions get easier. Pricing makes sense. Referrals happen.

₱5M in 90 days and I have less than a month left.

If you skipped everything before this, here's the core idea:

The only thing worse than charging ₱5M to someone with a ₱50k budget is charging ₱50k to someone with a ₱5M budget.

Now that you're caught up, here's what matters: demand is non-negotiable.

The offer I'm building is for founders who already have demand. It's a business optimization offer. It tightens systems: clearer roles, cleaner handoffs, better use of time and spend. It's for teams where sales already show up, and what's leaking is operational, not commercial.

That qualifier changes everything.

This work only makes sense when something is already moving.

Which means there's a group I shouldn't sell to, even if it makes the ninety-day target easier.

"We already set up the CRM and the automations. I don't get why sales are still up and down."

If conversations don't repeat, if revenue stops when effort stops, the issue isn't tooling.

It's demand.

And demand doesn't appear because your dashboard improved. You see it in patterns: inbound that doesn't require persuasion, referrals from buyers who already understand the problem, calendars that fill because urgency exists before you explain it.

If that's missing, tightening operations just adds weight. Hiring creates noise. Tools create distance. The founder gets further from what's true.

"Maybe we just need to improve conversion."

I understand the instinct. With a ninety-day clock running, the temptation is to adjust whatever moves fastest. Broaden the promise. Land whoever is willing. Close something.

That's the short game. It also rearranges the problem instead of solving it. If someone needs demand, they need demand. You can't organize your way into demand.

"Sales are coming in. The problem now is we're starting to feel stretched."

That's different. When there's demand, now we're talking. Pricing becomes revealing. Raise it and you see quickly whether the problem carries budget and whether the outcome earns commitment.

"Every client's slightly different. It's working, but it feels harder each month."

Delivery starts to define the ceiling. If every engagement requires reinvention, growth multiplies strain. Exceptions accumulate. Capacity shrinks instead of expands.

"I can't really step away. If I don't check things, things fall apart."

That's the bottleneck. Decisions collect at the top. Activity increases, but output doesn't. The founder works more hours, but the company can't grow beyond their bandwidth.

This is where optimization actually becomes valuable.

That's the lane I'm building in. It narrows the audience and it likely slows early revenue, because it excludes founders who are still trying to generate demand. That's part of choosing the right stage instead of chasing the fastest sale.

It took me years to understand that sequence. I spent a long time improving structure when what I really needed were more qualified conversations. I refined workflows because it felt productive and measurable. The work wasn't wrong. It just wasn't solving the constraint.

That delay costs time.

So before you tighten anything, find out what stage you're actually in. That's the one question this whole experiment kept returning to.

The diagnostic below takes about a minute. It won't tell you you're doing great. It'll tell you where the constraint actually is, and the one thing worth doing about it today.