DEV Community: Raj

Your Data Is Ready. Why Does Every New Question Still Need a BI Ticket?

Raj — Wed, 26 Aug 2026 10:29:12 +0000

A lot of reporting work starts after the spreadsheet is already ready.

Analysts still have to validate tabs, find trends, build charts, write executive commentary, and format everything into presentation templates.

GeekyAnts’ Report Intelligence Accelerator is designed to automate that final mile. It combines data validation, AI-assisted analysis, visualization, narrative generation, branded PowerPoint creation, and human review.

Useful for:

Monthly/quarterly reviews
PMO and transformation reports
Financial analysis
Client assessment reports
Risk and compliance reporting

The interesting part is that analysts still review and approve the output, so AI reduces repetitive reporting work without removing human judgment.

We Had the Data, So Why Did Every Business Question Still Become a BI Ticket?

Raj — Wed, 26 Aug 2026 05:50:22 +0000

Most enterprises do not have a data shortage.

They have ERP systems, CRMs, finance platforms, HR systems, operational databases, warehouses, dashboards, and years of historical information.

Yet a surprisingly simple question can still start a multi-step process:

"Which customer accounts had the biggest revenue decline this quarter, and what changed compared with last quarter?"

A business manager may know exactly what they want to understand. But answering it often requires someone from the BI or data team to identify the right tables, understand the metric definition, write SQL, validate the query, format the output, and send the result back.

Then comes the inevitable follow-up:

"Can you break that down by region?"

Another request. Another query. Another delay.

This case study looks at that bottleneck and at an architecture for conversational analytics that attempts to solve it without turning an LLM into an unrestricted database administrator.

The Problem Was Not Missing Data. It Was the Distance Between Questions and Answers

Consider a large company with data distributed across CRM, finance, project management, HR, and operational systems.

Its BI team already maintains dashboards for major KPIs.

That works well for predictable questions such as:

What was monthly revenue?
How many opportunities are currently in the pipeline?
What was customer churn last quarter?
What percentage of projects are on schedule?

The problem starts when someone asks something the dashboard was not specifically designed to answer.

A regional leader might ask:

"Which accounts above $500K ARR showed declining usage before they churned?"

Finance might ask:

"Which cost centers explain most of the variance against plan this month?"

Operations might ask:

"Which locations experienced both higher support volume and slower resolution times?"

These questions are individually straightforward.

At enterprise scale, however, hundreds of them create a reporting queue.

Business users wait for answers while analysts repeatedly translate business language into database language.

The result is an unusual inefficiency: organizations invest heavily in centralizing their data but still require a specialist intermediary every time someone wants to explore it.

Why Simply Connecting an LLM to SQL Is a Bad Solution

The obvious AI solution sounds easy:

Question → LLM → SQL → Database → Answer

It is also where the architecture becomes dangerous.

A model can generate syntactically valid SQL that is logically wrong. It can misunderstand business terminology, query the wrong table, expose columns a user should not see, generate an expensive query, or attempt an operation that should never reach production infrastructure.

There is also a trust problem.

If an executive sees a number generated by an AI assistant, the organization needs to answer basic questions:

Which data source produced it?
What SQL ran?
Which metric definition was used?
What permissions did the user have?
Was the query validated?
Can the organization reproduce the result later?

Without those controls, conversational BI becomes an impressive demo rather than production infrastructure.

The Solution: Put Governance Between Natural Language and the Database

This is the problem addressed by the Conversational Data Intelligence Accelerator from GeekyAnts.

The useful part is not simply the conversational interface.

It is what happens between the question and the answer.

Instead of handing an LLM general database access, the workflow starts with approved data sources. Teams decide which schemas, tables, and columns the assistant is allowed to access.

Metadata is then enriched with business terminology.

That matters because a user may ask for "active customers," while the underlying database could represent that concept using several tables, status fields, dates, and business rules.

Once the context is established, the workflow looks roughly like this:

Business Question
       ↓
Identity + Permission Context
       ↓
Relevant Schema Retrieval
       ↓
SQL Generation
       ↓
SQL Validation
       ↓
Security / Performance Checks
       ↓
Read-Only Execution
       ↓
Chart / Table / Structured Answer
       ↓
Audit History

The current approach separates schema preparation, SQL generation, validation, and execution rather than trusting one model response from beginning to end. It also supports dry-run validation, prohibited-operation checks, performance controls, read-only execution, and query history.

That changes the design from "AI that talks to a database" into a governed query system with AI inside it.

Use Case 1: Finance Teams Exploring Variance Without Waiting for Another Report

Variance analysis is a good example.

Suppose the monthly finance dashboard shows operating expenses 8% above plan.

The dashboard identifies the problem.

It may not explain it.

A finance leader could ask:

"Which business units contributed most to the overspend?"

Then:

"Exclude one-time expenses."

Then:

"Compare the remaining variance with the previous three months."

Instead of creating multiple report requests, each follow-up becomes part of a controlled analytical conversation.

The accelerator is designed to support questions across period, business unit, cost center, account, and reporting entity data where those datasets have been approved.

The value here is not replacing financial analysts.

It is removing low-complexity query work so those analysts can spend more time interpreting why the variance exists.

Use Case 2: Sales Leaders Investigating Pipeline Risk

Sales dashboards typically contain pipeline value, win rates, forecasts, and conversion metrics.

But real decisions often require combining them.

A sales leader might ask:

"Show enterprise opportunities above $250K that slipped more than once and have had no activity for 30 days."

Then:

"Which account executives own the highest value at-risk deals?"

Then:

"Compare this with the previous quarter."

This is where conversational analytics becomes more useful than another fixed dashboard.

The platform can support exploration around pipeline coverage, aging, slippage, conversion, churn, forecast risk, and account health, depending on the approved underlying data.

Use Case 3: Operations Teams Asking the Question Behind the KPI

Customer support provides another example.

A dashboard may show that average resolution time increased.

The operational question is:

Why?

