DEV Community: boaz-hwang

How I shipped 3 apps in a month and built the tool that made it possible

boaz-hwang — Tue, 07 Apr 2026 06:36:59 +0000

I quit my job in March. By the end of April, I had three native iOS/Android apps on the App Store.

No team. No co-founder. No funding.

I'm self-taught. No CS degree. 10 years of shipping fullstack — startups, large companies, everything in between. And I did the three apps alone.

Here's what actually happened.

The real bottleneck isn't coding

Before I quit, I spent a week thinking about why solo projects take so long.

Turns out it's not the coding. It's everything around it.

Setting up auth for the third time in two years
Wiring in payments, push notifications, onboarding — from scratch again
Spending half a day deciding between X and Y, then Googling the same thread you've read before
Switching between building and debugging infrastructure that should just work

I had 10 years of experience. I was still losing weeks to setup.

So before I wrote a single line of product code, I built a foundation. Auth. Payments. Push notifications. Navigation patterns. All the things I knew I'd need — done once, reusable everywhere.

Week one was entirely infrastructure. Then the apps started going fast.

The timeline:

Week	What happened
Week 1	Build the foundation — auth, payments, push, navigation. Done once.
Week 2	App #1 submitted. Core feature: 3 days. Setup time: near zero.
Week 3	App #2 submitted. Different problem. Same foundation. Faster.
Week 4	App #3 submitted. Felt like a production line.
After	Productized the system → AI App Factory

Why native apps

I wanted to ship actual native apps to the App Store. Real iOS. Real Android. Not web apps wrapped in a shell.

Web wrappers are fast to generate. But they feel like web apps. Scroll physics are off. Keyboard behavior is wrong. Animations don't match the platform. Users notice even if they can't articulate it.

I was building things I planned to sell. That meant building things people would actually use. So I went native from the start — React Native 0.81 with Expo, a real NestJS backend, Supabase for the database.

More setup upfront. But no compromises on what ships.

The revenue pipeline

Here's the thing most people miss about side projects.

The hard part isn't the app. The hard part is getting to the point where revenue is even possible. Most solo builders never get there. Not because the idea is bad. Because the pipeline is incomplete.

App built → but not submitted. Submitted → but no monetization. Monetization added → but the ad SDK isn't wired. Or the in-app purchase flow breaks on Android. Or the push notification setup was never finished so you can't re-engage users.

Most side projects die in this gap. The app works on your simulator. It never makes it to a real user's phone with money flowing.

So I built the system to close that gap completely:

App Store + Play Store: Automated submission. One command.
AdMob: Pre-installed and configured. Ads show up on day one.
RevenueCat: In-app purchases and subscriptions, wired from the start.
Push notifications: Ready to send. Re-engagement from launch.

After I shipped those 3 apps, actual ad revenue started coming in. $0.35 on the first week. Tiny. But not zero. The pipeline worked.

The point isn't "$0.35 will change your life." The point is: the money pipeline was complete in a weekend. App live on the store, ads connected, users coming in, revenue flowing. Most people spend months and never reach this state.

I'm not selling "you'll make money." I'm selling the pipeline that makes revenue possible. What you earn depends on your idea and your execution. But the infrastructure — the part that stops 90% of side projects from ever generating a dollar — that's handled.

"App launch → Ad connection → First revenue. This pipeline, done in a weekend."

About AI

AI didn't make me fast. A good system made me fast. AI made the system faster to operate.

I think of it like an Iron Man suit. The suit amplifies what you can already do. Put it on someone who knows exactly what they're building — they become much more capable. But if you don't know what you're building, the suit just lets you move in the wrong direction faster.

The thing that actually mattered was being clear about the problem before writing any code. Every hour I spent on that saved ten hours of building the wrong thing. That's been true my whole career. AI didn't change it.

What AI changed: execution got cheaper. The thinking part is still on you.

Common take	What I actually found
AI makes it so you don't need to think	AI amplifies thinking people. It doesn't replace thinking.
The bottleneck is writing code faster	The bottleneck is setup, decisions, and problem definition.
Ship fast = cut corners on the product	Ship fast = eliminate everything except the actual problem.

What the system looks like now

After those three apps, I kept refining. The boilerplate grew. I added AI agents for specific tasks — generating screens from specs, writing API endpoints, scaffolding test cases. I added automation scripts for the tedious parts — App Store metadata, environment setup, icon generation.

The stack: React Native 0.81, Expo ~54, NestJS 11, Supabase, 11 AI agents, 8 automation scripts.

Everything is production-ready from day one. Auth flows. Payment integration. Push notification setup. AdMob. RevenueCat. The things that cost weeks when you start from zero — already built and connected.

It's a one-time purchase. You get the code. You own it. No subscription eating into your margins every month.

What I learned

Three apps in one month is fast. Honestly, the month was exhausting. I wouldn't recommend the pace as a lifestyle.

But a few things from it have stuck:

Write down what you're building before you build it. One paragraph. What problem, for who, how you'll know it worked. Every shortcut here costs double later.

Complete the pipeline, not just the app. An app without monetization, without store presence, without push notifications — that's a demo, not a product. Close every gap before you launch.

