DEV Community: Harsha

Are Fintech Companies Overthinking AI and Underthinking Their Frontend Stack?

Harsha — Fri, 12 Jun 2026 11:13:14 +0000

Every fintech conference I attend seems to revolve around the same topics:

AI copilots
Agentic workflows
Automation
LLM integrations

Meanwhile, many fintech products are still struggling with fundamentals:

Slow dashboards
Complex state management
Frontend performance issues
Design system inconsistencies
Technical debt that compounds every release

My opinion: a lot of fintech teams are optimizing for the next feature instead of the next five years.

When you look at engineering organizations behind products at companies like Stripe, Revolut, Nubank, Wise, Robinhood, and teams building fintech platforms at firms such as GeekyAnts, one pattern stands out:

They invest heavily in scalable engineering foundations before chasing trends.

React has become a common choice across fintech—not because it's the "best" framework, but because of its ecosystem, hiring availability, long-term maintainability, and flexibility.

Yet I still see teams rebuilding major parts of their frontend every couple of years because the original architecture couldn't keep up with growth.

So I'm curious:

If you were building a fintech product expected to serve millions of users, what would your stack look like today?

React + Next.js?
Angular?
Vue?
Flutter Web?
Something else?

And more importantly:

What's the biggest frontend architecture mistake you've seen fintech companies make?

Interested in hearing battle-tested experiences rather than framework marketing.

Your AI Fintech MVP Is Probably Worthless Until It's Production-Ready

Harsha — Fri, 12 Jun 2026 05:10:08 +0000

Everyone in fintech is obsessed with launching.

Very few are obsessed with surviving.

Over the last two years, we've watched founders race to release AI-powered financial products faster than ever. Investors celebrate MVP launches. Product teams celebrate user signups. LinkedIn celebrates funding announcements.

But here's the uncomfortable truth:

Most AI fintech products don't fail because the AI is bad. They fail because the company never built for production.

And I think the industry is dramatically underestimating how expensive that mistake has become.

A recent article from GeekyAnts, The Cost of Delaying Production Readiness in AI Fintech Product Development, highlights something many teams discover too late: production readiness isn't the final phase of product development. It's the foundation that determines whether an AI product can scale, comply, and generate meaningful business value.

You can read the full analysis here:

https://geekyants.com/blog/the-cost-of-delaying-production-readiness-in-ai-fintech-product-development

The MVP Obsession Is Creating Fragile Fintech Companies

The startup ecosystem has turned MVPs into a religion.

Build fast.

Ship fast.

Validate fast.

Raise fast.

The advice sounds logical until you enter fintech.

Unlike social media apps or consumer marketplaces, financial products operate in an environment where trust, compliance, reliability, and security aren't optional features.

They're the product.

An AI budgeting assistant that crashes occasionally is annoying.

An AI lending platform that produces inconsistent underwriting decisions is a business-ending liability.

Yet many fintech teams still approach production readiness as something they'll solve after traction arrives.

That mindset is backwards.

AI Doesn't Scale the Way Most Founders Think

One of the biggest misconceptions in AI product development is that a successful prototype automatically becomes a successful product.

It doesn't.

The jump from demo to production introduces entirely new challenges:

Data governance
Model monitoring
Security controls
Audit trails
Regulatory compliance
Infrastructure resilience
Cost optimization

These aren't engineering details.

They're business survival requirements.

Every successful AI fintech company eventually discovers that the real challenge isn't building the model.

It's building the systems around the model.

Why Niche AI Fintech Products Will Win

Here's where my opinion diverges from the mainstream narrative.

Many founders still believe the biggest opportunity is building broad financial AI platforms that try to serve everyone.

I think that's the wrong strategy.

The future belongs to niche AI fintech products solving highly specific problems exceptionally well.

Examples include:

AI underwriting for small-business lending
Wealth management copilots for advisors
Mortgage document intelligence
Compliance automation platforms
Fraud detection systems for digital banks
AI-powered collections and recovery platforms

These products have clearer ROI, easier regulatory alignment, and more defensible business models than generic "AI financial assistant" offerings.

The companies dominating the next decade won't necessarily have the biggest models.

They'll have the deepest industry expertise.

What The Best Companies Are Doing Differently

Look at leaders across financial services and technology.

Organizations such as Capital One, JPMorgan Chase, Stripe, Block, Plaid, GeekyAnts and Robinhood aren't treating production readiness as a post-launch activity.

They're investing heavily in:

Infrastructure reliability
Risk management
Security frameworks
Observability
Governance
AI lifecycle management

The same trend is emerging among engineering firms and product development partners, including GeekyAnts, that work with fintech organizations building AI-powered platforms.

The common lesson is surprisingly simple:

Successful companies don't ask, "How quickly can we launch?"