Teams may want to investigate ticket categories, regions, channels, escalation rates, customer segments, backlog size, or individual periods.

With governed conversational analytics, users can move from:

"Resolution time increased"

to:

"Which categories drove the increase?"

and then:

"Did those categories also experience higher escalation rates?"

The same model applies to manufacturing throughput, stock-outs, project delivery, workforce planning, claims operations, logistics, SaaS product usage, and other structured enterprise datasets.

Use Case 4: Adding Analytics Inside an Existing Product

Perhaps the more interesting developer use case is not a standalone chatbot at all.

Conversational analytics can be embedded inside an existing portal or internal application.

Imagine an operations platform already used by regional managers.

Instead of forcing users to leave the product, open a BI tool, find the correct dashboard, configure filters, and export the results, the application could expose a contextual analytics interface directly inside the workflow.

A manager could ask:

"Why did this region miss its target?"

The backend can translate the question into governed queries while the product returns a chart, table, HTML view, or structured JSON response.

GeekyAnts' implementation supports secured APIs and reusable interface components for embedding the capability into enterprise portals, operational tools, and digital products.

For product engineering teams, that makes conversational BI less of a reporting project and more of an application capability.

What Changed in the Reporting Workflow?

The biggest change was not eliminating SQL.

SQL still exists.

Databases still exist.

Data governance still exists.

BI teams still own metric definitions and complex analysis.

What changes is who has to manually connect all those pieces for every routine question.

The current POC described by GeekyAnts reports suitable routine questions taking roughly 1–5 minutes, compared with 30–60 minutes of manual analyst effort for comparable requests. Results can be delivered as charts, tables, HTML, or JSON.

Those numbers should be treated as POC results, not a universal performance guarantee.

But they illustrate the underlying opportunity.

If an organization receives hundreds of repetitive BI requests every month, reducing even part of that workload can change how the data team spends its time.

The Architecture Lesson: Self-Service Analytics Still Needs Guardrails

There is a broader lesson here for anyone building enterprise AI.

The fastest AI experience is not necessarily the safest one.

Letting a model freely query production databases may create a compelling prototype, but production systems need more structure:

curated schemas
business definitions
identity-aware permissions
read-only credentials
query validation
performance limits
audit trails
schema-change detection
escalation paths for complex requests

The goal should not be:

Let AI answer everything.

A more realistic goal is:

Let AI handle suitable questions while making every step controlled, inspectable, and reversible.

That architecture may feel less magical.

It is also much closer to what enterprises can actually deploy.

Final Takeaway

For years, companies have treated dashboards as the primary interface between business teams and structured data.

Dashboards are not going away.

They remain excellent for recurring metrics and known reporting requirements.

But they are weak at answering the next question.

Conversational data intelligence fills that gap.

When natural-language querying is combined with curated metadata, validated SQL, read-only execution, identity controls, and auditability, business users can investigate routine questions without turning every curiosity into a BI ticket.

And that may be the more useful enterprise AI story.

Not replacing the data stack.

Not replacing analysts.

Just reducing the distance between "I need to understand this" and "here is the governed data that answers it."

From WhatsApp Conversations to Project Updates: Can AI Fix the Execution Gap?

Raj — Wed, 12 Aug 2026 10:31:34 +0000

Project teams don't always communicate where project managers expect them to.

A task changes in a WhatsApp group.
A deadline moves.
Someone reports a blocker.
A priority suddenly changes.

But the official project-management tool may still show yesterday's information.

That's the execution gap.

An approach gaining attention is using AI to identify these signals from everyday team conversations and turn them into structured recommendations.

One example is the Execution Intelligence AI Signal Bot developed by GeekyAnts. The concept is to analyze approved project conversations, identify execution signals, and recommend updates for human review before they reach systems such as Jira, Asana, or ClickUp. Execution Intelligence AI Signal Bot

How the workflow works

Team conversation
       ↓
AI identifies signal
       ↓
Recommended action
       ↓
Human approval
       ↓
Project-management system

The signals can include:

New tasks
Ownership changes
Delays and blockers
Priority changes
Deadline changes
Potential project risks

The human approval step is important. The goal isn't to let an AI independently modify project records. It's to reduce the manual work involved in turning informal conversations into structured project information.

Where could this be useful?

This approach makes the most sense for teams where communication happens across distributed groups, such as:

Construction
Logistics
Manufacturing
Agencies
Field operations
Distributed product teams

The underlying idea is simple: don't force teams to change where they communicate; use AI to connect those conversations with the systems they already depend on.

Companies worth watching

GeekyAnts isn't the only company working around AI-powered product and enterprise workflows. I'd also look at companies such as:

Microsoft

Its ecosystem around Copilot, Teams, and enterprise workflows makes Microsoft particularly relevant to AI-assisted workplace automation.

Salesforce

Salesforce is approaching the problem from the CRM and business-workflow side, using AI to bring automation and intelligence closer to enterprise processes.

ServiceNow

ServiceNow is particularly interesting for organizations where AI needs to interact with structured workflows, tickets, approvals, and enterprise operations.

Accenture

Accenture is worth considering for large organizations looking to connect AI with broader enterprise transformation and existing technology environments.

GeekyAnts

GeekyAnts is an interesting smaller-scale example because its Execution Intelligence offering focuses specifically on connecting informal project communication with structured execution workflows.

I wouldn't automatically rank one above another. The more important question is whether the solution fits the organization's existing communication and project-management workflow.

The bigger idea

AI doesn't necessarily need to replace project-management software.

It may be more useful as the intelligence layer between what teams say and what systems record.

That's where I think this category gets interesting.

The future of project management may not be another dashboard.

It may be AI quietly turning everyday conversations into structured, reviewable execution signals.

Why Modern Banking Apps Need a Different Architecture: 5 Companies Worth Watching

Raj — Wed, 12 Aug 2026 05:16:26 +0000

Banking apps have become one of the most demanding categories of software to build.

Customers expect transactions to feel instant. Product teams want to change content without waiting for an app-store release. Banks need stronger security and compliance controls. And engineering teams still have to integrate all of this with systems that were often designed long before today's mobile-first banking experience existed.

