DEV Community: Renee Chung

How Shipping Changed the Way I Find Product Ideas

Renee Chung — Fri, 10 Jul 2026 11:50:35 +0000

I used to think finding a product idea was the hardest part of building software. Not because I didn’t have ideas. Because every idea seemed to come with the same questions.

“Why would anyone use your app?”

“There are already apps that do this.”

“What’s different about yours?”

The funny thing is, nobody was asking me those questions.

I was. Every single time.

So I’d write an idea down. Open a blank project. Think about it for a while. Then convince myself not to build it. I’d tell myself the market was too crowded. Or someone else had already built it. Or I couldn’t explain why my version deserved to exist. After a while I realised I had become very good at talking myself out of building things.

Around that time I started watching Marc Lou’s videos. I don’t remember exactly which video it was. I just remember one thing standing out.

He kept building.

Not every product was a huge success. Some worked better than others. But he didn’t seem to spend months trying to answer every question before he started.

He just... built.

I remember thinking maybe I was making this harder than it needed to be.

So I tried something different. Instead of asking, “Is this a good idea?” I asked, “Would I enjoy building this?”

That sounds like a small change. For me, it wasn’t.

It took away this imaginary pressure that every side project had to become a business.

Over the next few months I built a few small products. Some of them didn’t go anywhere. Some got a few users. One of them got a single paying customer.

Most people would probably look at that and say they weren’t successful. I don’t really see them that way anymore. Each one taught me something I didn’t know before. Not just technically. About products. About writing. About talking to people.

About realising that marketing feels very different when you’ve spent your career writing code.

Something else happened that I wasn’t expecting. The more I shipped, the less I worried about finding the perfect idea. Not because I suddenly became good at finding ideas. Because I realised ideas don’t arrive fully formed.

They change while you’re building them.

Sometimes the interesting part of the product isn’t even the thing you started with. Sometimes you only discover it halfway through.

I still remember how much time I spent trying to answer one question.

“What makes your app different?”

These days I think that’s the wrong question to ask at the beginning. Not because it isn’t important. Because sometimes you genuinely don’t know yet.

Sometimes the answer only appears after you’ve spent enough time building.

I’m still figuring this out. I don’t have a framework for finding great ideas. I don’t know if the next thing I build will work.

I still have days where I wonder if anyone will ever use something I’ve spent months making.

That feeling hasn’t really gone away.

But one thing has changed. I don’t wait for certainty anymore.

I build first.

Then I listen.

Then I keep building.

Somewhere along the way, the product usually tells me what it wants to become.

Looking back, I don’t think shipping helped me find better ideas. I think it changed the way I look at them. And maybe that’s been the biggest lesson of all.

How I Ship Apps While Working a Full-Time Job

Renee Chung — Wed, 10 Jun 2026 08:21:05 +0000

I have a full-time job. I also build and ship indie apps on the side.

Not because I have endless energy or some heroic morning routine. Most evenings my brain is fried. And yet — I've shipped three apps this year with more on the way.

Here's how I actually do it, without the productivity guru fluff.

The reality first

Let me be honest about what "shipping while working full-time" actually looks like.

It's not glamorous. Some evenings I open my laptop and manage to fix one bug before calling it a night. Some weeks I barely touch my side projects at all.

I'm not optimising for speed. I'm optimising for not stopping.

I build small things on purpose

My apps are not complex platforms. They are focused, single-purpose tools:

A recipe generator that works from your pantry
An expense tracker
A mood tracker
A to-do list that only lets you focus on one thing at a time

Each one has a core feature and not much else. That's not a limitation — it's the whole strategy. A focused app is something one person can design, build, test, and ship. A platform is a team problem.

When scope is small, the distance between "idea" and "live on the App Store" stays short enough to survive a fried brain.

I committed to one stack early

Flutter, Supabase, RevenueCat. I chose these deliberately — not because I already knew them, but because I wanted to learn them properly and keep using them across every app I build.