Problem definition matters more than technology. I've believed this for 10 years. AI hasn't changed it. It's just made it more obvious — because now the execution gap between people who think clearly and people who don't is immediate.

Ship something real. Not a prototype you're privately embarrassed about. Something you'd actually pay for. Something that can pay you back.

The system I used to ship those three apps is now AI App Factory. Same boilerplate. Same agents. Same revenue pipeline.

If you're building native mobile — or thinking about it — and you're tired of losing weeks to setup before you can even start earning: this is what solved it for me.

Happy to answer any questions about the build in the comments.

Steep Slopes Ahead: Navigating AI's Rapid Changes as a Product Engineer

boaz-hwang — Fri, 28 Mar 2025 05:50:19 +0000

Today's story is about the steep slope of rapid changes in the AI era and how Product Engineers can adapt. To illustrate what's necessary for adaptation, I’m using the analogy of riding a bicycle.

A Steep Slope

Thanks to advancements in AI, makers can now move as swiftly as if racing downhill. Even those without coding knowledge can easily create simple apps, provided they have problem awareness and creativity. This development will likely lead to a surge of diverse apps aimed at addressing inefficiencies across society. Moreover, those with development knowledge can now build richer functionalities more swiftly than ever. Some apps might stay at a prototype level, but many will achieve significantly higher quality.

In the U.S., even before AI’s rapid advancement, some developers were already earning a living from simple apps. For instance, a developer featured recently on Geeknews runs a wedding seating arrangement web app and makes a comfortable monthly income. As AI evolves further, I expect more of such examples—people solving real problems around them with technology, creating tangible business value, and sustaining themselves financially.

However, as more apps emerge to solve various problems, it might become challenging to find the perfect app tailored to an individual's specific needs. With too many apps available, and an inability to know them all, finding the right app could be tough. Yet, this challenge itself could be solved by AI. I imagine AI will evolve toward directly finding suitable apps for us.

One of the reasons I think this way is due to OpenAI's recent announcement of a new feature called Operator. To briefly describe the demo, when a user inputs a request like "Make a restaurant reservation for two at 7 pm" into Operator and selects an appropriate web app, the AI directly controls the computer, accesses the chosen web app, and completes the reservation. During this process, the human never touches the mouse or keyboard. The cursor clicks autonomously, inputs the necessary information, and completes the booking. Though a web app was used, there was zero human involvement in the interaction.

Currently, humans still choose the appropriate app within Operator, but soon even that selection might be handled by AI. It's an entirely plausible scenario if the AI learns human preferences.

The idea of AI selecting services on our behalf leads to another, perhaps even more shocking, shift: people may no longer be the primary users of digital services. Instead, making services user-friendly for AI could become a new competitive edge. We might need to consider developing interfaces tailored specifically for AI rather than humans.

Riding a Bicycle

When facing steep, rapid changes, new tools seem essential for adaptation. With advancements in AI affecting the very concept of user interfaces and more, the role of frontend engineers must evolve accordingly. Although there are many ways to evolve, I see expanding the role into Product Engineering as a compelling direction.

The core of a Product Engineer's role is Product Engineering. But what exactly is Product Engineering? To clarify, I've divided Product Engineering into three phases: Discovery, Architecture, and Development. To simplify understanding, I'll use the analogy of riding a bicycle.

Discovery (Handlebars)

Discovery acts like bicycle handlebars, setting the direction for Product Engineering. It involves recognizing real-world problems and translating them into solvable technical challenges. This stage includes user interviews to pinpoint users' genuine problems. Analyzing and reflecting on interview results helps define the true issue—not creating problems from thin air, but recognizing existing ones. Finally, systematic thinking is crucial, as it influences the next phase, Architecture.

Architecture (Front Wheel)

Architecture guides the direction set by Discovery, just as a front wheel follows the handlebars. It concretizes the path forward for Product Engineering, notably through system design. This stage outlines specifics about how Development will proceed. The more detailed context we provide AI Editors, the higher quality code they produce. With flexible, scalable architecture, developing complex apps becomes achievable.

Development (Rear Wheel and Gears)

Development propels Product Engineering forward, much like the rear wheel of a bicycle. The big gear provides substantial power but moves slowly, analogous to foundational skills (Computational Thinking, Algorithms & Data Structures). The small gear offers less power but moves quickly, similar to practical technical skills (Framework Knowledge, AI Editors). Just as climbing uphill requires the big gear and moving fast demands the small gear, both foundational and practical skills are crucial for effective development. These elements combine with the rear wheel (implementation) to drive Product Engineering forward.

Navigating the Steep Slope

As frontend engineers, we inevitably encounter steep slopes—such as rapid AI advancements. For those equipped with the right tools, such changes can become incredible opportunities. By preparing tools that suit us personally—like having the essential skills needed by frontend engineers to leverage AI advancements—we can lead rather than follow changes.

At the end of March, I'm launching the Product Engineer Community, a gathering of people riding bicycles together, navigating steep slopes with ease. Why not join us and enjoy the ride?

If you’d like to join the Product Engineer Community and ride along, please click the link below to subscribe :)

https://pecwithboazglobal.substack.com/