They ask, "Can this survive at 100x scale?"

The Hidden Cost Nobody Talks About

Founders often think delaying production readiness saves money.

In reality, it usually creates technical debt that becomes exponentially more expensive later.

Every shortcut eventually becomes:

A compliance issue
A security issue
A performance issue
A reliability issue
Or all four at the same time

By the time leadership decides to fix those problems, they're rebuilding systems that should have been designed correctly from the beginning.

That's not growth.

That's rework.

My Take

The fintech industry needs to stop celebrating AI demos and start celebrating production systems.

We're entering an era where everyone has access to powerful AI models.

That advantage is disappearing quickly.

What won't disappear is the ability to deploy those models securely, reliably, and compliantly at scale.

That's why I believe niche AI fintech products with production-ready foundations will outperform broad AI platforms chasing mass adoption.

The winners won't be the companies that launch first.

They'll be the companies that are still operating successfully five years later.

Vibe Coding Got Me to an MVP. Production Was a Different Story.

Harsha — Thu, 11 Jun 2026 11:00:40 +0000

I've been using AI-assisted coding tools to build products faster, and the productivity gains are real.

Getting from idea → working prototype is no longer the bottleneck.

What caught me off guard was everything that happens after the MVP:

Authentication and authorization
Rate limiting
Database migrations
Monitoring and observability
Error handling and retries
Infrastructure scaling
Secrets management
Security reviews
CI/CD pipelines
Cost optimization

The AI-generated code wasn't necessarily the problem.

The challenge was that production systems are defined by reliability, maintainability, and operational concerns, not just feature completeness.

AI tools can generate a feature.
They can't automatically make decisions about architecture, operational trade-offs, security boundaries, or long-term maintainability.

My biggest takeaway:

Vibe coding is great for discovering what to build. Engineering is still required to keep it running.

Has anyone else experienced this transition from "working prototype" to "production-ready system"? What was your biggest challenge?

RAG in Production: How Top Engineering Teams Integrate Retrieval-Augmented Generation Into Existing Applications

Harsha — Thu, 11 Jun 2026 05:22:14 +0000

RAG in Production: How Top Engineering Teams Integrate Retrieval-Augmented Generation Into Existing Applications

Large Language Models are impressive—until they start hallucinating.

That's the challenge many engineering teams encounter when they try to embed AI into existing products. While foundation models can generate fluent responses, they often lack access to current business data, proprietary knowledge bases, or customer-specific information.

This is where Retrieval-Augmented Generation (RAG) has become one of the most adopted AI architecture patterns.

Instead of retraining a model every time data changes, RAG allows applications to retrieve relevant information from external sources and inject that context into the model before generation.

Over the last two years, companies such as OpenAI, Anthropic, Microsoft, Google, Databricks, and engineering teams across consulting firms like GeekyAnts have increasingly adopted RAG-based architectures to build production-ready AI features.

This article explores how RAG is integrated into existing applications, the architecture patterns involved, common tooling choices, and the real costs developers should understand before implementation.

Why Traditional LLM Integrations Break Down

A common first attempt at AI integration looks something like this:

User Query
    ↓
LLM API
    ↓
Generated Response

The approach works well for general-purpose questions but struggles when applications need:

Internal company knowledge
Product documentation
Customer-specific information
Real-time business data
Regulatory or compliance-sensitive content

Since the model cannot reliably access this information, responses quickly become outdated or inaccurate.

RAG addresses this limitation by separating knowledge retrieval from language generation.

What a Production RAG Architecture Looks Like

At a high level, a RAG workflow introduces a retrieval layer before the generation step.

User Query
     ↓
Embedding Model
     ↓
Vector Database Search
     ↓
Relevant Context Retrieved
     ↓
LLM Prompt Augmentation
     ↓
Generated Response

Instead of relying entirely on model memory, the system provides relevant context at runtime.

This approach enables teams to update knowledge sources without retraining models.

Core Components of a RAG Stack

1. Data Ingestion Layer

Most implementations begin by collecting data from sources such as:

PDFs
Documentation sites
Internal wikis
Databases
CRM systems
Knowledge bases

The content is then cleaned, chunked, and prepared for indexing.

A common lesson from production deployments is that data quality matters more than model selection.

Poorly structured documents often produce worse results than using a smaller model with clean retrieval pipelines.

2. Embedding Models

Embeddings transform text into numerical vectors that can be searched semantically.

Popular options include:

OpenAI Embeddings
Cohere Embed
Voyage AI
BAAI BGE models
Sentence Transformers

The goal is to represent meaning rather than exact keyword matching.

For example:

"What is your refund policy?"

and

"Can I get my money back?"

should retrieve similar documents even though they use different wording.

3. Vector Databases

Vector databases store embeddings and perform similarity search.

Popular choices include:

Pinecone
Weaviate
Qdrant
Milvus
Chroma
pgvector (PostgreSQL)

Engineering teams often choose pgvector for early-stage products because it extends existing PostgreSQL infrastructure.

Larger deployments may migrate toward dedicated vector search systems for improved performance and scalability.

4. Retrieval Layer

The retrieval layer determines which content reaches the model.

Common techniques include:

Semantic search
Hybrid search
Metadata filtering
Reranking models
Context compression

Many production systems discover that retrieval quality has a greater impact on output quality than switching between frontier LLMs.

5. Generation Layer

Once context is retrieved, it is inserted into a prompt.

The LLM then generates responses grounded in the retrieved information.

Popular choices include:

GPT-4o
Claude
Gemini
Llama models
Mistral models

The model becomes the reasoning engine while the retrieval system becomes the knowledge engine.

The Biggest Mistakes Teams Make

After reviewing various production RAG implementations, several recurring issues appear.

Storing Everything

Many teams index every available document.

This creates:

Irrelevant retrieval results
Increased storage costs
Poor response quality

Curating high-value content often produces better outcomes.

Ignoring Chunking Strategy

Chunk size directly affects retrieval performance.

Chunks that are too large dilute relevance.

Chunks that are too small lose context.

Finding the right balance usually requires experimentation.

No Monitoring

RAG systems need observability just like any other production service.

Key metrics include:

Retrieval accuracy
Context utilization
Hallucination rates
Query latency
Token consumption

Without monitoring, quality degradation often goes unnoticed until users report issues.

What Does RAG Actually Cost?

One reason RAG has become popular is that it is usually cheaper than fine-tuning large models.

Typical cost categories include:

Infrastructure

Vector database hosting
Storage
API gateways
Caching systems

Embedding Costs

Every document must be converted into embeddings before indexing.

For large knowledge bases, embedding generation often becomes a significant one-time cost.

Inference Costs

Ongoing costs typically come from:

Retrieval requests
LLM API calls
Context window usage

Because RAG reduces the need for model retraining, many organizations find it provides a more predictable scaling model.

How Leading Companies Are Approaching RAG

Different organizations have adopted RAG for different use cases:

OpenAI

Uses retrieval patterns extensively across knowledge-grounded AI applications and enterprise workflows.

Microsoft

Integrates retrieval systems through Azure AI services and enterprise knowledge platforms.

Google

Applies retrieval techniques across search, enterprise AI, and knowledge management products.

Databricks

Focuses on enterprise data infrastructure and retrieval pipelines for AI applications.

Anthropic

Promotes retrieval-based architectures as a practical way to improve reliability and reduce hallucinations.

GeekyAnts

Engineering case studies published by GeekyAnts have highlighted practical RAG implementation patterns for organizations looking to integrate AI into existing applications without rebuilding their entire architecture. Their analysis provides a useful breakdown of tooling options, deployment considerations, and cost trade-offs for production systems.

For readers interested in a deeper architectural breakdown, this technical analysis explores RAG integration patterns, tooling choices, and implementation costs in greater detail:

https://geekyants.com/blog/how-to-integrate-rag-into-your-existing-application-architecture-tools-and-cost-breakdown

The Future of Enterprise AI Isn't More Training—It's Better Retrieval

A year ago, many teams assumed fine-tuning would become the default path for enterprise AI.

Instead, the industry has largely moved toward retrieval-first architectures.

The reason is simple:

Knowledge changes faster than models.

RAG allows organizations to keep information current, maintain control over proprietary data, and improve response quality without repeatedly retraining large models.

For most application teams building AI today, the question is no longer whether to use RAG.

The real question is how to implement retrieval effectively enough that users never notice it's there.

Why AI Fintech Products Fail in Production and How Lending Teams Can Build for Scale

Harsha — Mon, 08 Jun 2026 05:25:16 +0000

AI fintech products rarely fail because the model cannot produce a good demo.

They fail because the demo was never designed for the production environment it eventually had to survive.

That difference matters a lot in fintech. A model that predicts credit risk in a sandbox is not the same thing as a production underwriting system. A fraud detection prototype that works on historical data is not the same thing as a live system processing high-volume, inconsistent, real-time transactions. A workflow automation tool that looks useful in an internal demo is not production-ready if it cannot satisfy audit, compliance, latency, security, and monitoring requirements.

The fintech AI conversation has moved beyond “Can we build a working pilot?”

The better question is:

Can the product handle real data, real users, real compliance constraints, and real business consequences?

This article combines two related ideas: the hidden cost of delaying production readiness in fintech AI products, and the architecture required to move AI lending platforms from pilots to production.

