When I started working with React Native, I thought writing good code meant making it work.

And to be fair — that’s enough when you’re learning.

But after spending almost five years building production applications, maintaining large codebases, fixing performance issues, reviewing pull requests, and debugging bugs that only appeared in production, I realised many of my early habits were actually slowing me down.

Here are ten mistakes I used to make — and what I do instead today.

1. Creating Components That Did Too Much

One of my first habits was creating huge components.

A single screen would contain:

• API calls
• State management
• Business logic
• UI
• Navigation
• Validation
• Animations

Everything lived in one file.

It worked… until it didn’t.

Large components quickly become difficult to understand, almost impossible to test, and painful to modify without accidentally breaking something.

What I do now

I try to give every component one responsibility.

Business logic moves into hooks.

Reusable UI becomes separate components.

Complex calculations become utility functions.

A screen should mostly describe what gets rendered — not how everything works behind the scenes.

2. Overusing useEffect

This is probably the biggest mistake I see — not only in my old code, but in many React applications today.

I used useEffect for everything.

Updating state.

Calculating values.

Synchronising data.

Reacting to other state changes.

Most of these effects weren’t actually side effects.

What I do now

Before writing a useEffect, I ask one question:

Is this really a side effect?

If something can be calculated during render, I calculate it.

If it belongs inside an event handler, I keep it there.

If it comes from props, I avoid duplicating it in state.

Fewer effects usually mean fewer bugs.

3. Premature Optimisation

At one point I wrapped almost every component with React.memo.

Everything. Buttons, Icons, Headers…

Even components that rendered once.

I thought more memoisation meant better performance.

It doesn’t.

Sometimes it actually makes performance worse.

What I do now

I profile first.

If I don’t know what is slow, I don’t optimise it.

Optimisation should solve an existing problem — not an imaginary one.

4. Putting Everything Into Context

Context is amazing.

Until it isn’t.

Early on I treated Context like a global store.

Authentication, Theme, Settings, Notifications… Everything.

Every update caused unrelated components to re-render.

What I do now

Context is for data that is truly global.

For everything else, local state is usually the better choice.

Sometimes the simplest solution is also the fastest one.

5. Ignoring FlatList Performance

I used to think FlatList handled everything automatically.

Then I worked on applications displaying hundreds or even thousands of items.

That’s when performance problems appeared.

What I do now

I pay attention to:

• stable keyExtractor
• avoiding inline functions
• getItemLayout when possible
• memoised row components
• proper windowSize
• avoiding unnecessary re-renders

Small improvements here can completely change how an application feels.

6. Repeating API Logic Everywhere

My early projects looked something like this:

try {
  const response = await axios.get(...)
  ...
} catch (error) {
  ...
}

Repeated dozens of times.

Loading states, Error handling, Authentication…

Every screen implemented them differently.

What I do now

API requests live behind reusable abstractions.

Every request follows the same pattern.

Authentication, retries, logging and error handling are centralised.

The screens become dramatically simpler.

7. Fear of Native Code

For years I avoided touching native Android code.

I thought:

“I’m a JavaScript developer.”

Eventually I had to build native modules.

Then another.

Then another.

It turned out native code wasn’t nearly as scary as I imagined.

What I do now

Whenever React Native cannot do something efficiently, I don’t fight the framework.

Sometimes fifty lines of Kotlin solve what hundreds of lines of JavaScript never could.

Learning just enough native development made me a much better React Native developer.

8. Ignoring Error Reporting

During development everything worked perfectly.

Production was a different story.

Users reported crashes.

Nobody knew why.

What I do now

Crash reporting is one of the first things I configure.

Knowing where an application crashed is infinitely better than guessing.

Good monitoring saves countless hours of debugging.

9. Writing Code for Today Instead of Tomorrow

Sometimes I wrote code that solved the current ticket as quickly as possible.

Then another feature arrived. Then another.

Soon every change became risky because everything depended on everything else.

What I do now

I don’t try to predict the future.

But I do leave the codebase in a slightly better state than I found it.

Future me is just another developer who deserves readable code.

10. Thinking React Native Is “Just React”

React Native uses React.

But mobile development introduces an entirely different set of challenges.

Memory, Offline behaviour, Permissions, Animations, App lifecycle, Background execution, Native limitations, Battery consumption, Platform differences…

Once I stopped treating mobile like a website, I started building much better applications.

Final Thoughts

Looking back, none of these mistakes were “bad.”

They were simply part of the learning process.

Every project taught me something new.

Every production bug made me rethink how I approached architecture.

And every difficult feature forced me to become a better engineer.

If you’re just starting with React Native, you’ll probably make some of these mistakes too.

That’s okay.

The important part isn’t avoiding every mistake — it’s recognising them early and continuously improving.

Five years from now, you’ll probably look back at the code you’re writing today and smile.

I know I do.

10 React Native Mistakes I Stopped Making After 5 Years was originally published in ScaleUp on Medium, where people are continuing the conversation by highlighting and responding to this story.

If there’s one topic that every React Native developer struggles with at some point, it’s performance. The framework gives you a huge amount of flexibility — but also enough room to shoot yourself in the foot. Most performance issues aren’t caused by React Native itself, but by the way we structure components, handle state, load images, or manage the JavaScript thread.

The good news? Almost all performance bottlenecks have predictable causes and proven fixes. In this article, I’ll walk you through the techniques I’ve learned (and painfully discovered) over the years — practical tips that you can apply today to make your app smoother, faster, and more stable.

Let’s dive into the optimization playbook.

Use Memoization the Right Way

One of the biggest hidden performance killers is unnecessary re-renders. Even lightweight components can cause noticeable UI lag if they render hundreds of times due to parent updates.

Memoization helps — when used correctly.

How to improve performance:

• React.memo prevents re-renders when props haven’t changed.
• useCallback ensures stable function references.
• useMemo caches expensive calculations.