The bet is on compounding. Every app I ship with this stack means the next one starts with more familiarity. Instead of re-learning tooling from scratch each time, I'm slowly building muscle memory — and spending more time on the actual product.

Pick a stack with intention. Stick with it long enough to get boring with it. The returns show up later.

I separate high-energy and low-energy tasks

Building a new feature requires a switched-on brain. Writing App Store copy, researching keywords, updating a README, fixing a minor UI issue — these don't.

I've learned to match the task to my energy level. Evenings after a heavy day are not the time to architect a new system. They are fine for polishing a screen, writing a social post, or planning tomorrow's actual work.

Brainstorming, writing, admin — these are fried-brain friendly. Save the hard coding sessions for when you're actually sharp.

I don't wait for motivation

Motivation is unreliable. Routine is not.

I don't wait to feel inspired before opening the project. I just open it. Sometimes I close it 20 minutes later having done almost nothing useful. That's fine. The habit of showing up matters more than any single session.

The apps that never get shipped are the ones that only get worked on when the developer feels like it.

I ship before it's perfect

SimplePlate, my AI recipe app, went through 10 App Store review rounds before it was approved. It launched with bugs I knew about. It launched with features I wished were better.

It launched.

A live app with imperfections beats a perfect app that exists only on your laptop. Real users find real problems. Real downloads tell you whether the idea has legs. Waiting for perfect is just delayed quitting.

The honest reason it works

Every app is a small step toward something bigger. The indie portfolio is a long game — slow, sometimes frustrating, occasionally exciting when a stranger downloads something you made on a tired Tuesday evening.

That context keeps me going on the nights when I'd rather just watch TV.

You don't need a perfect schedule or unlimited energy. You need a reason, a small scope, and the discipline to keep showing up even when the sessions are short and messy.

That's it. That's the whole system.

I'm building 10 Flutter apps in 2026 and documenting the journey. Currently 3/10 live. Follow along on X (@renee_chung).

I learned how to build an AI wrapper by shipping a real app

Renee Chung — Sun, 07 Jun 2026 04:06:30 +0000

I'm not an AI researcher. I'm a backend developer with 16 years of Laravel and PHP experience who wanted to build something with AI.
So I did what made sense — I built a real app.

The idea

Simple Plate is an AI recipe generator. Tell it what ingredients you have, your dietary preferences and cuisine mood, and it generates three recipe ideas for you. Simple problem. Simple solution.

What I didn't expect was how much I'd learn about working with AI APIs by actually shipping something real.

The "AI" part is simpler than you think

The core AI integration is straightforward:

dartfinal response = await openai.chat.completions.create(
  model: 'gpt-4o-mini',
  messages: [
    {'role': 'system', 'content': systemPrompt},
    {'role': 'user', 'content': userPrompt},
  ],
);

That's it. The API call itself is not the hard part.

Prompt engineering is everything

The hard part is getting consistent, useful output. My prompts evolved significantly:

First version: vague, inconsistent results
Added dietary restrictions: better but still repetitive
Added cuisine mood: more variety
Added avoid list for recent recipes: solved repetition
Added pantry scoped history: solved repetition properly

The prompt is where 80% of the real work lives in an AI wrapper.

The non-AI parts took longer

Honest truth — the OpenAI integration took a day. Everything else took weeks:

Apple App Store: 8 rejections before approval
Email verification with Supabase and custom SMTP
Deep linking on Android
RevenueCat subscription setup across iOS and Android
UTC timezone bugs in recipe scheduling
Image generation and caching in Supabase storage

What I'd do differently

Start with the prompt engineering earlier. I spent too long on UI before nailing the core AI output quality. The prompt is your product — treat it that way.

The result

Simple Plate is live on both the App Store and Google Play. Built solo in about a month using Flutter, Supabase, OpenAI, and RevenueCat.

Zero subscribers so far. But it's real, it's live, and I learned more about AI integration by shipping it than I would have from any tutorial.

Sometimes the best way to learn is to just build something real.

Apple Store | Google Play Store