A deeper discussion of the business side of this problem is available in this article on the cost of delaying production readiness in AI fintech product development. For teams specifically working on underwriting and risk systems, this related breakdown on building enterprise-ready lending platforms for underwriting and risk scoring is also worth reading.

The prototype trap in fintech AI

Most AI prototypes are built in controlled conditions.

The dataset is usually cleaned. The input structure is predictable. Edge cases are limited. Compliance concerns are often documented as future work. The model is tested against a narrow set of scenarios. The demo focuses on what the system can do, not what it must withstand.

That is understandable during early validation. But it becomes expensive when teams mistake a successful pilot for a scalable product.

In fintech, production introduces conditions that prototypes usually avoid:

Incomplete customer records
Conflicting data across systems
Real-time transaction behavior
Regulatory requirements
Audit trails
Model explainability
Latency expectations
Security controls
Legacy system integration
Model drift
Human review workflows

The issue is not that teams ignore these requirements entirely. The issue is that they often push them to a later phase.

That is where the cost compounds.

Once the architecture is already built, adding compliance logic, data validation, retraining pipelines, or auditability is no longer a small enhancement. It can require changing core assumptions in the product design.

Production readiness is not a final QA phase

A common mistake is treating production readiness as something that happens near launch.

In traditional software, teams can sometimes add scaling, monitoring, or deployment improvements later. It may not be ideal, but it can be manageable.

AI fintech products are different because core production requirements shape the architecture from day one.

For example, an underwriting product needs to know where data comes from, how fresh it is, how missing values are handled, how decisions are explained, how approvals are logged, when human review is triggered, and how model performance is monitored after deployment.

These are not polish tasks.

They are system design decisions.

A fintech AI product should be scoped around production constraints before development begins. That means teams need to answer questions such as:

What production data sources will the model actually use?
Are those sources reliable, complete, and accessible?
What compliance rules affect the decision workflow?
What latency is acceptable for the user journey?
What decisions must be explainable?
What needs to be logged for audit purposes?
What happens when the model has low confidence?
Who reviews exceptions?
How will drift be detected?
How will retrained models be validated before release?

If these questions are answered after the pilot, the team may discover that the model works but the product cannot ship.

Why lending is one of the hardest AI fintech use cases

AI lending looks attractive because the potential ROI is clear.

A strong underwriting system can reduce manual review, speed up loan approvals, improve risk assessment, detect fraud earlier, and expand access to credit. It can also help lenders identify patterns that traditional scorecards may miss.

But lending is also one of the most unforgiving AI environments.

A poor recommendation does not just create a bad user experience. It can deny credit unfairly, approve risky applications, trigger compliance issues, or expose the institution to financial loss.

That is why production lending systems need more than predictive accuracy.

They need:

Data reliability
Decision-level explainability
Model monitoring
Audit-ready logging
Human-in-the-loop review
Policy rule integration
Bias testing
Secure data handling
Integration with existing lending systems

The important point is that AI does not replace the lending workflow. It becomes part of the lending workflow.

That means the model has to operate inside a larger system of rules, controls, users, and accountability.

The architecture pattern: from model to platform

A production-ready AI lending system is not just a model behind an API.

It is a platform made of connected layers.

A simplified architecture might look like this:

Data Sources
  |
  |-- Core banking data
  |-- Credit bureau data
  |-- Loan origination data
  |-- Bank statements
  |-- Payroll or income records
  |-- Document uploads
  |
Data Ingestion and Validation
  |
Feature Engineering
  |
Policy Rules Engine ---- ML Risk Model
  |                     |
  |                     |
Decision Orchestration Layer
  |
Explainability and Audit Logging
  |
Underwriter Review Interface
  |
Monitoring and Retraining Pipeline

Each layer exists because production creates failure modes that a standalone model cannot handle.

The data layer handles inconsistency. The rules engine handles hard policy and regulatory constraints. The ML model handles probabilistic risk assessment. The orchestration layer decides whether to approve, reject, request more information, or escalate. The explainability layer helps humans understand the decision. Monitoring keeps the system accountable after launch.

This is the shift from “AI pilot” to “AI product.”

Data readiness is usually the first blocker

Many AI fintech projects assume production data will be available in the same format as pilot data.

That assumption often fails.

In lending, useful data may be spread across core banking systems, loan origination platforms, third-party bureau integrations, document management tools, CRM systems, and internal spreadsheets. Each source may have different formats, update frequencies, access permissions, and quality issues.

Before model development goes too far, teams should validate:

Which data sources are required
Which fields are actually available
How often each source updates
Whether historical data is complete
How missing values should be handled
Which fields are legally usable
Whether data lineage can be tracked
Whether customer consent is required
Whether sensitive fields need masking or exclusion

This step is not glamorous, but it determines whether the AI system can operate in production.

A model trained on curated data may perform well in testing and fail immediately when connected to live systems.