Common mistake:

Wrapping everything in memoization. This often increases complexity without real gains. Focus on:

• large components
• heavy lists
• components with expensive logic

Virtualize Long Lists (Stop Using ScrollView for 200+ Items)

You’ll find this mistake everywhere: rendering large datasets inside ScrollView.
This forces React Native to mount every item at once—instant performance disaster.

Use instead:

• FlatList
• SectionList
• VirtualizedList

These only render what’s visible on screen and recycle views as you scroll.

Bonus optimizations:

• set initialNumToRender thoughtfully
• avoid inline functions/styles
• use keyExtractor
• enable getItemLayout when item height is fixed

A well-optimized FlatList can turn a choppy list into a buttery smooth experience.

Avoid Inline Functions and Objects in JSX

Inline functions and object literals are created on every render, causing child components to rerender even when nothing changed.

Bad example:

<View style={{ padding: 10 }} onPress={() => handlePress(item)}>

Good example:

const styles = { container: { padding: 10 } };
const onPress = useCallback(() => handlePress(item), [item]);

This small change, applied consistently, can dramatically reduce unnecessary renders — especially in lists.

Optimize Images (Caching, Resizing, Lazy Loading)

Images are one of the biggest sources of performance issues in mobile apps.

Key strategies:

• Use react-native-fast-image for caching and smarter loading.
• Compress images before bundling them.
• Avoid using huge images where thumbnails would work.
• Lazy-load off-screen images (especially in carousels and product lists).

A single unoptimized image can slow down your app more than all JavaScript logic combined.

Use Reanimated for Smooth Animations

React Native’s built-in Animated library runs many calculations on the JS thread—fine for simple fades, but not enough for complex interactions.

react-native-reanimated moves animations to the UI thread. This results in:

• smoother gestures
• consistent FPS
• better interactions on low-end Android devices

If you’re building anything with drag-and-drop, shared transitions, or gesture-heavy UI, Reanimated is a must.

Optimize Navigation with the Right Navigator

Navigation libraries can have different performance characteristics.

Two tips:

• Use createNativeStackNavigator (faster because it uses native views).
• Use lazy or unmountOnBlur to avoid loading unnecessary screens.

Each screen you leave mounted keeps its component tree alive. Sometimes that’s good — sometimes it’s not. Choose intentionally.

Reduce Re-Renders With Better Component Architecture

A giant component with 2,000 lines of code is not only hard to maintain — it’s a performance trap.

Best practices:

• Break screens into smaller components.
• Each component manages its own state.
• Keep prop chains shallow.

This prevents a tiny change (e.g., toggling a boolean) from accidentally causing half the UI to rerender.

Reduce Bridge Traffic (Minimize JS ⇄ Native Communication)

One of the hidden performance bottlenecks in React Native is the bridge — the communication layer between JavaScript and native code. Every time your JS code sends data to native (or vice versa), it adds overhead. Individually these calls are tiny, but in large numbers they can visibly slow down animations, gesture handling, and lists.

Common sources of excessive bridge usage:

• Constantly sending repeated events (e.g., scroll events, sensor data).
• Chatty native modules (e.g., every second sending updates).
• Complex objects being serialized on each bridge call.
• Rapid state updates that trigger multiple renders.

How to optimize bridge usage:

• Batch data instead of sending many small messages.
• Use JSI-based libraries (e.g., Reanimated, MMKV) to avoid the bridge entirely.
• Reduce unnecessary event listeners (especially scroll and gesture listeners).

By minimizing how often you cross the JS/native boundary, your app becomes smoother — especially on low-end Android devices, where the bridge overhead is more noticeable.

Avoid Unnecessary API Calls & Repeated Fetching

Repeated fetches mean:

• extra re-renders
• more work for JS thread
• slower UI

Use caching strategies with:

• React Query
• SWR
• custom caching hooks

Smart caching often results in a visibly faster app without even touching component logic.

Conclusion: Performance Is Not Magic — It’s Technique

React Native is capable of excellent performance, but it rewards developers who understand how rendering works, how threads communicate, and how to structure apps responsibly.

You don’t need to rewrite everything in native code.
You just need the right optimization habits.

Use this playbook as a checklist, and over time, you’ll start recognizing performance pitfalls before they happen.

React Native Optimization Playbook: What Every Developer Should Know was originally published in ScaleUp on Medium, where people are continuing the conversation by highlighting and responding to this story.

You’ve done the hard part.
You validated your idea, confirmed that the problem exists, and proved that your solution can work.

Now comes the fun (and sometimes scary) part — turning your idea into a real product.

Current state: where are you now

At this stage, you’ve managed to:

• Validate the idea and the market.
• Validate the problem you assumed existed with your target audience.
• Validate the solution that solves that problem.

All of this matters because it gives you confidence that you are onto something that can actually work.
You’re now sure that you need to build it.

Let’s go step by step.

Defining what to build

A lot of founders don’t spend enough time on this part — defining what to build.

The truth is, not every idea needs a full-scale product right away.
Some products can go live half-baked, gather feedback, and grow as you go. Others must be baked to perfection before showing them to users.

How do you know which path is yours?
It mostly depends on how innovative your idea is.

If your product is something new — opening a new market or changing user behavior — it’s usually better to build together with users.
Define your core differentiator, build the smallest version that demonstrates it, and collect feedback early.

On the other hand, if you’re building a product for an existing, saturated market, you might be better off launching only when your core value proposition is fully realized.

Because in a crowded market, a weak early version can hurt your chances. People already have habits and expectations. To win, you must stand out.

Examples make this clear:

• Facebook started with a small group of university users and built its way up into a completely new market.
• Gmail, however, entered a crowded market but stood out with a sleek interface, large storage, and advanced search.

Both strategies worked, because they matched the product type.