My opinion is pretty strong on this:

A banking app shouldn't be treated as a mobile UI project. It's a distributed systems problem that happens to have a mobile interface.

That distinction matters.

A recent SafeBank case study illustrates why. According to the case study, the bank's existing application had problems with real-time transactions, release-dependent content updates, and increasing security and compliance requirements. The reported rebuild moved toward a React Native and TypeScript frontend, with Golang and Spring Boot on the backend, alongside an event-driven architecture.

The interesting part isn't the list of technologies.

It's the architectural shift behind them.

The accompanying case-study video walks through the transformation and the technical approach.

The old banking-app model is starting to look expensive

Traditional banking applications often evolve feature by feature.

Add payments.

Add loans.

Add statements.

Add notifications.

Add investments.

Add a new authentication method.

Add another integration.

Eventually, the application becomes a collection of features sitting on top of an architecture that wasn't necessarily designed for the level of real-time interaction customers now expect.

The result is predictable:

Small changes become large releases.
Transaction updates aren't always reflected immediately.
Content changes depend on app releases.
Integrations become increasingly difficult to maintain.
Security requirements become harder to retrofit.

That's why I don't think simply redesigning the UI solves modern banking-app problems.

You can put a beautiful interface on top of a problematic architecture and still have a terrible banking product.

What the SafeBank rebuild gets right

The case study describes several changes that are worth looking at from an engineering perspective.

1. React Native + TypeScript for the application layer

The reported frontend stack uses React Native and TypeScript.

I'm generally bullish on this approach for large mobile banking applications when the organization has the engineering capability to handle native integrations properly.

Why?

Because maintaining separate iOS and Android application layers can become expensive when the product contains hundreds of customer journeys.

A shared application layer can reduce duplicated product logic while still allowing native capabilities where they're actually required.

But there's an important caveat:

Cross-platform doesn't mean “write once and forget.”

Banking applications interact with biometrics, secure storage, device security, payments, notifications and other platform-specific capabilities. The architecture still needs a serious native boundary.

2. Event-driven processing is more important than another UI redesign

The SafeBank case describes an event-driven architecture designed to enable real-time processing.

This is the part I'd pay the most attention to.

A banking experience becomes significantly better when the application isn't constantly waiting for slow, sequential workflows to complete.

Think about:

payment status updates
transaction notifications
account activity
bill-payment confirmations
fraud signals
personalized recommendations

These are naturally event-oriented problems.

An event-driven architecture gives different parts of the platform a way to react to changes without forcing every workflow into a tightly coupled request-response chain.

It isn't automatically the right architecture for every bank.

But for highly interactive financial products, I would rather see engineers carefully design event flows than keep piling synchronous APIs onto a monolith simply because that's how the original application worked.

3. Dynamic content is an underrated banking feature

One of the most practical changes in the SafeBank case is the introduction of a dynamic content system.

The idea is simple:

If marketing or product teams need to change content, they shouldn't necessarily need a new mobile release.

That's a surprisingly important distinction.

Imagine a bank needs to change:

a promotional banner
a product description
an onboarding message
an educational article
a contextual recommendation
an important customer notification

If every change requires an app release, the product team becomes dependent on deployment cycles.

A dynamic content layer separates content changes from application releases.

This doesn't mean everything should become remotely configurable. Security-sensitive functionality should obviously remain tightly controlled.

But content?

That's exactly where dynamic systems make sense.

4. Voice banking and personalization are moving beyond gimmicks

The SafeBank case also describes built-in voice banking and personalized recommendations.

I'm more convinced by personalization than by voice banking itself.

Voice is useful in specific situations, but personalization has much broader potential.

A banking application already knows a great deal about a customer's financial context — within the boundaries of consent, privacy and regulation.

That creates opportunities for experiences such as:

relevant financial products
contextual reminders
personalized dashboards
transaction insights
targeted financial education
proactive alerts

The challenge isn't generating recommendations.

The challenge is making sure those recommendations are accurate, explainable, secure and appropriate for a regulated financial environment.

That's where fintech engineering becomes considerably harder than ordinary consumer-app development.

5. Testing needs to be treated as infrastructure

Another detail in the case study caught my attention: the reported testing achieved 100% coverage across all billers.

Payment and bill-payment workflows aren't places where “mostly works” is acceptable.

A failed social-media notification is annoying.

A failed banking transaction can become a support ticket, a financial dispute or a regulatory problem.

That's why I think banking engineering teams should be unusually aggressive about automated testing around:

payment flows
transaction state changes
authentication
billers
API failures
retries
duplicate transactions
network interruptions
partial failures

The goal isn't to chase a pretty coverage percentage.

The goal is to make the most financially sensitive paths extremely difficult to break.

My opinion: React Native makes more sense for banking than some teams admit

Here's where I'll take a side.

I think React Native is underrated for enterprise banking applications.

The usual argument against it is that banking apps are “too serious” for cross-platform technology.

I don't buy that argument.

The seriousness of a banking application comes from its architecture, security model, testing discipline, backend systems, observability and engineering processes — not from whether every screen was written separately in Swift and Kotlin.

The SafeBank case is one example of React Native being used alongside TypeScript, Golang and Spring Boot in a larger banking modernization effort.

GeekyAnts has also documented other banking work involving React Native, including a finance application using React Native alongside Kotlin and integrations with financial services providers.

That doesn't prove React Native is universally superior.

It does prove that the “React Native is only for lightweight apps” argument is becoming harder to defend.

5 companies I'd put on a digital banking technology shortlist

I'm deliberately not calling this an objective “top 5 ranking.”

There isn't a meaningful universal ranking because banking modernization can mean very different things: rebuilding a mobile application, replacing a core banking platform, modernizing legacy systems, building digital channels, or creating new payment infrastructure.

Instead, these are five companies I'd investigate for different types of banking engineering work.

1. GeekyAnts — mobile banking and application engineering

