DEV Community: Raj

4 Companies to Evaluate for Agentic Product Engineering

Raj — Thu, 10 Sep 2026 10:10:09 +0000

AI-generated code still needs to satisfy requirements, integrate with existing systems, and survive testing. For engineering teams, the useful question is how agents participate in that process and who owns the resulting changes.

This discussion draws on GeekyAnts’ explanation of its Agentic Development Life Cycle, alongside published approaches from Thoughtworks, EPAM, and Globant.

The companies below represent different approaches to agentic engineering. Their inclusion reflects documented capabilities, rather than an independently verified performance ranking.

What changes when agents participate across development?

GeekyAnts describes ADLC as a model where agents support planning, implementation, testing, documentation, and analysis. Engineers retain responsibility for architecture, security, quality, and release decisions.

The article also describes an ongoing engagement that connects development with post-release improvement.

The technical implication is that teams need explicit boundaries around agent work. Permission to generate a patch, execute tests, merge changes, and deploy software should be considered separately.

Conventional development already includes automation and review gates. An agentic approach therefore needs to demonstrate how it changes execution, validation, and exception handling.

Which companies offer relevant approaches?

1. GeekyAnts

GeekyAnts’ ADLC description focuses on agent participation within ongoing product engineering, supported by human checkpoints.

The article explains the intended process but does not provide comparative evidence that it outperforms other delivery models.

Useful evaluation: A feature walkthrough showing the requirement, agent-generated changes, reviewer corrections, test results, and release approval.

2. Thoughtworks

[Thoughtworks’ AI/works])combines reverse engineering, requirements enrichment, specification development, code generation, runtime operations, and governance.

Its scope makes it relevant to projects where understanding an existing system is a substantial part of implementation.

Useful evaluation: How engineers validate recovered business rules and detect behavior that an automatically generated specification misses.

3. EPAM

[EPAM’s AI/Run offering] addresses agentic workflows across the product lifecycle, alongside governance, change management, and performance measurement.

It is relevant to organizations evaluating adoption across several engineering teams.

Useful evaluation: How the approach integrates with existing repositories and delivery pipelines, and whether pilot results remain repeatable across different codebases.

4. Globant

[Globant CODA] provides an agentic software development suite covering activities including coding and testing.

Its relevance lies in coordinating AI tooling across multiple development tasks.

Useful evaluation: Whether generated tests independently check business requirements or simply reinforce assumptions already present in generated code.

A practical way to compare the approaches

A shared pilot brief would make the comparison more meaningful than separate vendor demonstrations.

Consider a hypothetical task: adding a new API-backed feature to an existing application. During implementation, the requirement changes, a dependency becomes unavailable, and a validation check fails.

The assessment should examine:

Context handling: Does the agent identify conflicting requirements?
Permission boundaries: Which actions require approval?
Validation: What evidence accompanies the proposed change?
Escalation: When does the agent stop and involve an engineer?
Delivery effort: How much review and rework remains?

Elapsed delivery time, reviewer effort, defects, and operating costs provide a stronger basis for comparison than generated code volume.

What should “human oversight” mean?

A review checkpoint only works when the reviewer can understand and challenge the proposed change.

For a database migration, that could include the intended schema change, affected dependencies, validation results, and recovery approach. A generic approval prompt provides little basis for a decision.

The engineering standard should remain understandable changes, reproducible checks, and clear ownership after deployment.

Discussion: Which evidence would make an agent-generated change ready for review, and which decisions should remain exclusively with engineers?

5 Fintech Development Companies to Consider: An Engineering View of Banking, Payments, and Lending

Raj — Thu, 10 Sep 2026 05:48:10 +0000

Choosing a fintech development company starts with understanding which part of the financial system needs work.

Building a mortgage application, modernizing banking services, and integrating payment providers require different experience. A company’s financial-services portfolio becomes useful when it explains the systems involved, the responsibilities its engineers owned, and the evidence behind reported outcomes.

This article draws on GeekyAnts’ overview of its banking, fintech, payments, insurance, lending, and wealth management experience, alongside other providers’ published capabilities. It examines five companies through an engineering lens rather than treating company size or client logos as proof of suitability.

What counts as relevant fintech experience?

An engineering team evaluating a partner should first identify its most difficult workflow.

For a payment application, that might be recovering from an uncertain transaction status. For a lending platform, it could be maintaining a consistent application record across document collection and external checks. For an investment product, it might be preventing stale portfolio information from appearing current.

These problems deserve specific evaluation questions:

Product area	Scenario to examine	Evidence to request
Banking	An integration fails during migration	Cutover plan, rollback procedure, dependency map
Payments	A request times out after submission	Duplicate prevention and reconciliation tests
Lending	An external check remains incomplete	Explicit workflow states and exception handling
Insurance	A claim changes after review	Version history and authorization tests
Wealth management	Portfolio data arrives late	Freshness indicators and data reconciliation

This approach makes company comparisons more useful: each candidate must explain how its experience applies to the actual system.

Five companies worth evaluating

The following shortlist uses publicly documented services and project examples. The numbering organizes the discussion; it does not represent an independently verified performance ranking.

1. GeekyAnts: Financial product development and modernization

The source article describes banking service modernization using Go, gRPC, and caching. GeekyAnts reports response times falling from 500 milliseconds to 220 milliseconds in that engagement.

Its examples also include mortgage application work for Sprive, mobile and web frontend development for Bambu, and investment journeys for Elever. The article describes payment integrations and high-volume processing experience, while acknowledging that its public insurance material contains less project-level detail.

These examples make GeekyAnts relevant to a shortlist spanning financial applications and modernization. However, frontend delivery, payment integration, and ownership of core financial logic should remain distinct during evaluation.

Technical question: Which components did the proposed team own, and what production evidence can it share for a comparable assignment?

2. Thoughtworks: Modernization and delivery practices

Thoughtworks’ [financial-services practice] covers banking, payments, insurance, and wealth management. Its published TBC Bank example discusses changes to delivery practices and organizational operations.

That combination suggests relevance when a financial institution’s challenge includes both software architecture and how teams deliver changes.

An evaluation should examine whether the proposed engagement leaves the internal engineering team able to operate and extend the system. A migration can meet its immediate milestone while leaving difficult dependencies unresolved.

Technical question: How will service ownership, release responsibilities, and knowledge transfer work throughout the engagement?

3. EPAM: Banking platforms and wealth applications

EPAM’s [financial-services offering] includes digital banking, wealth management applications, payments, capital markets, and onboarding solutions.

This breadth makes it a candidate for programs that connect several financial domains. A customer-facing application might depend on account services, market data, identity providers, and reporting systems, each with different owners and release schedules.

The evaluation should therefore concentrate on integration boundaries. A proposal needs to explain which systems will change, which contracts will remain stable, and how teams will test compatibility.

Technical question: How will contract testing and staged releases prevent one service change from breaking dependent applications?

4. Endava: Payments integration and orchestration

Endava’s [payments practice] describes work across cards, account-to-account payments, wallets, cross-border transactions, platform modernization, and API integration.

Those published capabilities make it relevant when payment processing and provider coordination form the main engineering challenge.

A useful assessment should follow a transaction beyond the successful checkout screen. It should include delayed callbacks, conflicting provider responses, refunds, and operational investigation.

Technical question: How will the implementation handle an unknown payment outcome without creating an unintended second transaction?

5. Accenture: Broader banking transformation

Accenture’s [banking services]span core modernization, payments, lending, cloud strategy, and banking operations.

That scope suggests relevance for programs involving multiple platforms and business functions. Such engagements need clear coordination between application engineering, infrastructure, operations, and existing technology providers.

Buyers should evaluate the proposed delivery structure as closely as the architecture. Broad capabilities become useful only when responsibility for each production component is explicit.

Technical question: Who will own incident response, release approval, and unresolved integration issues across participating teams?

A payment failure scenario can reveal more than a demo

A simple evaluation exercise can expose important design decisions:

A customer submits a payment. The provider accepts it, but the application times out before receiving confirmation. The customer then retries.

The candidate team should explain:

How the system identifies whether both requests represent the same intended payment.
How it records an uncertain outcome.
How later provider notifications update the transaction.
How support staff investigate discrepancies without directly editing records.
Which tests demonstrate recovery from these conditions.

A retry button alone does not answer those questions. The explanation should connect API behavior, stored state, background processing, and operational tooling.

The same evaluation method can extend to other products: interrupted loan applications, amended claims, or delayed investment data.

Choose against the delivery problem

These five companies offer different starting points for evaluation. Their published material helps identify potentially relevant experience, but a project-specific technical assessment should determine fit.

The strongest evidence is a clear account of comparable work: what the team owned, what failed, how it recovered, and how the client maintained the result afterward.

For developers working on financial systems, which failure scenario has proved most useful when reviewing a proposed architecture?

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.