Regardless of your case, always keep two evolving lists:
Core features (MVP) and Future features (R2, R3…).

Keep it simple: everything not needed for your first release goes into the second list.
Your priorities will evolve as you learn more, but two things will always drive decisions — time and budget.

Let’s say you’re building Uber. Your initial feature list might look like this:

Feature  | Time | Cost
Authentication & Login | 1 week | €2,000
Upload Photo | 1 day | €1,000
Payment | 2 weeks | €8,000
Real-Time Map Updates | 4 weeks | €16,000
Messaging | 2 weeks | €10,000

At first, all seem essential.

But once you add time and cost, it’s clear that you might skip real-time map updates and messaging for version one, replacing them with simple notifications like “Your ride is near.”

You get to launch faster, cheaper, and still deliver the core experience.

Today, AI tools can make this process even faster.
From generating wireframes and prototypes to creating user flow simulations or early feedback models, AI helps you define and visualize your MVP before spending a single euro on development.

👉 Check out our AI Toolkit for Founders

Choosing the right development approach

Once you know what to build, the next big decision is how to build it.

The most common approaches are:

1. Hiring an in-house dev team
2. Outsourcing development
3. A hybrid model

From our experience at ScaleUp, the hybrid approach works best for early-stage founders.

Here’s why:

• We usually build the first version of the product (the MVP) end-to-end, so founders can move fast and validate early.
• Once the product gains traction or funding is secured, we help the founder bring in a CTO or technical co-founder if needed.
• When that happens, we don’t step away — we reorganize together, keeping our ScaleUp team as an embedded development partner under the founder’s or CTO’s leadership.

This setup gives founders both speed and continuity: a full team from day one, and long-term technical stability as the product grows.