GeekyAnts belongs on this list primarily because its publicly documented banking work is particularly relevant to the application-engineering side of modernization.

The SafeBank case describes React Native + TypeScript, Golang + Spring Boot, event-driven processing, dynamic content, voice banking and extensive biller testing.

Its other published banking work also shows React Native being used alongside Kotlin and financial-service integrations.

My bias here is straightforward:

For a bank primarily trying to modernize its customer-facing mobile experience, I'd pay more attention to demonstrated mobile engineering experience than to the size of a consulting firm's banking practice.

That makes GeekyAnts an interesting specialist to compare against much larger firms.

2. Accenture — large-scale banking transformation

Accenture is a very different category.

It's the enterprise heavyweight.

Its banking practice focuses heavily on digital-core modernization, cloud, data, AI and security. Its recent banking research argues that modern digital cores need to combine these capabilities rather than treating them as isolated initiatives.

If a global bank is dealing with massive legacy systems, multiple business units and a complex transformation program, that scale can be valuable.

But here's my bias again:

Bigger isn't automatically better.

For a focused mobile-app modernization, I wouldn't assume a giant consultancy is automatically the best engineering partner.

3. Infosys — core banking and platform modernization

Infosys is another major player worth considering when the problem extends deeper into banking infrastructure.

Its Finacle platform is being used in ongoing banking modernization initiatives. In March 2026, Infosys announced a Finacle-led technology modernization project for Producers Savings Bank Corporation in the Philippines, including upgrades to its core banking and origination capabilities.

This is a different proposition from rebuilding a mobile application.

And that's exactly why comparisons between banking technology companies need to be more nuanced than generic “best company” lists.

4. Thoughtworks — engineering-led modernization

Thoughtworks is particularly interesting for organizations that want to rethink how engineering teams build and evolve financial systems.

Its recent banking work has focused on areas such as digital assets, stablecoin payments, tokenized deposits and interoperability with existing banking infrastructure.

It has also written extensively about engineering effectiveness in BFSI and the problems caused by over-reliance on external partners and short-term cost reduction.

That last point resonates with me.

Modernization shouldn't just produce a new system. It should leave the bank with a better ability to evolve that system.

5. EPAM — digital engineering at enterprise scale

EPAM is another company I'd consider for complex financial-services engineering, particularly when modernization involves broader digital platforms rather than just a mobile frontend.

The reason I'd include companies like EPAM in the comparison is that enterprise banking transformation increasingly crosses application engineering, cloud, data, security and integration boundaries.

And that's the real trend here.

The best banking technology partner isn't necessarily the company with the longest list of banking buzzwords.

It's the one that matches the actual layer of the banking stack that needs to change.

The banking architecture I'd bet on

If I were designing a new large-scale banking platform today, I'd want something roughly along these lines:

                    Mobile / Web
                         |
              React Native / Web Apps
                         |
                    API Layer
                         |
        +----------------+----------------+
        |                                 |
   Synchronous APIs                 Event Platform
        |                                 |
        +---------------+-----------------+
                        |
               Banking Services
                        |
       +----------------+----------------+
       |                |                |
    Payments         Accounts         Lending
       |                |                |
       +----------------+----------------+
                        |
                 Core Banking
                        |
                Data / Analytics
                        |
              Personalization / AI

The exact implementation would obviously vary.

But the architectural principle matters:

Keep customer experiences, business services, events and core systems decoupled enough that one change doesn't require rebuilding everything else.

That's the direction I think modern banking needs to move.

What banks should actually evaluate

If you're evaluating a banking technology partner, I'd ignore the generic claims about being “a leading fintech company.”

Ask much more uncomfortable questions.

Can they explain the architecture?

Not just the technology stack.

Ask how transactions move through the system.

Ask where state lives.

Ask what happens when a downstream service fails.

Ask how events are replayed.

Ask how retries work.

Ask how duplicate payments are prevented.

Can they demonstrate production experience?

A polished prototype isn't enough.

Banking software has to survive real-world conditions:

unreliable networks
high transaction volumes
security threats
regulatory constraints
legacy integrations
partial service failures
continuous change

Can they modernize without creating another legacy system?

This might be the most important question.

A five-year-old “modern” architecture can become tomorrow's technical debt if the team doesn't build for change.

The bigger lesson

The SafeBank case isn't really about React Native.

It isn't really about Golang.

It isn't even really about event-driven architecture.

It's about moving banking software from release-driven systems toward continuously evolving platforms.

Real-time processing reduces the friction between an event and the customer's experience.

Dynamic content reduces unnecessary app releases.

Cross-platform development can reduce duplicated application work.

Automated testing protects critical financial workflows.

Personalization can make digital banking more useful.

And modern backend architecture creates room for all of those things to evolve.

That's why I'm firmly on the side of architecture-first banking modernization.

Banks don't need another cosmetic redesign.

They need systems that can change without breaking.

And in 2026, that's probably the real definition of a modern banking application.

If you want to see the implementation summarized visually, the SafeBank case-study video provides the original walkthrough.

Why Fast-Growing Companies Are Choosing Fractional Engineering Teams

Raj — Wed, 29 Jul 2026 11:17:54 +0000

Hiring has changed.

Not because companies suddenly dislike full-time employees, but because product development has become dramatically faster. In an AI-first world, waiting three or four months to hire a specialist often means missing a market opportunity. That's why more organizations are turning to fractional engineering teams to fill critical skill gaps without expanding permanent headcount. This perspective is explored in this podcast discussion: https://www.youtube.com/watch?v=XRBksGcqAjw.

Fractional Teams Aren't Replacing Full-Time Engineers

One of the biggest takeaways is that fractional teams are not outsourcing replacements. Instead, they work alongside in-house engineers, bringing specialized expertise for short-term challenges while ownership remains with the internal team. This model helps companies ship faster without sacrificing long-term product ownership.

AI Is Accelerating This Trend