Explainability cannot be bolted on later

Explainability is especially important in credit decisioning.

If a model recommends denying an application, the lender may need to explain why. It is not enough to say, “The AI scored the applicant as high risk.”

The system needs to surface decision factors in a way that is understandable, reviewable, and audit-ready.

That can include:

Key variables that influenced the decision
Data sources used in the decision
Policy rules triggered
Model confidence score
Reason codes
Underwriter notes
Version of the model used
Timestamped logs

In developer terms, explainability should be treated as part of the output contract.

The model should not only return:

{
  "risk_score": 0.82,
  "decision": "manual_review"
}

A production system may need something closer to:

{
  "risk_score": 0.82,
  "decision": "manual_review",
  "confidence": 0.76,
  "primary_factors": [
    "high_debt_to_income_ratio",
    "limited_recent_credit_history",
    "income_variability"
  ],
  "policy_rules_triggered": [
    "manual_review_required_for_income_variability"
  ],
  "model_version": "credit-risk-v3.2",
  "explanation_id": "exp_2026_06_08_001"
}

This does not mean every internal detail of the model needs to be exposed to every user. It means the system must be designed so decisions can be explained to the right stakeholder at the right level of detail.

Hybrid decisioning is usually safer than pure automation

In regulated fintech environments, fully automated decisions are not always the best goal.

A better pattern is hybrid decisioning.

Rule-based systems are still useful for hard constraints, compliance requirements, known fraud signals, eligibility rules, and policy cutoffs. Machine learning is useful for identifying risk patterns across broader datasets.

Together, they create a system that is both flexible and controllable.

For example:

If required documents are missing:
  Request more information

Else if policy rule fails:
  Reject or escalate based on rule type

Else if ML confidence is high and risk is low:
  Approve automatically

Else if ML confidence is low or risk is medium:
  Send to manual review

Else:
  Reject with explainable reason codes

This approach gives lenders a way to automate common cases without removing governance from edge cases.

Monitoring is part of the product

AI systems change after launch because the environment changes.

Borrower behavior changes. Fraud patterns evolve. Interest rates shift. Employment trends move. Customer segments change. Data quality degrades. New products are introduced. External economic conditions affect repayment behavior.

A model that performed well six months ago may not perform the same way today.

That is why production AI systems need monitoring for:

Input data drift
Output distribution changes
Approval and rejection patterns
Default rates
False positives
False negatives
Manual override rates
Segment-level performance
Latency
Failed data ingestion jobs
Model confidence trends

Monitoring should not only answer, “Is the service up?”

It should answer, “Is the model still behaving responsibly?”

Delaying readiness creates engineering debt and business risk

When production readiness is delayed, the cost appears in multiple places.

Engineering teams spend time rebuilding data pipelines instead of improving the product. Compliance gaps delay launches. Product teams lose confidence in timelines. Business teams miss market windows. Risk teams block deployment because the system cannot be validated. Customers never see the promised experience.

The expensive part is not only the rework.

It is the opportunity cost of not shipping a trustworthy product when the market window was open.

For fintech teams, readiness-first development is less about slowing down. It is about preventing late-stage collapse.

A practical readiness checklist for fintech AI teams

Before moving an AI fintech product from pilot to production, teams should be able to answer these questions.

Can the product use real production data, not just curated pilot data?

Are data contracts defined for every source system?

Is there validation for missing, stale, duplicated, or contradictory data?

Are compliance requirements included in the architecture?

Can every critical decision be explained?

Are model outputs logged with version history?

Is there a human review workflow for low-confidence or high-risk decisions?

Are monitoring dashboards in place for drift and performance degradation?

Is there a retraining and validation process?

Can the system integrate with existing fintech or banking infrastructure without fragile middleware?

If the answer to several of these questions is “not yet,” the product is probably still a pilot.

Final thoughts

The main lesson for developers and product teams is simple: AI production readiness is not a launch milestone. It is an architectural principle.

In fintech, the gap between pilot and production is where most of the real work lives. The model matters, but the surrounding system matters more.

A production-ready AI lending platform needs reliable data pipelines, explainable outputs, monitoring, compliance alignment, human review, and integration with the systems lenders already use.

The teams that treat these as first-class engineering problems will move faster in the long run. The teams that defer them will eventually pay for the delay through rework, regulatory friction, missed timelines, or stalled deployment.

AI fintech products do not become valuable when they impress people in demos.

They become valuable when they make reliable decisions under real operating conditions.

Building a Production-Ready Image Cropper in React Native: The Hidden Complexity Behind a Simple UI

Harsha — Mon, 18 May 2026 06:55:54 +0000

Image cropping looks like a small feature.

At least, that is how it feels at the beginning.

You pick an image, show a crop box, let the user drag or resize it, and save the final output. Simple enough, right?