👉 See how we build MVPs (https://www.scaleup.ba/build)

Other options that can work depending on context:

• Continue with an interim CTO from the development company.
• Gradually replace the outsourced team with in-house hires.
• Mix in-house and external devs.
• Offer equity-based partnerships where the dev company acts as a technical co-founder.

Whatever the setup, the key is fit.
Startups need small, agile, and flexible teams that can pivot quickly, not enterprise-sized vendors. Look for a team that is comfortable working with startups, can adjust pricing models, and has full-stack capability (design, development, QA, DevOps).

Avoid managing multiple agencies — it adds unnecessary overhead early on.

And increasingly, consider AI-augmented development workflows.
AI copilots can generate boilerplate code, assist with QA, automate documentation, or even help with refactoring. But they don’t replace human alignment. Someone still needs to own the why behind every feature.

Building the right team

Every successful product starts with the right team setup.

For early stages, this is the usual minimum:

• Frontend or Full-stack Engineer — full-time
• Backend or Full-stack Engineer — full-time
• UI/UX Designer — part-time or full-time

Alongside them, you’ll often need:

• Tech Lead — to guide technical decisions
• Product/Project Manager — to define features, scope, and timelines
• QA Engineer — to ensure quality before launch

As traction grows or funding comes in, you can start thinking about full-time additions. Each startup’s path is unique, so adapt as you go.

Development timeline and roadmap

Once you have your team and plan, it’s time to set your timeline and roadmap.

This step affects everything else — marketing, sales, investor communication, even your fundraising narrative.

A common trap here is the never-ending MVP.
Founders keep tweaking colors, layouts, or animations instead of shipping.
Small details matter, but not more than user feedback.

Launch. Learn. Iterate.

It helps to understand the key development phases:

• Wireframe — low-fidelity blueprint for structure and flows
• Prototype — interactive mockup showing key interactions
• POC (Proof of Concept) — small-scale technical validation
• MVP (Minimum Viable Product) — functional version with core differentiator
• Future Releases (R2, R3) — subsequent iterations after MVP
• Alpha/Beta — early testing phases before public launch
• PMF (Product-Market Fit) — when the product sustains itself financially

Forget buzzwords like “Minimum Loveable Product” — focus on delivering real value, not new acronyms.

Agile development and rapid iteration

Building doesn’t stop when you launch.
Each milestone is the start of another, usually more important, journey.

Once your MVP is live, your job is to test, learn, and improve fast.

There are dozens of frameworks out there — Waterfall, Agile, Scrum, Kanban, Lean Startup.
But the truth is, your process should serve your goal, not the other way around.

Most startups benefit from fast feedback cycles — a mix of Agile and Lean Startup principles.

At ScaleUp, we work in two-week iterations, constantly testing ideas in production with real users. Each sprint includes a feedback loop where we assess what worked, what didn’t, and what to improve next.

👉 See our process here (https://www.scaleup.ba/grow)

AI plays a growing role here, too. Automated test bots, performance monitoring, and AI-driven analytics can spot bottlenecks long before humans do, allowing you to move faster with confidence.

Testing and QA: Don’t ship garbage

Testing starts early.
As soon as you have something functional, you test it.

The first round should catch critical bugs before Alpha users ever touch it.
Your goal: let testers focus on usability, not broken features.

Parallel testing should cover:

• Functionality
• UX and UI
• Security
• Performance
• Compatibility
• Compliance (if relevant)

AI-driven testing tools now make this much easier.
They can automatically detect UI issues, missing states, or inconsistent flows before launch — saving you weeks of manual QA.

Once your Alpha and Beta versions are stable, you’re ready to launch.

Prepare for launch

Before you hit “Publish”, make sure your analytics are in place.
What gets measured gets improved.

Don’t drown in vanity metrics.
Focus on what truly matters for your product’s stage.

The simplest model to follow is AARRR (Pirate Metrics):

• Acquisition — how you attract users
• Activation — how you onboard them
• Retention — how you keep them
• Revenue — how you monetize
• Referral — how users promote you

Start from the top and improve each step iteratively.
And use AI analytics tools when possible — they can surface insights you’d otherwise miss, from predicting churn to recommending feature priorities.

These metrics will guide your next steps, help you prioritize new features, and inform your scaling strategy.

Wrapping up

You’ve built it.
You’ve tested it.
You’ve launched it.

Now the real game begins — scaling.

In the next part of the Startup Series, we’ll talk about what comes next:
How to scale your product, grow your user base, and build a company around your idea without losing focus or momentum.

About ScaleUp

At ScaleUp, we help founders build and scale digital products faster, smarter, and with total ownership. We’ve built over 50 products used by millions of users worldwide. Whether you’re validating your idea or scaling your platform, our embedded teams act as your unfair product advantage.

👉 Let’s build together — Contact Us

Startup Series #3— I need to build it was originally published in ScaleUp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everything starts with an idea. But always remember this:

There is nothing so useless as doing efficiently something that should not have been done at all. — Peter Drucker

The thing is, it’s not just about the actual idea, but whether we are ready to act on it. That is essentially what entrepreneurship is all about. I bet that every one of us, at one point in our lives, has thought to ourselves — “Damn, this would be an awesome idea,” but only a few of us would actually try to turn the idea into reality.

What is even more depressing is that only a few of those who actually try will end up creating a successful product (success being a highly relative term). The weird thing is, it’s not merely a question of perseverance (in most cases, at least), but rather a question of knowing when to stop or pivot. That is the hard truth — even if you believe your idea is something the world truly needs, your potential customers may not agree.

So, the initial question you need to ask yourself is — is the world ready for this product? Are your customers ready for it?

I intentionally say ‘ready’ because it often happens that the product is indeed needed, but simply it is yet too early for it. In any case, the sooner you get the answer to this question, the better.

What is meant by ‘sooner the better’ is not solely about timing, as someone may take your idea before you do. It’s more about being fundamentally practical and spending the least amount of money in the shortest possible time frame to prove that your idea will work. How can you achieve this?

Unfortunately, this is not something that can be templated. The cold truth is, you need to be creative and define your customer segment. Test both the problem and value hypotheses.

Define customer segment

While this might seem obvious, take a moment to consider: who is your customer segment? For whom are you building your product? It’s okay to be broad and not too specific at this stage, but we should have some understanding so we can decide for whom we are going to build the product.

Helpful questions:

1. Are you going to aim for the B2B or B2C segment?
2. In the case of B2C, which age group is likely to use your product the most?
3. For B2C, is there any common/shared interest among potential customers of your product?
4. For B2C, are you aiming for a specific region/country or worldwide?
5. In the case of B2B, are you aiming for startup or enterprise businesses?
6. For B2B, are you targeting any particular industry?
7. For B2B, are there any particular shared financial aspects these companies are required to have? (e.g., 1mm+ ARR)
8. For B2B, are you aiming for a specific region/country or worldwide?

Now, store that somewhere. It’s likely to change as you grow, but it’s always good to know what you defined when you started.

Use all of those answers to the questions to consider if there is someone in your network who fits the parameters. If yes, save their contact info; ideally, they will be part of your focus group. If possible, these contacts should not be your close friends or family, as we want unbiased feedback. However, if that is your only option, talk with them as if it is not your idea. “Mom’s Test” has awesome tips that essentially help you get honest feedback, even from your mom (although you will always be the smartest and the prettiest one!).

Ideally, you will have around 10 contacts in your focus group, but try to add more. Some might not be willing to take part in validating the hypothesis.

Great! At this point, you should already have a list of potential customers for your future product!

Problem hypothesis

So, now let’s get a bit more practical. I need you to ask yourself: What kind of problems are you going to solve with your product? List down all the problems that you want to address.

Be as creative as possible and think deeply about the problem you want to solve. If you come up with multiple problems, try to prioritize them so that you have a leading problem you want to address. To assist in prioritizing, you can use different techniques. For example, you can use a 100-point prioritization method where you split 100 points across all the problems, and the problem with the highest number of points becomes the top priority (you can apply the same technique with the focus group, giving them 100 points to allocate across multiple problems to prioritize them).

Now, you need to decide how to approach testing the problem hypothesis. In general, there are two main approaches: quantitative and qualitative.

Quantitative approach

This essentially means that you need them to think about the problem and assign a numerical value to it. For example:

How frustrating is it for you to xyz? (Then you provide a Likert scale from 1 to 7, where they choose the level of their frustration).

It is important to identify what would be satisfactory for you to validate the problem hypothesis. For example, you might decide that anything above 5 on a scale of 1 to 7 means that the problem hypothesis is validated. Alternatively, you could create your own scale, where scores of 1 to 3 indicate that the problem is not worth resolving, scores of 4 to 5 suggest it might be worth exploring further, and scores of 6 to 7 indicate that you might be on a promising path.

Qualitative approach

Instead of assigning a specific number to a problem with the qualitative approach, you are leaning toward having a discussion with your potential customers and attempting to elicit insightful answers from them.

The most used method here is conducting 1:1 interviews. You should prepare a list of questions to guide the interview, but don’t be too strict in following the script. Keep the questions as broad as possible, as you might uncover additional problems during the conversation.

In general, always try to prompt discussions about previous experiences. Remember, the goal here is to gather unbiased feedback. For instance, if you’re building an art trading mobile app, asking them how they usually buy or sell verified art will provide more insight than asking if they dislike encountering fake art on eBay. These discussions about previous experiences offer valuable insights and often lead to the discovery of additional topics. While it’s important to gain a broad understanding, try to keep the discussion focused on topics relevant to the narrative of your product.

While everyone would like confirmation that they are solving a real problem, it’s crucial to maintain objectivity. The way you ask your questions is extremely important.

Solution hypothesis

At this point, you have your ideal customer segment, your focus group, and furthermore, you have validated the problem! Believe me, you are already ahead of many startups out there. You wouldn’t believe how many startups are building their products now without knowing if what they are building is worth building at all.

Now, let’s test your solution.

This is where things get a bit more complicated, as you might actually need to invest some funds to complete this step.

You can try to explain the solution that you want to build, and for some products, that will be a solid option. Then, you can distribute surveys to gather quantitative data, and voila!

However, for many startups, that approach will not be viable because it is challenging to explain the product without visually showing it. Fortunately, there are multiple options to overcome this obstacle. For example, for many web or mobile apps, you can create a clickable design prototype. This prototype mimics the main functionality of the product and is at least 10 times cheaper than building the actual product.

Even if you proceed with a textual explanation of the solution, I would advise building your clickable prototype afterward. You will benefit greatly from it, as I will explain later.

For now, let’s review the two approaches you used for problem hypothesis validation.

Quantitative approach

If you are all about the data, then the quantitative approach is your best option. One of the safest methods is to create a questionnaire with a mix of questions. Ensure that there is a combination of scaled questions, such as ‘How important do you find XYZ functionality?’ (rated on a scale of 1–7), and open-ended questions, such as ‘While using the prototype, did you find any cool functionality missing that would make your life easier?’

The quantitative approach, like the one above, really assists you in rating the solutions that you offer. However, don’t expect to uncover many cool ideas; people are usually not so fond of thinking outside the box when presented with predefined options.

One important note is not to overdo it with the number of questions, for the same reason as why you shouldn’t expect many cool textual answers on surveys. People are busy and don’t have much time these days, so their motivation to focus and respond truthfully to your questions drops dramatically when they see a survey with a lot of questions. Keep it straight to the point, clear, and concise.

Qualitative approach

The qualitative approach, such as conducting 1:1 interviews, is perfect if you want to uncover hidden thoughts about your product from testers.

I always suggest going with this approach for idea validation, as it can reveal emotions that are simply impossible to detect through survey answers.

Interviews can be conducted online or in-person. Either way, the goal is to capture their emotions and gestures while they click through the prototype. Ask them to perform specific actions and observe if they struggle with them. Pay attention to whether they ask a lot of questions or seem confused. Additionally, inquire about their thoughts on the product and whether they would like to see any changes. Finally, ask if they would use this product that your friend wants to create.

Remember that your goal here is to determine whether it is worth investing your time and resources in building this product.

Conclusion

Remember to document all the insights you gather from these activities. Once you’re ready, review each insight individually and then decide if it’s worth pursuing your idea further.

Understand that from now onwards, you are not only investing your time, but also your money. Every subsequent phase in your journey becomes proportionally more expensive.

Now, if you have made an unbiased decision to continue, it is time to build.

But, who am I? To decide if you want to read more about startups from my point of view, here is a short bio.

I am an entrepreneur by nature who has been involved in building startup products for the last 10 years, taking on different roles such as software developer, business analyst, project manager, product manager, and founder. I have experienced being part of the team from various perspectives, and each viewpoint has been an essential piece in helping me understand the entire cycle and how everything is interconnected. When you’re in the trenches, the bigger picture isn’t always clear, but having been involved in all these teams, I have gained a better understanding of how everything functions because a startup is truly like a living organism. Today, I am the founder and CEO of ScaleUp, where our focus is on building digital startup products with founders and companies from all around the world.

Startup Series #2 — I have an idea was originally published in ScaleUp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently, I had to make two separate React apps exchange data — despite being hosted on different domains. I needed something simple and secure. One of the simplest ways I found to solve this was by using window.postMessage.

The Problem

• App A → running on https://app.example.com
• App B → running on https://widget.example.com

The goal: when a user is about to access App B, App A should check if the user is logged in and then send a short-lived code securely to App B. App B can then verify this code with the backend. Since these apps are on different domains, they can’t directly share storage or state.

Why postMessage?

With postMessage, a page can talk to an iframe or a popup it created. It’s the safe, built-in way the browser lets different origins send messages to each other.

The Setup

1. Sending a Message

From App A, I open App B in a popup and send a short-lived code, which App B can send to the backend to validate the user’s session:

// AppA.tsx
const openWidget = () => {
  // Open App B in a popup
  const widgetWindow = window.open(
    'https://widget.example.com', 
    'widget', 
    'width=800,height=600'
  );
   
  if (widgetWindow) {
    // Generate or get a short-lived code from your backend
    const shortLivedCode = '...'; // Generate this on your backend

    // Send the code securely
    widgetWindow.postMessage(
      { type: 'LOGIN_CODE', code: shortLivedCode },
      'https://widget.example.com'
    );
  }
};

// Example button
<button onClick={openWidget}>Proceed To Widget</button>

It’s important to explicitly specify the target origin (https://widget.example.com) to keep it secure.

2. Receiving a Message

Over in App B, I set up a listener inside a React component:

// AppB.tsx
import { useEffect } from "react";

export default function AppB() {
  useEffect(() => {
    const handleMessage = async (event: MessageEvent) => {
      // Only accept messages from App A
      if (event.origin !== "https://app.example.com") return;

      const { type, code } = event.data;
      if (type === 'LOGIN_CODE') {
        // Verify the code with your backend
        const isValid = await verifyCode(code); 

        if (isValid) {
          console.log('User is authenticated, proceeding...');
        } else {
          console.log('Invalid or expired code, redirecting to login.');
          window.location.href = '/login';
        }
      }
    };

    window.addEventListener("message", handleMessage);
    return () => window.removeEventListener("message", handleMessage);
  }, []);

  return <div>Waiting for login verification...</div>;
}

App B receives the data from App A and exchanges the code with the backend to validate the user session and decide whether to proceed or redirect the user.

Bonus: Sending Back a Response

Sometimes App B might need to respond to App A (for example, to confirm the redirect was handled):

event.source?.postMessage(
  { type: "LOGIN_PROCESSED", result: "success" },
  event.origin
);

Common Pitfalls

• Forgetting to check event.origin → Critical for security. Don’t process messages from unknown domains.
• Using * as the target origin → Okay for testing, but never in production. Always whitelist the exact domain.
• Message shape mismatch → Both apps should agree on the format (e.g., { type, payload }).

Additional Security Measures

1. Make sure to validate the code before sending or using, on both sides, to ensure it matches the expected type or pattern.

2. Set a Timeout for Window Reference

If the popup fails or is closed immediately — alert the user to prevent confusion and improve UX and security.

setTimeout(() => {
  if (!widgetWindow || widgetWindow.closed) {
    alert("Failed to open login widget. Please try again.");
  }
}, 3000);

3. Make sure your backend:

• Issues codes that expire in minutes.
• Accepts codes only once.
• Logs or blocks suspicious reuse attempts.

Final Thoughts

Using postMessage is simple, reliable, and works across domains without violating security rules.

If you’re ever in a situation where two React apps (or even one React app and a vanilla JS widget) need to communicate across domains, don’t overcomplicate it. Start with postMessage.

It’s a valuable approach that every frontend developer should be familiar with.

Cross-Domain Communication in React using postMessage was originally published in ScaleUp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Favicons are small but important — they appear in browser tabs, bookmarks, and mobile home screens. With dark mode becoming more common, it’s a good idea to provide separate icons for light and dark themes. This ensures your site always looks polished, no matter the user’s settings.

Choosing Your Icons

Keep your icons simple and recognizable at small sizes. For best results, start with 16x16 PNG files with transparent backgrounds, then convert them to .ico format. Create two versions: one for light backgrounds (favicon-light.ico) and one for dark backgrounds (favicon-dark.ico). Place them in your React app’s public folder so they can be referenced directly in index.html.

Implementation in React

In your public/index.html, you can use the media attribute to automatically switch icons based on the user’s theme:

<link rel="icon" href="/favicon-dark.ico" media="(prefers-color-scheme: dark)" />
<link rel="icon" href="/favicon-light.ico" media="(prefers-color-scheme: light)" />

This method works without extra JavaScript and ensures the correct favicon appears as soon as the page loads. Modern browsers will detect the user’s preferred color scheme and display the appropriate icon.

Pro Tip: Testing and Caching

Browsers often cache favicons aggressively, so changes might not appear immediately. To test your light and dark mode favicons, try opening your site in an incognito window or do a hard refresh (Ctrl+Shift+R / Cmd+Shift+R). You can also toggle your system’s light/dark mode to make sure the correct favicon appears. This ensures your implementation works reliably across different browsers and devices.

Conclusion

Adding light and dark mode favicons is a small but meaningful improvement to user experience. By using simple PNGs, the right sizes, and the media attribute, you can make your React app look polished across all themes with minimal effort.

Adding Light and Dark Mode Favicons in React was originally published in ScaleUp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why I Had to Go Native

As a React Native developer, I rarely find myself stepping into the native world. React Native abstracts most platform-specific things so well that I almost forgot there’s Java and Kotlin running underneath.

But recently, I had a specific use case: I needed to reboot the Android device directly from my React Native app.

And here’s the catch — this functionality doesn’t exist in the React Native ecosystem. So I had no choice but to go native and write a custom Android module myself.

What React Native Developers Should Know About Native Modules

React Native provides a bridge that allows communication between JavaScript and the native layers (Java for Android and Objective-C/Swift for iOS).

By writing a native module, you can expose native functionality that isn’t available in the default RN APIs. Once registered, these native methods can be called directly from JavaScript using NativeModules.

Use cases include:

• Accessing native Android/iOS APIs
• Performing privileged operations (like device reboot)
• Handling complex performance-critical logic
• Integrating with third-party native SDKs

It’s surprisingly straightforward once you get past the initial setup.

Full Process Overview

Here’s the full step-by-step guide to creating and using a native Android module in React Native (I am using a reboot module as an example here):

1. Navigate to your native module folder
Go to:
android/app/src/main/java/com/app
(Replace com/app with your actual package name.)

2. Create two files

• RebootModule.java – This contains your native logic.
• RebootPackage.java – This exposes the module to React Native.

3. Register the package
Open your MainApplication.java (or MainApplication.kt if you're using Kotlin) and add your custom package in the getPackages() method.

4. Call the native method from JavaScript
Use NativeModules.RebootModule.rebootDevice() inside your React Native code.

Writing Module in Java

Here’s the native Java code I wrote to reboot the Android device from React Native. In this example, the reboot functionality requires root access — the reboot command won't work on regular (non-rooted) Android devices.
Note: Most native modules you write do not require root access. This requirement is specific to the reboot command or any command that requires admin (su) access.

package com.app;

import android.util.Log;
import androidx.annotation.NonNull;
import com.facebook.react.bridge.ReactApplicationContext;
import com.facebook.react.bridge.ReactContextBaseJavaModule;
import com.facebook.react.bridge.ReactMethod;
import com.facebook.react.bridge.Promise;

import java.io.DataOutputStream;
import java.io.IOException;

public class RebootModule extends ReactContextBaseJavaModule {
    private static final String TAG = "RebootModule";

    public RebootModule(ReactApplicationContext reactContext) {
        super(reactContext);
    }

    @NonNull
    @Override
    public String getName() {
        return "RebootModule";
    }

    @ReactMethod
    public void rebootDevice(Promise promise) {
        try {
            Process process = Runtime.getRuntime().exec("su");
            DataOutputStream os = new DataOutputStream(process.getOutputStream());
            os.writeBytes("reboot\n");
            os.flush();
            os.writeBytes("exit\n");
            os.flush();
            os.close();
            
            int exitCode = process.waitFor();
            
            if (exitCode == 0) {
                promise.resolve("Reboot initiated");
            } else {
                promise.reject("REBOOT_ERROR", "Reboot command failed with exit code: " + exitCode);
            }
        } catch (IOException | InterruptedException e) {
            promise.reject("REBOOT_ERROR", "Reboot failed: " + e.getMessage());
        }
    }
}

This class extends ReactContextBaseJavaModule and defines a method rebootDevice() that uses root privileges (su) to execute a reboot command.

Exposing Native Functionality to React Native

To make this native module available in JavaScript, you need to create a ReactPackage and register it.

package com.app;

import com.facebook.react.ReactPackage;
import com.facebook.react.bridge.NativeModule;
import com.facebook.react.uimanager.ViewManager;
import com.facebook.react.bridge.ReactApplicationContext;

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class RebootPackage implements ReactPackage {
    @Override
    public List<NativeModule> createNativeModules(ReactApplicationContext reactContext) {
        List<NativeModule> modules = new ArrayList<>();
        modules.add(new RebootModule(reactContext));
        return modules;
    }

    @Override
    public List<ViewManager> createViewManagers(ReactApplicationContext reactContext) {
        return Collections.emptyList();
    }
}

Now, register this package in your MainApplication.java (or MainApplication.kt if using Kotlin).

import com.app.RebootPackage

override fun getPackages(): List<ReactPackage> =
  PackageList(this).packages.apply {
    add(RebootPackage()) // <-- add this line
}

With that, your native module is ready to use.

Calling the Native Method from JavaScript

Once everything is wired up, using the native method in JS is simple:

import { NativeModules } from 'react-native';

NativeModules.RebootModule.rebootDevice()
  .then(response => {
    console.log(response); // Reboot initiated
  })
  .catch(error => {
    console.error('Reboot failed:', error);
  });

⚠️ Reminder: The reboot command used in this example works only on rooted Android devices. If the device is not rooted, this specific command will silently fail or return a permission error. (Other native modules you create may not have this requirement.).

Final Thoughts

Writing a native module might seem intimidating if you’ve only worked in JavaScript — but it’s not rocket science.

For me, this was a necessary step to bridge a gap in functionality React Native couldn’t fill. I was surprised at how well the integration worked once the setup was complete.

If you’re a React Native dev who’s never went into native land, I encourage you to try writing one small module. Even a simple one like this reboot function can teach you a lot about how the native and JS worlds interact.

How to Write a Native Android Module in React Native was originally published in ScaleUp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

The debate between React Native vs. Native app development is one that many developers and businesses face when they’re ready to build an app.

On one hand, React Native offers cross-platform capabilities and faster development time. On the other, native app development promises optimal performance and full access to device features.

Development Time

A key factor when comparing React Native and Native app development is the development time.

With native development, separate codebases are written for Android and iOS platforms due to their technical differences. This means you’ll need two dedicated teams — one for Android and one for iOS — to ensure your app is available on both platforms. Plus, any code changes require rebuilding and rerunning the entire project, which adds extra time and effort.

React Native simplifies this by using a single codebase for both platforms, enabling developers to build apps for Android and iOS simultaneously. The hot reloading feature further accelerates deployment, as changes can be applied instantly without a full rebuild.

So, if you’re aiming for a faster and more affordable entry into the mobile market across both platforms, React Native is an excellent choice.

Cost

React Native significantly reduces development costs since you’re maintaining a single codebase instead of two. If cost is a key consideration, React Native is the clear winner.

UI/UX Experience

While React Native allows developers to reuse core functionality and write platform-specific code where needed, creating complex user interfaces — such as custom views, intricate navigation patterns, seamless transitions, and animations — can be challenging.

Matching the UI/UX standards of both platforms can also be tricky with React Native. In contrast, native development allows every screen to be designed individually for each platform, delivering a superior mobile app UI/UX experience.

In terms of delivering an exceptional mobile experience, native development is the better choice.

Performance

For most standard use cases, React Native provides commendable performance that’s often comparable to native apps. However, for scenarios involving complex animations or high-performance operations, the JavaScript bridge used by React Native can introduce slight delays, impacting performance.

Scalability

When it comes to scalability, React Native offers developers more flexibility to handle higher workloads and release feature-rich updates. React Native has the edge here.

App Maintenance

Maintaining a native app is more time-consuming because bugs must be addressed separately for each platform.

With React Native, you only need to fix bugs once, and the updates apply across both platforms, making maintenance simpler and more efficient.

When to Choose Native App Development

Go with native app development if:

• You’re building a complex application.
• You want to ensure a superior native user experience.
• Your app relies heavily on device-specific features (e.g., a Brightness Controller app or a video-playing app in the background).
• You’re targeting a single platform.

When to Choose React Native

Choose React Native if:

• You’re building a simple and uniform app.
• You need to launch on both platforms simultaneously.
• You want to enter the market quickly.
• You’re working with a limited budget.

Conclusion

React Native offers advantages like cost-effectiveness, cross-platform compatibility, and faster development time. However, it can face performance and complexity challenges for demanding applications.

Native development excels at delivering high-performance apps that fully leverage device capabilities, though it requires more resources due to separate codebases for Android and iOS.

• Startup Advantage: React Native is great for startups seeking a cost-efficient and quick market entry.
• Enterprise Advantage: Native development is better for businesses prioritizing performance, user experience, and leveraging platform-specific features.

The right choice depends on your business goals, available resources, and emphasis on cost, performance, and user experience.

React Native vs Native Development: Choosing the Right Approach for Your App was originally published in ScaleUp on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re a product designer and you’re not talking to users, let me tell you something straight: you’re guessing. And guessing in product design is the fastest way to waste time, build the wrong thing, and frustrate everyone — your team, your users, and yourself.

A lot of designers avoid user interviews because:

• They think they already know what users want. (They don’t.)
• It feels like extra work. (It’s not — it’s work that prevents rework.)
• They don’t know how to do it properly. (That’s what this article is for.)

If you’re a beginner, or just someone who’s been avoiding user interviews like a dentist appointment, this guide will take you from “What do I even ask?” to “Oh wow, this just made my product actually usable.”

Why Even Do User Interviews?

Because real users don’t care about your beautiful UI. They care about getting something done. And if your product makes their life harder instead of easier, they’ll leave. Fast.

Let me give you a real-world example:

I worked on SHARPENN, a platform connecting consumers with beauty professionals. At one point, our onboarding process was long and complicated. We assumed people would take the time to set everything up properly. (They didn’t.)

So, I ran user interviews — real calls with real people who had never seen the app before. I gave them tasks, watched them struggle, and listened to their thoughts as they tried to sign up. Guess what? Most of them either quit halfway or got frustrated.

Based on those interviews, I cut the onboarding flow significantly, and the result? A huge jump in user retention. No A/B test, no analytics, no guessing — just actual conversations with actual users telling me exactly what was broken.

If I had relied on my assumptions, I would’ve wasted months designing something nobody wanted to use.

How to Run a User Interview (Like a Smart Person, Not a Robot)

Let’s get into the how. Here’s a simple framework to follow:

1. Find the Right Users

Not your coworkers. Not your mom. Not other designers. Find actual target users — people who would realistically use the product.

Where?

• If you have an existing user base, recruit them through email or in-app pop-ups.
• If you don’t, go where they hang out — Facebook groups, Reddit, LinkedIn, Discord, niche communities.

2. Don’t Ask What They Think, Ask What They Do

New designers make the mistake of asking:

• “Would you use this feature?” (They’ll say yes just to be nice.)
• “Do you like this design?” (Meaningless. They’re not UI critics.)

Instead, ask:

• “Can you show me how you currently do [task]?” (Now you see their real process.)
• “What was the last time you struggled with [problem]?” (Now you know if they even have the problem you’re solving.)

3. Give Them a Task, Then Shut Up

This is where you learn the most. Instead of talking about the product, let them use it.

Example: On SHARPENN, I needed to see if non-tech users could navigate the app. So, on a Google Meet call, I gave them tasks like:

• “Find a hairstylist job and apply for the position.”
• “Try to message a professional you like.”

Then I watched.

• Where did they hesitate?
• What confused them?
• Where did they rage-click?

And I didn’t explain anything. If I had to explain it, that meant the UI was unclear.

What to Do With the Insights?

Once you have data from multiple users, look for patterns. If one person gets stuck, maybe they’re just bad at technology. If five out of six get stuck, you’ve got a design problem.

Examples of changes I made based on user interviews:
✅ Cutting onboarding time → More users completed signup.
✅ Reworking navigation → Users found what they needed faster.
✅ Simplifying the main screen → Less confusion, more engagement.

These weren’t “creative” design choices. They were direct responses to real user struggles.

Final Thought: Get Over Yourself & Start Talking to Users

Some designers act like user interviews aren’t necessary because “I understand good UX”. No, you don’t — not until you watch someone completely fail to use your design.

User interviews aren’t extra work. They’re insurance against making dumb design decisions. If you take one thing from this article, let it be this:

Designing without talking to users is like cooking blindfolded — you’re just hoping it turns out fine. Don’t do that.

User Interviews: The One Thing That Will Save You from Designing Garbage was originally published in ScaleUp on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Platform Built for Writers

Medium is designed for writers of all levels, whether you’re a beginner sharing your first thoughts or an expert with years of experience. Unlike setting up a personal blog, which requires managing hosting, design, and SEO, Medium handles everything for you. You can focus entirely on writing and sharing your ideas.

With its clean interface and built-in audience, Medium makes publishing effortless. You don’t need to worry about technical details — just write, hit publish, and your work is out there for readers to discover.

Writing Makes You a Better Thinker

Writing isn’t just about putting words on a page — it’s a process of organizing thoughts, clarifying ideas, and questioning your own understanding. When you write on Medium, you’re not just sharing what you know, you’re also strengthening and improving your own knowledge.

To explain something clearly, you need to be sure about it yourself. This pushes you to research, double-check facts, and think critically. Over time, this habit improves your ability to communicate, analyze, and learn better. Writing regularly on Medium isn’t just about helping others — it’s one of the best ways to grow yourself.

Helping the Community

Sharing knowledge is one of the best ways to give back to the community. When you write on Medium, you’re contributing to a space where people come to learn, find solutions, and gain new perspectives.
What might seem simple or obvious to you could be exactly what someone else needs to read.

We All Learn from Each Other

No one knows everything, but together, we can learn so much. Medium is a place where people from different backgrounds and experiences share their insights, mistakes, and lessons learned. By reading others’ perspectives, you expand your own understanding.

When you write, you contribute to this collective knowledge. Your experiences, no matter how big or small, can inspire or help someone else. And in return, the feedback, comments, and discussions around your writing can teach you new things too.

Your Voice Matters — Start Writing Today!

Everyone has something valuable to share. Whether it’s a lesson you’ve learned, an idea that excites you, or a challenge you’ve overcome, your experiences can inspire and help others. You don’t need to be an expert — just start writing.

Many people hold back because they think their ideas aren’t important enough or that they’re not “good” writers. But the truth is, writing is a skill that improves with practice, and every perspective matters. The more you write, the more confident you become.

I know this because I was once in the same place. I hesitated, wondering if my ideas were good enough or if my writing was strong enough. I was scared to put my thoughts out there. But I took the leap, and now I’m glad I did. Writing has helped me grow, connect with others, and made me realize that every voice, including mine, has value.

So don’t wait for the perfect moment — start today. Share your thoughts, learn from the process, and be part of a community that grows together.

Why You Should Write on Medium: Share, Learn, and Grow was originally published in ScaleUp on Medium, where people are continuing the conversation by highlighting and responding to this story.