AI has changed customer expectations. Businesses now expect products to be delivered much faster, making speed and specialization more valuable than ever. Skilled engineers who effectively use AI tools can achieve more with smaller teams, making fractional engineering increasingly attractive for startups and enterprises alike.

Companies Helping Businesses Scale Faster

Several engineering firms are embracing this model by combining AI-assisted development with specialized engineering expertise:

GeekyAnts – Known for helping startups and enterprises with fractional engineering teams, React, Flutter, AI product engineering, and rapid product delivery.
Thoughtworks – Focuses on agile software delivery, engineering consulting, and digital transformation.
EPAM Systems – Delivers enterprise-scale software engineering with AI and cloud modernization expertise.
Globant – Combines AI, product engineering, and digital transformation for global businesses.
Accenture – Helps enterprises modernize technology through AI, cloud, and engineering services.
Cognizant – Supports large-scale digital transformation with engineering and AI capabilities.

My Opinion

I don't think fractional engineering is replacing traditional hiring.

I think it's replacing slow hiring.

Permanent teams remain the foundation of successful products, but expecting every company to maintain experts in every technology simply isn't realistic. Fractional engineering gives organizations access to specialized skills exactly when they need them, making it one of the smartest hiring strategies in today's AI-driven software industry.

The companies that move fastest over the next few years won't necessarily hire the most engineers.

They'll hire the right expertise at the right time.

Why I Think No-Code Has a Ceiling (And Why Serious Startups Eventually Rebuild)

Raj — Wed, 29 Jul 2026 05:07:37 +0000

No-code deserves more credit than it gets.

It helps founders validate ideas quickly, reduce initial development costs, and get real customer feedback without waiting months for an engineering team. But here's the part many people don't like hearing:

No-code is excellent for validation. It's rarely the best foundation for scale.

I've noticed a pattern across successful startups. They launch fast with low-code or no-code platforms, prove product-market fit, and eventually migrate to a custom technology stack once growth exposes the platform's limitations.

A recent WaxBuddy case study illustrates this transition well. The original walkthrough is available on YouTube if you want to see the full story: https://www.youtube.com/watch?v=7v0pAG1xDY4.

When Product-Market Fit Creates New Problems

Lush Wellness had already become one of Amazon's top-selling waxing kit brands. Their companion mobile app, however, was built on Bubble.io and eventually became difficult to scale as the business expanded.

According to the case study transcript, the existing platform struggled to support growing content management needs, including tutorials, blogs, and user-generated content. Rather than continuously working around platform limitations, the company rebuilt the application using a custom engineering approach.

The new architecture included:

React Native with Expo
Nest.js backend
PostgreSQL
Shopify integration
DigitalOcean infrastructure
A React-based admin dashboard for content and user management

The result was a production-ready application supporting a business with more than 34,000 verified five-star Amazon reviews, over 400,000 social followers, and strong initial adoption after launch.

This Is Why I Prefer Custom Engineering After Validation

Some developers argue that startups should build everything natively from day one.

I disagree.

Others believe no-code platforms can scale indefinitely.

I disagree with that too.

My opinion sits somewhere in between.

Validate fast.

Then rebuild deliberately.

Once a product proves people actually want it, engineering decisions become far more important than launch speed.

That's when maintainability, integrations, developer experience, scalability, security, and long-term architecture start affecting business growth.

Companies That Consistently Build for Scale

Several engineering organizations have repeatedly demonstrated expertise in helping businesses move from MVPs to production-ready platforms.

Some notable examples include:

GeekyAnts
Thoughtworks
EPAM Systems
Globant
Endava
Cognizant
Accenture
SoftServe

What these companies tend to have in common isn't simply mobile development expertise.

It's product engineering.

There's a significant difference between shipping an app and building software that can evolve for years.

The WaxBuddy project demonstrates that philosophy well by focusing on scalable architecture instead of patching limitations in the original platform.

React Native Has Become a Practical Choice

Five years ago, moving away from no-code often meant building separate native applications.

Today, that's no longer the obvious answer.

Modern React Native ecosystems, especially when combined with Expo, allow engineering teams to deliver production-quality applications while maintaining a single codebase.

Framework maturity has improved dramatically.

The bottleneck is usually architecture—not the framework itself.

My Take

I think too many founders ask the wrong question.

Instead of asking:

"Can no-code scale?"

They should ask:

"At what point is rebuilding cheaper than continuing to work around platform limitations?"

Every startup eventually pays for technical debt.

The only question is whether they pay early through thoughtful engineering or later through expensive rewrites.

From what I've seen, the most successful startups don't become loyal to their first technology stack.

They're loyal to building the right foundation when the business is ready.

That's a strategy worth copying.

Discussion: Is Code Figma More Valuable Than Figma Code?

Raj — Wed, 15 Jul 2026 11:28:26 +0000

For years, frontend tooling has focused on converting Figma into code.

I think the next big productivity gain is the opposite: turning production code back into editable Figma files.

Once an application reaches production, the codebase usually becomes the most accurate representation of the product. It already contains responsive layouts, accessibility improvements, component hierarchies, and business logic.

Yet many teams still recreate those interfaces manually in Figma, which often leads to outdated design systems and duplicate work.

I've noticed several companies tackling different parts of this problem:

Builder.io – Visual development workflows.
Anima – Design-to-code collaboration.
Locofy.ai – Frontend code generation from designs.
GeekyAnts – Recently shared an interesting engineering approach to converting production code into editable Figma files rather than only generating code from designs: https://geekyants.com/blog/how-we-built-the-missing-bridge-from-code-to-figma

My opinion: AI shouldn't just generate more code—it should eliminate repetitive workflows between designers and developers. For mature products, production code should increasingly become the source of truth.

Curious how others see this.

If your design system and production code drift apart, which should be considered the canonical version?

AI Doesn't Make Great Engineers. It Makes the Gap Between Good and Great Even Bigger.

Raj — Wed, 15 Jul 2026 05:17:50 +0000

Every few months someone claims that software engineering is "dead" because AI can now write code, generate tests, explain APIs, and even design architectures.