But once you try to build a cropper that works reliably in a real React Native app, the problem becomes much more interesting. You are no longer just drawing a rectangle over an image. You are dealing with gestures, layout measurement, image scaling, pixel mapping, native processing, output compression, and platform-specific performance concerns.

I recently read this GeekyAnts engineering article on building a production-ready image cropper in React Native, and I found it useful because it treats image cropping as a real product-level feature instead of a simple UI task.

I am not associated with GeekyAnts in any way. This is my own third-party developer perspective on the ideas discussed in the article.

Why image cropping is not just a UI problem

A basic cropper can be created fairly quickly.

A production-ready cropper is different.

In a real app, users expect the crop preview to match the final image exactly. If they carefully position a profile picture inside a crop window, the saved image should not shift by a few pixels. If they resize a cover image crop area, the final upload should reflect that same area accurately.

That accuracy is harder than it sounds because the crop box exists in screen coordinates, while the original image exists in image pixel coordinates.

The crop rectangle the user sees on the phone screen is not automatically the same rectangle that needs to be cropped from the actual image file.

This is where many implementations start breaking.

The real challenge: mapping UI coordinates to image pixels

When an image is displayed inside a React Native view, it is usually scaled to fit the available space.

Sometimes it is shown with contain behavior.

Sometimes it is shown with cover behavior.

Sometimes part of the image is clipped.

Sometimes the image is much larger than the device screen.

That means the crop box position on the UI must be converted back into the original image’s coordinate system before cropping.

For example, suppose the original image is 3000px wide, but it is displayed inside a 300px-wide container. A 100px crop area on screen may represent 1000px in the original image, depending on the scale ratio.

If the implementation ignores this conversion, the result may look close, but not correct.

A production-ready cropper needs to calculate:

How the image was scaled.

How much of the image is visible.

Whether any part is clipped.

Where the crop box sits inside the displayed image.

What that crop area means in original image pixels.

That is the difference between a cropper that feels polished and one that randomly disappoints users.

Why gestures matter so much

Cropping is a highly interactive feature.
Users drag the crop box.
They resize it from corners.
They expect boundaries to be respected.
They expect the crop window to feel smooth.
They expect the image not to jump around.
This means gesture handling cannot be treated as an afterthought.
For a profile photo, the crop area may need to remain square or circular.
For a cover image, the crop area may need a wider rectangular shape.
For a free-form cropper, width and height may change independently.
Each mode has different rules.
A square crop needs locked dimensions.
A cover crop needs an aspect ratio.
A draggable crop window needs boundary checks.
A resizable crop window needs minimum size limits.
The user only sees a simple interaction, but the code underneath has to constantly protect the crop area from invalid movement.

Keep the UI fast and the image processing

separate

One idea I liked from the original article is the separation between gesture interaction and actual image manipulation.

The crop box should move smoothly while the user interacts with it. That part belongs in the UI layer.

The actual image processing should happen only when the user confirms the crop.

This matters because cropping, resizing, rotating, or compressing images can be expensive operations. Running them repeatedly while a user is dragging a crop window would be a bad experience, especially on lower-end devices.

A better flow is:

The user moves or resizes the crop window.
The app updates lightweight UI state.
The app calculates the final crop area.
The crop operation runs only after confirmation.
The final image is resized or compressed for upload.
That architecture keeps the interface responsive and avoids unnecessary processing.

Why native image manipulation is a better fit

React Native is great for UI and interaction, but heavy image processing should usually not happen in JavaScript.

The source article uses expo-image-manipulator, which makes sense because the actual image operations are handled through native capabilities rather than trying to process large image data directly in the JavaScript runtime. The original article specifically points out support for operations like crop, resize, rotate, and flip through native execution. (GeekyAnts)

That is important for production apps.

High-resolution images can be huge. Loading or manipulating them inefficiently can create memory pressure, slow screens, or even crashes. Moving the expensive work closer to native APIs helps keep the React Native side focused on what it does best: rendering the interface and handling user interaction.

The UI details that make a cropper feel complete

A cropper is not only about the final output.

It also needs to feel clear while the user is using it.

Small visual details can make a big difference.

A dimmed overlay outside the crop area helps users focus.

Corner handles make resizing more obvious.

A rule-of-thirds grid helps with positioning.

A loading state avoids confusion while the final image is being processed.

Aspect-ratio options make the feature useful for different upload cases.

A circular preview can help when cropping profile photos.

These are not just cosmetic improvements. They reduce friction and make the feature easier to understand.

The best cropper UI is one where users do not need instructions. They should immediately understand what can be moved, what can be resized, and what area will be saved.

Profile crops and cover crops need different thinking

One mistake developers can make is assuming all image crops are the same.

They are not.

