How We Build Products at Loona (And How You Can Too)

Most people think building a product starts with code. It does not. It starts with a problem.

At Loona, we have a specific philosophy about how products should be built — especially products meant to create real-world impact. We use this philosophy internally when building Loona itself, and we teach it to every student who goes through our programs. It is not theoretical. It is the actual process we follow.

Here it is, in full.

Principle 1: Problems First, Solutions Never

The most common mistake new builders make is falling in love with a solution before they understand the problem. "I want to build an app" is not a starting point. "Food-insecure families in my city cannot easily find which pantries have stock today" is a starting point.

Before you write a single line of code (or prompt a single line from an AI), you should be able to answer:

• Who has this problem? Be specific. "Everyone" is not an answer.
• How do they deal with it today? Every problem has an existing workaround, even if it is bad.
• Why do current solutions fail? This is where your insight lives.
• How will you know if your solution works? Define success before you build.

This is the foundation of design thinking and it is non-negotiable. We teach it in depth in our Product Building Handbook, but the short version is: talk to people before you build for them. Understand their experience. Do not assume.

At Loona, before we built any feature of this platform, we talked to students, parents, and educators. We learned that students did not want another program that felt like school. Parents wanted to see real outcomes, not just participation certificates. Educators wanted something that extended beyond the classroom. These conversations shaped everything we built.

Principle 2: Build the Smallest Useful Thing

There is a concept in product development called the minimum viable product — the smallest version of your product that delivers real value to a real user. Not a prototype. Not a demo. Something that actually helps someone, even if it is basic.

We take this seriously. When we launched Loona's first program cohort, we did not have a polished application portal, an automated review system, or a student dashboard. We had a clear program structure, a mentor, and a way for students to apply. That was enough to learn whether the core idea worked.

Here is how to apply this:

Instead of: Building a full platform with user accounts, a database, notifications, analytics, and social features

Build: A single page that solves the core problem for one type of user

Example: If you are building a tool to connect student volunteers with local organizations:

• Version 1: A simple directory page listing organizations, their needs, and contact info. No accounts. No matching algorithm. Just useful information in one place.
• Version 2: Add a form so organizations can submit their own listings.
• Version 3: Add filtering by cause area, location, and time commitment.
• Version 4: Add accounts so students can save favorites and track their hours.

Each version is useful on its own. Each version teaches you something about what users actually need. And with vibe coding, each version takes days, not months.

Principle 3: Ship Early, Ship Scared

The product you are embarrassed by is the product you should ship. If you wait until it is perfect, you will never launch, and you will never learn whether anyone actually wants what you are building.

We call it "shipping scared" because that is what it feels like. Every time. Even for experienced builders. The internal voice says: "It is not ready. It needs one more feature. The design is not polished enough." That voice is the enemy of progress.

The antidote is a deadline. Pick a date. Tell someone. Ship by that date, no matter what.

In our programs, we build this into the structure. Students have demo days with real deadlines. You present what you have built — not what you planned to build. This creates urgency and accountability, which are the two things most personal projects lack.

Practical advice: Deploy your project the same day you start building it. Use Vercel or Netlify (both free). Put a live URL in the world. It does not matter if the page just says "Coming Soon" — the act of deploying breaks the psychological barrier between "something I am working on" and "something that exists in the world."

Principle 4: Users Are the Only Focus Group That Matters

You can debate features with your friends for weeks. Or you can put your product in front of a real user and learn more in ten minutes than you would in a month of brainstorming.

User feedback is not optional. It is the engine that drives good product development. Here is how to do it without overcomplicating things:

1. Find 3-5 people who have the problem you are solving. Not friends who will be nice. Real users.
2. Watch them use your product. Do not explain it first. Just say "this is a tool that [one sentence]. Try using it and tell me what you think."
3. Write down what they struggle with. Not what they say — what they do. People say "this is great" while visibly struggling to find the submit button.
4. Ask two questions: "What was confusing?" and "Would you use this again?"
5. Fix the biggest problem. Ship again. Repeat.

This is the same process used by every successful product team in the world. It is also the same process of community engagement that drives effective product building — listening to the people you serve, not assuming you know what they need.

Principle 5: AI Is Your Co-Builder, Not Your Replacement

This is where our philosophy diverges from a lot of what you see online about AI and building.

AI tools like Claude are transformatively powerful. They let you build things that would have required a team of engineers just a few years ago. We use them extensively — both internally and in our programs. We wrote about the specifics in our vibe coding best practices guide.

But AI does not replace the founder. It amplifies the founder.

Here is what AI is great at:

• Generating code from descriptions
• Debugging errors
• Explaining technical concepts
• Scaffolding project structure
• Writing boilerplate

Here is what AI cannot do:

• Decide what problem to solve
• Understand a user's emotional experience
• Make judgment calls about tradeoffs
• Care about impact
• Build relationships with the community you serve

The founder provides the vision, empathy, and judgment. The AI provides the execution speed. Together, they are more powerful than either alone. This is the model we teach.

Principle 6: Measure What Matters

"We built an app" is not an outcome. "37 families in our community used our app to find food assistance this month" is an outcome.

From the beginning, define how you will know if your product is working. Not vanity metrics (page views, downloads, likes). Real metrics that connect to the problem you set out to solve.

For products built to solve real problems, this means measuring your impact in concrete terms:

• How many people used it?
• Did it change their behavior or outcome?
• What would have happened without it?
• Is usage growing or shrinking?

Build measurement into your product from the start. It does not have to be complex. Even a simple counter — "X people have used this tool" — gives you real data to learn from.

Principle 7: Sustainability Is a Feature

A product that helps 100 people for a month and then dies is a worse outcome than a product that helps 10 people for a year. Sustainability is not a boring business concept — it is the difference between a project and a venture.

This does not mean you need revenue from day one. It means you need to think about:

• Who maintains this? If you stop working on it, does it die?
• Does it cost money to run? If so, who pays?
• Can it grow without you doing everything? Can other students contribute? Can organizations add their own content?

At Loona, we think about sustaining and scaling from the beginning. Not because scale is the goal — impact is the goal — but because sustainable impact is better than temporary impact.

Putting It All Together

Here is the framework in one sequence:

1. Find a problem worth solving (start here)
2. Talk to people who have the problem
3. Build the smallest useful thing using AI tools
4. Ship it before you feel ready
5. Get it to real users and watch what happens
6. Fix the biggest problem and ship again
7. Measure impact in concrete terms
8. Plan for sustainability so the impact lasts

This is not just how we build at Loona. It is how the best products in the world get built — by people who care deeply about a problem, build quickly, listen constantly, and iterate relentlessly.

The difference is that now, thanks to AI, this process is accessible to a sixteen-year-old with a laptop and an idea. That was not true three years ago. It is true today.

If you want to learn this process with mentorship, a cohort of peers, and real accountability, explore Loona's programs. We will teach you to build — and more importantly, we will help you build something that matters.