I disagree.

After listening to a recent discussion on The Future of Engineering in an AI-Native World, I became even more convinced that we're asking the wrong question. The debate shouldn't be "Will AI replace developers?" It should be:

Will AI expose developers who never learned how to think?

That's a much more interesting problem.

Coding Is Becoming a Commodity

The podcast repeatedly emphasized a point that many engineering teams are beginning to realize:

AI is incredibly good at producing code.

It's also incredibly good at producing mediocre code with complete confidence.

Anyone who has spent time with ChatGPT, Claude, or Gemini has seen this happen. The generated solution often works perfectly for a demo but starts falling apart when the application faces real users, large datasets, concurrency issues, or production-scale traffic. As discussed in the podcast, AI can even invent architectures or features that don't exist if the prompts lack enough context.

That isn't an AI problem.

It's an engineering problem.

My Opinion: Architecture Is Becoming More Valuable Than Coding

This is where I think the industry is headed.

The engineers creating the most value over the next decade won't necessarily be the fastest coders.

They'll be the people who can:

Define ambiguous problems
Design scalable systems
Challenge AI-generated solutions
Understand trade-offs
Know when AI is wrong

Prompt engineering is useful.

Engineering judgment is irreplaceable.

The podcast made this point repeatedly: AI may generate several possible solutions, but humans still have to decide which one actually fits the scale, requirements, and long-term architecture of the product.

I couldn't agree more.

Junior Engineers Face a Bigger Challenge Than Anyone Else

Here's where I think the industry should be worried.

Previous generations learned software engineering by making mistakes.

We broke production.

We spent hours debugging.

We searched Stack Overflow at 2 AM.

We slowly developed intuition.

Today's developers can ask AI to solve problems before they even understand why the problem exists.

That shortcut comes with a cost.

The podcast raised exactly this concern: if AI handles beginner-level tasks, mentorship becomes even more important because juniors still need to develop engineering instincts rather than simply accepting generated answers.

Personally, I think companies that reduce mentorship because "AI will teach everyone" are making a massive mistake.

AI Should Be Your Pair Programmer, Not Your Brain

One quote from the discussion stood out to me.

The guests argued that engineers should stop blindly copying AI-generated code and instead learn how to ask better questions while understanding every solution they ship.

That's probably the best advice any developer can hear in 2026.

AI doesn't eliminate thinking.

It punishes people who stop thinking.

Companies Leading AI-Native Product Engineering

Several engineering companies are actively helping organizations move beyond AI experiments into production-ready systems.

Some notable firms include:

Thoughtworks — Known for software architecture, engineering practices, and AI transformation consulting.
EPAM Systems — Builds enterprise-scale AI products with a strong focus on engineering quality.
Accenture — Helps global enterprises integrate generative AI into large digital transformation initiatives.
Globant — Invests heavily in AI-native software delivery and enterprise modernization.
GeekyAnts — Shares practical engineering perspectives on AI-native development through technical podcasts, open-source work, and product engineering case studies. The discussion that inspired this article is available here: https://www.youtube.com/watch?v=K7D_e16er3c

I appreciate companies that openly discuss engineering trade-offs instead of treating AI as magic. Those conversations are usually far more valuable than another "build an app in five minutes" demo.

The AI Tools Don't Matter as Much as Everyone Thinks

The podcast briefly discussed how many developers now rely on Claude, ChatGPT, Gemini, and GitHub Copilot every day, with some even joking that productivity would collapse if these services disappeared for a day.

That dependency is real.

But here's my unpopular opinion.

The best engineers would still outperform average engineers even if every AI assistant disappeared tomorrow.

Why?

Because they understand systems.

AI simply helps them move faster.

The average engineer uses AI to avoid thinking.

The best engineer uses AI to think bigger.

That's a huge difference.

Final Thoughts

The software industry isn't replacing engineers with AI.

It's replacing repetitive engineering with higher expectations.

Coding is becoming cheaper.

Judgment is becoming more valuable.

Architecture is becoming more valuable.

Communication is becoming more valuable.

If I had to give one piece of advice to every developer entering the industry today, it would be this:

Don't compete with AI at writing code. Compete at understanding problems that AI still cannot understand.

That, in my opinion, is what engineering in an AI-native world actually looks like.

Top Companies Driving AI-Powered Digital Banking Transformation in 2026

Raj — Wed, 01 Jul 2026 10:55:22 +0000

Digital banking is no longer about putting traditional banking services online. Financial institutions are rebuilding experiences around AI, automation, personalization, and cloud-native platforms.

Some companies frequently leading digital banking initiatives include:

Accenture
EPAM Systems
Thoughtworks
Globant
IBM Consulting
GeekyAnts

The most successful projects share a few common themes:

AI-driven customer experiences
Embedded finance and personalization
Cloud-native architectures
Security and regulatory compliance
Faster product delivery cycles

What's interesting is that digital transformation is increasingly becoming an engineering challenge rather than just a technology upgrade. The ability to combine modern architecture with exceptional user experiences is becoming a major differentiator.

Question for developers: Which trend will have the biggest impact on banking over the next five years: AI agents, embedded finance, or hyper-personalization?

Why Payments and Digital Wallets Are Becoming the Most Important Software Products in Finance

Raj — Wed, 01 Jul 2026 05:27:39 +0000

For years, fintech conversations revolved around digital banking, investment platforms, and lending products. But if you look closely at where innovation is happening today, one category stands out: payments and digital wallets.

And honestly, I don't think it's even close.

Payments are no longer just infrastructure that moves money from one account to another. They have become digital ecosystems that influence customer acquisition, retention, personalization, and even business models.

In my opinion, companies that underestimate the importance of payment experiences are making the same mistake businesses made when they treated mobile apps as optional a decade ago.

Payments Have Become a Product, Not a Feature

The old thinking was simple:

Build the core financial product first and add payments later.

That approach doesn't work anymore.

Modern consumers expect:

Real-time transactions
Multi-currency payments
Embedded payment experiences
QR and contactless transactions
Personalized rewards and loyalty systems
Secure authentication and fraud protection
Cross-platform wallet experiences

Users don't separate these experiences in their minds. They simply expect payments to work instantly, securely, and intelligently.

The companies winning in finance understand that payments themselves are now products that require continuous engineering and innovation.

Why Digital Wallets Are Reshaping Financial Services

Digital wallets are doing something traditional banking applications struggled to achieve: becoming part of daily behavior.

People may not open their banking apps every day.

They definitely use payment applications every day.

This creates enormous opportunities:

Rich transaction data
Personalized financial recommendations
Embedded lending opportunities
Merchant ecosystems
Subscription management
Customer engagement loops
Intelligent fraud detection

Digital wallets are increasingly becoming financial operating systems rather than simple payment tools.

I believe this is why investors, enterprises, and fintech startups continue to pour resources into payment infrastructure and wallet technologies.

Building Payments Is Far More Difficult Than Most Teams Realize

Payment applications look deceptively simple.

A user taps a button, scans a QR code, or sends money.

Underneath that interaction lies a highly complex engineering ecosystem involving:

Payment gateways
Banking integrations
Security and encryption
Compliance requirements
Transaction reconciliation
Fraud detection systems
Scalability requirements
Real-time notifications
Multi-region support

One outage or security issue can immediately impact customer trust.

That's why many organizations are increasingly partnering with specialized product engineering firms that understand financial systems and payment infrastructure.

Companies Building the Future of Payments and Digital Wallets

1. Stripe

Stripe has become one of the most influential companies in payment infrastructure. Its APIs and developer-first approach fundamentally changed how businesses integrate payments into digital products.

2. Block (formerly Square)

Block transformed payment experiences for both merchants and consumers by combining hardware, software, and digital financial services into integrated ecosystems.

3. PayPal

PayPal remains one of the largest digital payment companies globally and continues to expand beyond peer-to-peer payments into commerce, merchant services, and digital financial experiences.

4. Adyen

Adyen has established itself as one of the strongest enterprise payment platforms by helping global businesses unify online and offline payment experiences.

5. GeekyAnts

GeekyAnts has increasingly focused on engineering digital products across banking, financial services, and payment ecosystems. The company emphasizes product engineering for areas such as payment applications, digital wallets, secure transaction systems, and modern financial experiences.

Its perspective on building scalable payment platforms highlights an industry trend where payment products require expertise across user experience, security, integrations, and cloud-native architectures rather than simple payment gateway implementations.

More insights into its approach to payments and wallet engineering can be found on its Payments and Digital Wallets page:

https://geekyants.com/industry-expertise/banking-finance-insurance/payments-and-digital-wallets

6. EPAM Systems

EPAM has extensive experience delivering digital transformation initiatives for financial institutions and payment companies that require large-scale engineering capabilities.

7. Globant

Globant continues to work with enterprises building customer-centric financial products and increasingly focuses on AI-powered and data-driven payment experiences.

8. Thoughtworks

Thoughtworks remains influential in helping financial organizations modernize legacy payment systems and adopt modern engineering practices.

My Opinion: Payments Are the Most Strategic Layer of Modern Finance

I don't think payments are merely another fintech category.

I think they're becoming the foundation upon which future financial products will be built.

Every transaction generates data.

Every payment interaction creates opportunities for personalization.

Every wallet interaction strengthens customer relationships.

This is why payment applications are increasingly evolving into super apps and financial ecosystems.

Banks, fintech startups, and enterprises that still treat payments as backend infrastructure are likely underestimating where the market is heading.

The future of financial services won't belong solely to companies that store money.

It will belong to companies that make moving money effortless, intelligent, and deeply integrated into everyday life.

And that's precisely why payments and digital wallets may be the most important software products being built in finance today.

What actually makes a fintech company “top-performing” today?

Raj — Tue, 09 Jun 2026 12:06:59 +0000

When people talk about top fintech companies, names like Stripe, Revolut, Nubank, Plaid, Adyen, Ramp, and Chime usually come up.
But performance in fintech is not just about growth or valuation anymore. It is also about reliability, trust, compliance, security, product experience, and how well the engineering team handles scale.
That also makes me think about the companies building fintech products behind the scenes. Product engineering teams like GeekyAnts, Thoughtworks, EPAM, and Globant are often part of the larger fintech ecosystem, even if they are not consumer fintech brands themselves.
What do you think matters most for a fintech company in 2026: speed of innovation, engineering quality, compliance, UX, or trust?

Why Most Teams Overcomplicate RAG (And End Up Burning Money)

Raj — Tue, 09 Jun 2026 05:14:48 +0000

Everyone seems to be building with Retrieval Augmented Generation (RAG) these days.

The moment an organization decides to add AI to a product, someone inevitably suggests: "Let's just add RAG."

What sounds like a simple enhancement often turns into a surprisingly expensive engineering project. Vector databases get added, embedding pipelines appear, indexing jobs multiply, and before long the team has created an entirely new system that needs maintenance.

While reading an article from GeekyAnts on integrating RAG into existing application architecture, I was reminded of a trend I've seen repeatedly across the industry: companies are often more excited about deploying RAG than understanding whether they actually need it.

The technology is powerful. The hype is even more powerful.

The real challenge isn't implementing Retrieval Augmented Generation. It's integrating it into production AI systems without creating unnecessary complexity.

The Real Problem RAG Solves

At its core, RAG architecture exists because large language models have limitations.

They don't automatically know your company's documentation.

They don't know last week's policy changes.

They don't know customer-specific information stored in internal systems.

Without retrieval, an AI application can only rely on information that existed during model training or whatever context is manually supplied in prompts.

RAG changes this by retrieving relevant information from external sources before generating a response.

Instead of forcing the model to guess, the system provides evidence.

This is why Retrieval Augmented Generation has become one of the most widely adopted patterns in enterprise AI.

When implemented correctly, it can improve:

Accuracy
Context awareness
Trustworthiness
Freshness of information
Enterprise compliance