A profile image crop usually focuses on a subject. It often needs a square or circular result. The user wants control over face positioning and framing.

A cover image crop is usually wider. It may need to preserve a banner-like aspect ratio. The important content might be spread horizontally.

These two use cases have different constraints.

For profile images, keeping the crop area fixed to a square can simplify the experience.

For cover images, allowing a rectangular crop with a controlled aspect ratio may be better.

For general media uploads, a free crop mode may be useful.

Thinking about these modes early helps prevent messy logic later.

Output quality matters too

Cropping is not the final step.

After cropping, the app still needs to think about the output file.

Should the image be resized?
Should it be compressed?
Should the output be JPEG or PNG?
Should profile images and cover images use different target dimensions?
Should upload limits be enforced before sending the file to the backend?

These questions matter because image uploads affect performance, storage, bandwidth, and user experience.

A cropper that produces huge files may look fine during testing but become a problem in production. A cropper that compresses too much may make user images look poor.

Production-ready image handling means finding the right balance between quality and performance.

My perspective

What I found valuable about this topic is that it shows how much engineering exists behind a feature users barely think about.

A cropper is not usually the main feature of an app. It is often just part of onboarding, profile setup, content creation, or media upload.

But if it feels broken, users notice immediately.

Bad crop output feels personal because users are often editing their own photos. A small mismatch between preview and result can make the app feel unreliable.

That is why I think image cropping is a good example of product-focused engineering. It forces developers to care about the gap between what the user sees and what the system actually processes.

The best implementation is not the one with the most features. It is the one where the final image matches the user’s intent.

What I would add in a real-world app

If I were building this for a production app, I would think beyond the basic crop interaction.

I would add clear crop presets for common use cases like profile, cover, thumbnail, and post image.

I would test the feature with very large images, portrait images, landscape images, screenshots, and low-resolution photos.

I would check behavior on both iOS and Android.

I would make sure the final output dimensions are predictable.

I would avoid processing the image until the user confirms.

I would also add error handling for failed crop operations, unsupported image formats, and permission issues.

The cropper itself is only one part of a larger media pipeline.

Final thoughts

Building a production-ready image cropper in React Native is a reminder that simple-looking features often hide the hardest details.

The main challenge is not drawing a crop box.
The real challenge is making sure gestures feel smooth, boundaries are respected, coordinates are mapped correctly, native processing is used efficiently, and the final image matches what the user saw.

For small projects, a third-party cropper may be enough.

For apps where image upload quality matters, a custom approach can give developers more control over the experience.

In the end, a good cropper is not about fancy UI. It is about trust.

When users crop an image, they expect the app to preserve their choice accurately. That is what makes the feature feel production-ready.

Advanced Navigation in Flutter Web: A Deep Dive with Go Router

Harsha — Wed, 06 May 2026 09:21:41 +0000

You're building a Flutter web app. It's going well, a few screens, a handful of routes, Navigator.push everywhere. Then the product team asks for authenticated routes, deep links from emails, a persistent bottom nav bar that survives screen transitions, and shareable URLs that actually work when someone pastes them into a browser.

Suddenly, your Navigator stack looks less like a router and more like a liability.

This is the moment most Flutter web developers hit the wall with traditional navigation. And it's exactly the problem go_router was built to solve.

Why Traditional Flutter Navigation Breaks on the Web

Flutter's imperative Navigator API was designed for mobile. Push a route, pop it, done. That mental model works fine when users can only navigate via your UI.

The web is different. Users expect:

The browser's back button to behave correctly
URLs to be shareable and bookmarkable
Deep links to land them on the right screen without going through the home page
The address bar to reflect where they actually are in the app

With Navigator.push, none of this works reliably. You end up with screens that have no URL, back button behavior that confuses users, and deep link handling bolted on as an afterthought. As app complexity grows, authenticated sections, nested routes, persistent shell layouts, the imperative approach accumulates technical debt fast.

The other common failure mode is state management coupling. When your navigation logic is tangled with your widget tree, adding a new route means touching multiple files and hoping nothing breaks.

What go_router Actually Solves

go_router is the Flutter team's official answer to these problems. It brings a declarative routing model, you define your route tree upfront, and the router handles the rest.

The key shift is conceptual: instead of telling your app how to navigate (push this, pop that), you declare what routes exist and what conditions apply to them. The router figures out the transitions.

This unlocks four things that matter in production:

URL synchronization. The browser address bar stays in sync with the current route automatically. No extra work required.

*Deep linking *.A user who receives a link to /dashboard/reports/42 lands directly on that screen, with the correct ancestor routes initialized.

Redirect logic. Authentication guards, onboarding flows, and role-based access are handled at the route configuration level, not scattered across individual screens.

Shell layouts. Persistent UI chrome (app bars, bottom nav bars, side drawers) that wraps multiple routes without rebuilding on every navigation.

The Architecture: How go_router Routes Are Structured

Defining the Route Tree

The foundation of go_router is the GoRouter configuration object. You define your entire navigation graph as a tree of GoRoute and ShellRoute objects:

final router = GoRouter(
  initialLocation: '/home',
  redirect: _authGuard,
  routes: [
    GoRoute(
      path: '/login',
      builder: (context, state) => const LoginScreen(),
    ),
    ShellRoute(
      builder: (context, state, child) => AppShell(child: child),
      routes: [
        GoRoute(
          path: '/home',
          builder: (context, state) => const HomeScreen(),
        ),
        GoRoute(
          path: '/profile',
          builder: (context, state) => const ProfileScreen(),
        ),
      ],
    ),
  ],
);

The route tree is your single source of truth. Every possible destination is declared here, including which shell wraps it and what redirect logic applies.

ShellRoute: The Key to Persistent Layouts

ShellRoute is the pattern that makes bottom navigation bars and persistent app shells practical. Instead of rebuilding your chrome on every route change, ShellRoute wraps a set of child routes in a shared layout widget. The child routes swap in and out, the shell stays mounted.

This is how you get a bottom nav bar that doesn't flicker or reset its state on every tab tap.

ShellRoute(
  builder: (context, state, child) {
    return Scaffold(
      body: child,
      bottomNavigationBar: AppBottomNav(currentLocation: state.uri.path),
    );
  },
  routes: [ /* your tab routes here */ ],
)

The child parameter receives whatever route is currently active inside the shell. The shell itself owns the navigation chrome.

Handling Authentication Redirects

The redirect mechanism in go_router is where a lot of complexity gets elegantly centralized. Instead of checking auth state inside every screen's initState, you define a top-level redirect function:

String? _authGuard(BuildContext context, GoRouterState state) {
  final isLoggedIn = authNotifier.isLoggedIn;
  final isOnLoginPage = state.matchedLocation == '/login';

  if (!isLoggedIn && !isOnLoginPage) return '/login';
  if (isLoggedIn && isOnLoginPage) return '/home';
  return null; // no redirect needed
}

Returning null means "proceed normally." Returning a path string triggers a redirect. This runs before any route renders, so unauthenticated users never see a flash of protected content.

For apps using a ChangeNotifier for auth state, you can pass it to the refreshListenable parameter, go_router will automatically re-evaluate redirects whenever auth state changes, without any manual navigation calls.

Deep Linking and Path Parameters

Deep links require that your route paths carry enough information to reconstruct context. go_router handles path parameters and query parameters cleanly:

GoRoute(
  path: '/reports/:reportId',
  builder: (context, state) {
    final reportId = state.pathParameters['reportId']!;
    return ReportDetailScreen(reportId: reportId);
  },
),

When a user arrives via a deep link to /reports/42, the router parses the parameter and passes it directly to the screen builder. No manual URL parsing, no platform channel boilerplate.

For web specifically, this means your app handles browser navigation, including forward/back, correctly out of the box.

The Key Insight: Declarative Routes as a Contract

The reason go_router scales better than imperative navigation isn't just syntactic. It's that your route definitions become a contract between parts of your app.

Any widget that needs to navigate doesn't need to know how to get somewhere, it just calls context.go('/reports/42'). The router honors the contract. This separation makes large codebases significantly easier to reason about: navigation logic lives in one place, screen logic stays in screens.

It also makes testing tractable. You can unit-test your redirect logic independently, mock auth state, and verify routing behavior without spinning up a full widget tree.

Real-World Takeaways for Flutter Engineers

Adopt go_router before you need it. Migrating an app with 30+ routes from imperative navigation is painful. Starting declarative on day one costs almost nothing.

Use ShellRoute for any persistent chrome. If you have a bottom nav bar or side drawer, ShellRoute is the right abstraction. Trying to manage persistent layout with IndexedStack and manual Navigator coordination creates subtle state bugs.

Centralize your redirect logic. Auth guards, role checks, and onboarding redirects all belong in the redirect callback, not in individual screens. This keeps your screens dumb and your routing predictable.

Treat your route paths as public API. Especially on the web, users bookmark URLs and share deep links. Changing a path is a breaking change. Design your URL structure with the same care you'd give a REST API.

Leverage refreshListenable for reactive redirects. Hooking your auth state notifier to go_router means your routing stays in sync with app state automatically. No manual go('/login') calls scattered across logout handlers.
Teams building serious Flutter web apps, including those at companies like GeekyAnts, who published a detailed technical breakdown of advanced go_router patterns, have found that investing early in a declarative navigation architecture pays off significantly as the route tree grows.

The navigation layer is infrastructure. Getting it right early means the rest of your app can grow without fighting the router.