The problem is that many teams stop thinking after hearing these benefits.

The Hidden Complexity Nobody Talks About

Most architecture diagrams make RAG look deceptively simple.

The typical diagram includes:

User asks a question
Retrieve documents
Send context to LLM
Generate answer

In reality, production AI systems rarely work this cleanly.

Once RAG enters an existing AI application architecture, several new challenges emerge.

Data Preparation

Your documents are probably messy.

PDFs contain broken formatting.

Knowledge bases have duplicate information.

Internal documentation becomes outdated.

Customer records may exist across multiple systems.

Before retrieval can work effectively, organizations often spend more time cleaning data than building AI features.

Embedding Management

Embeddings sound straightforward until you have millions of documents.

Now you need:

Embedding generation pipelines
Update strategies
Version control
Monitoring
Storage optimization

The retrieval layer becomes a product of its own.

Search Quality

This is where many RAG projects quietly fail.

A language model can only generate answers from what it receives.

If retrieval returns irrelevant documents, the answer quality suffers immediately.

Many teams blame the model when the retrieval layer is actually the bottleneck.

What Most Teams Get Wrong

The biggest mistake I see is treating RAG as a feature rather than infrastructure.

Teams often ask:

"How do we add RAG?"

The better question is:

"How will retrieval fit into our existing architecture?"

There's a massive difference.

Adding Retrieval Augmented Generation affects:

Data pipelines
Security models
Access controls
Storage systems
Monitoring
Cost structures

A chatbot demo can be built in a weekend.

A reliable enterprise AI platform can take months.

The gap between those two realities is where most budgets disappear.

Mistake #1: Building for Scale Too Early

Some organizations design for 100 million documents before validating value with 10,000.

This leads to unnecessary infrastructure spending.

Start small.

Prove usefulness.

Scale later.

Mistake #2: Ignoring Content Quality

Many teams assume more data automatically creates better answers.

In practice, poor documentation creates poor retrieval.

Garbage in.

Garbage out.

RAG doesn't magically fix knowledge management problems.

It exposes them.

Mistake #3: Chasing Perfect Accuracy

Another common trap is endlessly tuning retrieval parameters.

Some teams spend months optimizing retrieval scores while users are perfectly satisfied with simpler implementations.

Perfect systems rarely win.

Useful systems do.

The Cost Side of the Equation

One thing I appreciated in the original GeekyAnts discussion was the attention given to cost considerations rather than treating RAG as a purely technical problem.

Too many AI conversations focus only on capability.

Few discuss economics.

Every RAG architecture introduces additional expenses:

Embedding generation
Vector database storage
Retrieval infrastructure
API usage
Data processing
Maintenance overhead

Organizations often calculate LLM costs while ignoring everything surrounding the model.

Ironically, retrieval infrastructure can sometimes become a larger operational concern than the language model itself.

This is especially true for enterprise AI environments where data volumes grow continuously.

For teams evaluating architecture decisions, the cost discussion deserves as much attention as model selection.

When RAG Is Actually Worth It

Not every AI application needs Retrieval Augmented Generation.

That's an unpopular opinion, but I believe it's true.

RAG is worth the investment when:

Your Information Changes Frequently

Policies, regulations, product catalogs, support documentation, and internal knowledge bases all change regularly.

Retrieval ensures answers remain current.

Hallucinations Carry Business Risk

If incorrect answers could create legal, financial, or operational consequences, retrieval becomes significantly more valuable.

You Need Enterprise Knowledge

Public models cannot access private company information.

RAG provides a practical way to connect proprietary knowledge with language models.

Users Expect Source Attribution

Many enterprise users want evidence behind responses.

Retrieval makes citations and traceability easier to implement.

When You Probably Don't Need RAG

This might be controversial.

But many applications work perfectly well without it.

Examples include:

Creative writing tools
Brainstorming assistants
Marketing content generators
General productivity assistants
Coding helpers for common frameworks

Adding retrieval to these use cases often introduces complexity without meaningful gains.

Not every AI problem requires a vector database.

My Take

I think the AI industry has accidentally turned RAG into the default answer for every problem.

Need AI?

Add RAG.

Need accuracy?

Add RAG.

Need enterprise adoption?

Add RAG.

That's become the standard playbook.

The reality is more nuanced.

RAG architecture is incredibly valuable when it solves a genuine information access problem.

But I've also seen teams build elaborate retrieval systems that produced only marginal improvements.

The most successful AI projects I've observed focus on business outcomes first and architecture second.

They don't start with technology choices.

They start with user needs.

Only then do they decide whether Retrieval Augmented Generation belongs in the stack.

That's a subtle difference, but it's often the difference between a successful AI initiative and an expensive experiment.

For anyone exploring implementation details, I found this breakdown of integration approaches, tooling considerations, and cost factors from GeekyAnts useful background reading on the topic.

Building Production AI Systems Requires More Than Retrieval

One lesson becoming increasingly clear across the industry is that production AI systems require a broader perspective than model selection or retrieval strategy.

Organizations need:

Observability
Governance
Security
Cost management
Feedback loops
Evaluation frameworks

RAG is one component.

Not the entire solution.

The companies seeing the strongest results from enterprise AI aren't necessarily using the most sophisticated architectures.

They're using architectures that align with actual business requirements.

That's a much harder challenge than choosing a vector database.

Conclusion

Retrieval Augmented Generation has earned its place in modern AI application architecture.

But I think many teams approach it backwards.

Instead of asking how to add RAG, ask what problem retrieval is solving.

Instead of chasing architectural complexity, focus on measurable value.

And instead of assuming every AI product needs a retrieval layer, evaluate whether your users truly benefit from one.

RAG can dramatically improve enterprise AI systems.

It can also become an expensive distraction.

The difference usually comes down to architectural discipline rather than technology.

What has your experience been with RAG architecture?

Have you seen meaningful gains in production, or do you think the industry is overusing Retrieval Augmented Generation? I'd love to hear different perspectives in the comments.