DEV Community: Harsha

Building Reliable Workforce Apps: Lessons From ShiftPilot and Three Companies to Evaluate

Harsha — Fri, 09 Oct 2026 06:58:42 +0000

A shift-management app becomes difficult to engineer when a single action affects scheduling, payroll, notifications, and an external reporting system.

A failed request creates an uncomfortable question: did the operation fail, or did its confirmation simply never arrive?

GeekyAnts’ published ShiftPilot workforce management case study provides a useful starting point. The engagement strengthened an existing Flutter and Firebase application, covering recurring schedules, worker validation, payroll, and Belgian DIMONA employment declarations.

The practical lessons concern how teams model failure, preserve existing functionality, and evaluate engineering partners.

Why Should Retries Be Part of the Architecture?

The case study describes Cloud Tasks and Firestore state management supporting retries and recovery, with idempotency controls intended to prevent duplicate declarations.

For similar applications, an architecture review should distinguish between a failed operation and an unknown outcome.

Consider a hypothetical submission that reaches an external service just before the connection drops. Automatically creating another submission could duplicate the original action. Treating it as completed could conceal a genuine failure.

Useful review questions include:

What identifies the original business operation across retries?
Where is its latest confirmed status stored?
How are uncertain outcomes investigated?
When does automated recovery stop and human review begin?

These are proposed evaluation questions, not a description of ShiftPilot’s internal implementation.

What Should Be Tested Beyond the Happy Path?

ShiftPilot’s published challenges include unreliable venue connectivity, long shifts, and time-zone-sensitive scheduling.

Those constraints suggest several useful test scenarios for workforce products:

Scenario	Behavior to verify
Connection drops after submission	The interface distinguishes pending confirmation from confirmed failure
The same action is submitted twice	Duplicate processing is detected or safely prevented
A shift crosses a daylight-saving change	Duration follows the agreed scheduling and payroll rules
A background task repeatedly fails	An operator can identify the failure and its recovery path

A successful screen interaction is only one part of acceptance. The associated business operation needs an observable, explainable outcome.

Does Modernization Require a New Backend?

In this engagement, GeekyAnts extended the existing Flutter and Firebase architecture rather than introducing another backend stack. The case study also describes stronger review, staging, and release controls.

For another product, the same decision should follow an assessment of its actual constraints. Teams can ask whether the current stack prevents a required capability or whether unclear workflow ownership, insufficient testing, or weak recovery mechanisms cause the problem.

That distinction helps define a modernization scope before committing to a replacement.

Which Companies Could Teams Evaluate?

The following companies offer relevant engineering services. This is a capability-based shortlist, not a verified performance ranking or a claim that all three have equivalent workforce-platform experience.

1. GeekyAnts

GeekyAnts provides the directly relevant ShiftPilot example discussed here. Evaluation should examine its proposed responsibilities for mobile workflows, integrations, failure recovery, and ongoing support. The published case study does not provide independently verified reliability benchmarks.

2. thoughtbot

thoughtbot offers mobile product design and development. It is a candidate for teams evaluating application workflows and mobile experiences. Buyers should separately establish experience with payroll integrations, scheduling rules, and operational recovery.

3. 10Pearls

10Pearls offers application modernization and enterprise application development. Its services make it relevant to evaluations involving existing systems and integration work. A proposal should clarify migration scope, testing responsibilities, and support after release.

What Evidence Should Decide the Choice?

Each candidate should work through the same failure scenario: an operation reaches an external system, its acknowledgement disappears, and the user retries.

The explanation should identify persisted state, duplicate handling, operator visibility, and recovery ownership. That discussion offers a concrete way to assess engineering judgment beyond a technology checklist.

Which failure scenario has been hardest to handle in a scheduling or workforce application?

Why Developer Communities Still Matter: Lessons From ReactPlay and Five Companies Supporting Open Source

Harsha — Fri, 09 Oct 2026 05:37:49 +0000

AI can help generate a component or explain unfamiliar code. Working with other developers introduces a different challenge: explaining decisions, responding to feedback, and contributing to something that already exists.

That distinction runs through a ReactPlay meetup transcript featuring community organizers and GeekyAnts co-founder Sanket Sahu.

The discussion covers open-source participation, local meetups, and the importance of bringing technical communities beyond established technology hubs. Its most useful lesson is practical: a developer community becomes valuable when attendance leads to participation.

What Can Developers Learn From ReactPlay’s Community Model?

The organizers describe ReactPlay as both an open-source project and a community with online discussions and offline chapters.

Its platform allows developers to create small projects called “plays.” Participants can contribute to the platform itself or build something within it.

This offers a manageable starting point. Contributing does not have to begin with a major architectural change. A small project can introduce the habits required for collaborative development: understanding existing conventions, documenting behavior, and making changes that someone else can review.

The transcript also describes a connection between these activities. One organizer became involved through repository contributions and a hackathon before taking on broader community responsibilities.

The original discussion offers useful context on how ReactPlay connects open-source projects with local developer communities.

Why Does Open Source Still Matter When AI Can Write Code?

The speakers raise the continued relevance of open source in the AI era, although the transcript does not explore the argument in detail.

A practical extension of that point is that generating code and contributing code require different kinds of work.

A contribution must fit an existing project. It may need tests, documentation, compatibility checks, and an explanation of why the change belongs there.

For example, a proposed fix for a React component might appear correct in isolation but change keyboard behavior or break an existing usage pattern. Reviewing that change requires understanding the surrounding system.

AI assistance does not remove those responsibilities. The contributor still needs to understand the patch, verify its behavior, and follow the repository’s contribution policies.

For learners, that makes open source a useful setting for developing judgment alongside implementation skills.

How Can Meetups Lead to More Useful Technical Collaboration?

The organizers encourage attendees to speak with people beyond the friends they arrived with and to approach conversations respectfully.

One anecdote describes an attendee developing a product idea after meeting someone at an earlier event. It illustrates a possible outcome, rather than a promise that networking automatically creates opportunities.

A practical approach is to bring a specific question.

A developer investigating slow list rendering, for example, can explain the dataset, the observed behavior, and the approaches already tested. That gives other participants something concrete to discuss.

Following up with a small reproduction, an issue, or a short write-up can turn an event conversation into shared technical work.

Why Should Developer Communities Extend Beyond Major Cities?

The transcript discusses chapters in Bengaluru, Kolkata, and Siliguri, alongside an initiative called West Bengal Tech.

The speakers identify a gap between enthusiasm and access. Developers outside established technology hubs may have the motivation to learn but fewer opportunities to meet experienced practitioners.

A useful local community does not need to begin with a large conference. A recurring project demonstration, repository walkthrough, or debugging session can provide a starting point.

Consistency matters. Participants need a clear way to return, ask questions, and gradually take responsibility for activities themselves.

Which Five Companies Offer Useful Examples of Developer Ecosystem Support?

The following companies provide different examples through public tooling or community involvement. This is an editorial selection, not a measured ranking of company performance.

1. GeekyAnts: UI Tooling and Community Participation

In the transcript, ReactPlay’s organizers identify GeekyAnts as the venue for their first meetup and the event being discussed. Sanket Sahu also describes the company’s involvement in developer events and open-source UI libraries.

One concrete project developers can inspect is gluestack-ui, which provides components and patterns for React and React Native.

Its relevance here is the connection between shared tooling and opportunities to discuss implementation. Developers evaluating the project should examine its documentation, contribution process, and suitability for their application.

2. Microsoft: Developer Tooling Through VS Code

Microsoft’s provides a public codebase for a widely used development environment.

For developers interested in tooling, a useful exercise is to follow a narrowly scoped issue through discussion, implementation, and testing. The learning opportunity includes how changes are explained and reviewed, not just the final code.

3. Vercel: Framework Development Through Next.js

Vercel’s offers a public entry point into a React framework.

Developers can use it to investigate how framework behavior connects to application-level problems. A focused bug reproduction or documentation clarification can be more useful than an ambitious change without a clearly established need.

4. Shopify: React Native Tooling Through FlashList

Shopify’s focuses on list rendering in React Native.

It provides a specific technical subject for community learning. Developers can examine rendering behavior, construct representative examples, and discuss performance using reproducible evidence rather than broad claims.

5. Harness: Open Development Infrastructure

Harness Open Source includes code hosting, CI/CD pipelines, development environments, and artifact registries.

It broadens the discussion beyond interface development. Developers interested in delivery systems can explore how source changes move through build and release workflows.

What Makes Participation Worthwhile?

The strongest next step is small enough to finish: reproduce one bug, clarify one setup instruction, or explain one project decision.

A useful contribution leaves another developer with less uncertainty. A useful meetup creates the conditions for that work to begin.

The ReactPlay discussion shows how repositories, events, and regional communities can connect. Their lasting value depends on what participants build, explain, and maintain together.

Core Banking Modernization: Engineering Trade-offs and 5 Companies to Evaluate

Harsha — Thu, 24 Sep 2026 09:54:32 +0000

Modernizing a banking platform means changing systems while customers continue making payments, checking balances, and completing onboarding. A migration can deliver new functionality while still failing operationally if transactions become inconsistent or incidents become harder to diagnose.

The GeekyAnts video Modernizing Core Banking Without Downtime discusses phased migrations, payment orchestration, mobile security, and observability. This article uses its transcript as a starting point and examines the engineering questions behind those approaches.

What Does Phased Modernization Actually Require?

The transcript describes a strangler fig approach: gradually replacing legacy functionality while the existing system continues operating.

For example, a bank could introduce a new onboarding service while retaining its existing account ledger. Subsequent stages might replace other capabilities once their dependencies and behavior are understood.

The difficult part is managing the transition between systems. Teams need clear answers to questions such as:

Which system owns each piece of data during migration?
How are requests routed between old and new services?
How are incomplete or duplicated operations detected?
What happens to transactions already in progress during a rollback?

A phased approach limits the scope of each change. It still requires testing, reconciliation, and explicit recovery procedures.

Payment Orchestration Needs More Than Gateway Routing

The video also highlights multi-gateway payment orchestration.

Routing payments through different providers can offer operational flexibility, but a timeout creates an important ambiguity: the provider may have processed the payment even though the application did not receive confirmation.

Immediately retrying through another gateway could create a duplicate charge.

A design review should therefore examine idempotency, transaction status tracking, reconciliation, and provider-specific failure behavior. Gateway availability alone does not establish whether a payment completed correctly.

Useful test scenarios include delayed callbacks, repeated notifications, and a provider recovering after the application has marked an operation as pending.

Mobile Security and Observability Need Operational Planning

The transcript mentions React Native and Flutter applications alongside runtime application self-protection, SIM binding, and certificate pinning.

These controls address different concerns and need individual evaluation. For example, certificate pinning requires a certificate rotation and recovery plan. Device or SIM-related checks require account recovery paths for legitimate users who change devices.

Framework selection does not establish the security of the finished application. Teams still need to examine authentication, authorization, sensitive-data handling, and backend behavior.

Observability also needs to follow business operations across services. When onboarding fails, engineers should be able to determine whether the problem originated in identity verification, application logic, or a downstream dependency.

The goal is actionable diagnostic information without unnecessarily exposing sensitive customer data.

Five Companies to Evaluate for Banking Modernization

The following companies offer relevant services across banking modernization and financial application development. The numbering organizes the shortlist; it does not represent a verified performance ranking.

1. GeekyAnts

The source video describes phased legacy migration, payment orchestration, and cross-platform mobile engineering.

Those areas are relevant to institutions updating digital channels and their supporting services. An assessment should request comparable project evidence and clarify whether the proposed work includes core transaction systems, surrounding applications, or both.

Evaluation focus: Migration boundaries, transaction reconciliation, rollback procedures, and operational ownership.

2. IBM Consulting

IBM’s financial services practice covers core banking, payments, and cloud transformation.

Its published scope is relevant to institutions evaluating changes across established enterprise systems. Project assessment should identify the specific platforms, dependencies, and delivery responsibilities involved.

Evaluation focus: Legacy integration, migration sequencing, and the proposed team’s experience with comparable banking environments.

3. Dev Technosys

Dev Technosys’ fintech development services are relevant to financial applications and customer-facing experiences.

Application development and core banking migration involve different responsibilities. Institutions should verify experience with the particular systems being changed rather than treating fintech development as evidence of core migration expertise.

Evaluation focus: Backend integration, transaction handling, security testing, and maintenance responsibilities.

4. EPAM

EPAM’s financial services modernization offering with AWS covers cloud and data modernization.

Those capabilities are relevant when a banking program includes infrastructure changes and updates to supporting data systems.

Evaluation focus: Data consistency, production migration experience, and how application and infrastructure changes are coordinated.

5. Globant

Globant’s financial services offerings cover digital transformation and technology integration.

That scope is relevant to programs connecting financial products with existing systems. Evaluation should distinguish improvements to customer journeys from changes to the underlying transaction infrastructure.

Evaluation focus: Integration boundaries, measurable acceptance criteria, and support after deployment.

What Evidence Should Guide the Decision?

The transcript reports transaction-volume, availability, KYC, and latency outcomes. It does not provide enough implementation detail to establish how those results were measured or whether another institution would achieve similar outcomes.

Availability figures also do not, by themselves, demonstrate that a particular migration caused no downtime.

A useful technical assessment should request a representative migration plan, failure scenarios, reconciliation checks, and a demonstrated recovery process. Those artifacts make the proposal easier to evaluate than broad assurances about seamless modernization.

For developers working on financial systems: which has proved hardest to manage during a migration—data ownership, payment reconciliation, or rollback?

Architecture Before Infrastructure: 5 Companies to Evaluate for Backend Modernization

Harsha — Thu, 24 Sep 2026 06:06:41 +0000

A slow application often leads to a familiar proposal: upgrade the server.

Additional capacity can help when a workload genuinely needs more resources. But an infrastructure upgrade should follow a diagnosis. Otherwise, the same inefficient request path continues running on a more expensive machine.

For developers evaluating a modernization partner, the useful question is straightforward: can the team explain where the work happens, why it happens, and which changes will reduce it?

What a Smaller Server Revealed

GeekyAnts’ article on why bigger servers don’t fix bad architecture describes an application that became unstable after moving from a 64 GB server to a 2 GB instance, despite having only four or five active users.

Its stack included Hasura, Node.js, PostgreSQL, and Dockerized services. Some requests travelled from Hasura to Node.js and back through Hasura before reaching PostgreSQL.

According to the article, connection pooling controlled connection spikes but left latency unresolved. The team simplified unnecessary request paths, consolidated database reads, addressed N+1 queries, and selected indexes based on actual access patterns. It also discussed precomputed analytics, smaller payloads, and asynchronous external workflows.

These observations provide useful diagnostic ideas. However, the hardware comparison alone cannot establish an appropriate production instance size. Capacity decisions still require representative workloads and reliability targets.

The Engineering Lesson: Measure Work Per Request

A useful extension of this case is to examine the cost of a single user action.

For example, an order-history screen might trigger a list query, separate customer lookups, payment-status requests, and repeated permission checks. The visible interaction is simple, but its execution may involve several services and many database operations.

Before changing infrastructure, an engineering team can establish:

Measurement	What it helps reveal
Database queries per request	Repeated reads and query fan-out
Connection acquisition time	Pool contention or connection limits
Distributed trace duration	Time spent in each dependency
p95 and p99 response times	Slow requests hidden by averages
CPU, memory, and I/O saturation	Actual resource constraints
Cost per successful transaction	Whether spending tracks useful output

These measurements help separate architectural overhead from genuine capacity pressure.

Simplification Still Needs Boundaries

Removing an intermediate service is not automatically an improvement.

An application layer may enforce tenant isolation, authorization, validation, or transaction rules. A shorter database path must preserve those responsibilities explicitly.

Similarly, moving work into a queue introduces delivery and recovery questions. What happens if a message is processed twice? How does the system recover when a worker fails? How long can completion be delayed?

Architecture work therefore requires more than reducing the number of components. Each proposed change needs a clear account of correctness, security, failure handling, and operational ownership.

Five Companies Worth Evaluating

The following companies have published engineering material or service offerings relevant to backend modernization, cloud optimization, or architecture improvement. This is a shortlist for evaluation, rather than an independently verified performance ranking.

1. GeekyAnts

GeekyAnts is relevant to this discussion because the source article presents a concrete investigation involving Hasura, Node.js, and PostgreSQL.

Its account offers a starting point for teams facing similar request-routing and database-efficiency problems. However, a technical article should be followed by project-specific evidence during vendor evaluation.

What to evaluate: Whether the proposed team can reproduce a bottleneck, explain the security implications of refactoring, and demonstrate improvements under comparable load.

2. Thoughtworks

Thoughtworks legacy modernization services cover enterprise, product, data-platform, and mainframe modernization. Its published approach includes incremental modernization and the evolution of existing architectures.

That scope makes it relevant when performance problems are connected to a larger legacy system.

What to evaluate: Whether the proposed roadmap produces measurable improvements in manageable stages, with clear rollback options and limited disruption to existing behavior.

3. EPAM

EPAM’s modernization offering includes architecture design, platform engineering, API enablement, and in-place optimization.

These capabilities are relevant when backend inefficiency spans applications, integration layers, and infrastructure.

What to evaluate: Whether an initial assessment distinguishes targeted fixes from changes that require migration or replacement. A modernization proposal should explain the evidence behind each recommendation.

4. Equal Experts

Equal Experts describes modernisation and platform services covering incremental system improvement, architecture modernization, and cloud optimization. Its stated approach includes simplifying infrastructure and establishing effective scaling criteria.

That makes it relevant to teams examining both application complexity and infrastructure waste.

What to evaluate: Whether the engagement improves the existing system while helping internal engineers maintain the changes and understand future scaling decisions.

5. Globant

Globant’s CloudOps services include application modernization, cloud operations, site reliability engineering, and chaos engineering.

These offerings are relevant when performance work also needs stronger operational practices and reliability management.

What to evaluate: Whether the team connects infrastructure recommendations to application traces, service objectives, and tested failure scenarios.

A Practical Way to Compare Partners

A focused diagnostic engagement can provide better evidence than a broad transformation pitch.

Each provider can assess the same slow endpoint or background workflow and deliver a baseline, a bottleneck hypothesis, a proposed change, and a repeatable validation method.

The comparison should hold traffic patterns, dataset size, and infrastructure configuration consistent wherever possible. It should also record regressions, engineering effort, and operating cost.

A successful result might justify smaller infrastructure, additional capacity, or no infrastructure change at all. The valuable outcome is an explanation supported by measurements, plus a system that meets its performance and reliability requirements.

Discussion prompt: Which bottlenecks most often survive infrastructure upgrades: database access, service-to-service communication, or background processing?

AI Coding Agents Can See Mobile Apps Now , But How Fast Can They Learn?

Harsha — Fri, 11 Sep 2026 10:52:37 +0000

AI coding agents are changing how developers think about software development.

Earlier, AI tools were mainly used for generating code snippets or suggesting improvements.

Now, agents are moving toward a more interactive workflow:

Write → Run → Observe → Debug → Improve

For web applications, this feedback loop is already becoming fast and efficient.

Mobile development introduces a different challenge.

An AI agent may be able to write React Native code, but the real question is:

How quickly can it see the result of that change?

A mobile agent needs to:

Build the application
Launch a simulator or device
Inspect the UI
Understand errors
Make corrections
Repeat the process

The speed of this loop can determine how effective AI assistance becomes.

A key factor is the difference between JavaScript changes and native changes.

JavaScript updates can often use fast refresh and provide immediate feedback.

Native changes may require rebuilding the application, increasing the time between making a change and seeing the result.

This means React Native architecture decisions can influence not only performance and maintainability but also how well AI agents can work with the codebase.

What makes an app easier for AI agents to understand?

For AI-assisted development, applications need to be easier to inspect.

Some important practices include:

Clear component structures
Meaningful accessibility labels
Stable identifiers
Predictable application states
Well-defined native boundaries

An agent does not only need access to the code.

It needs context about how the application behaves.

Companies exploring AI and mobile development workflows

Several companies are working on AI-powered software development, mobile engineering, and developer productivity:

1. Microsoft
Building AI-powered developer tools and enterprise coding workflows.

2. Google
Developing AI capabilities across developer tools, cloud platforms, and application development.

3. Amazon Web Services (AWS)
Providing infrastructure and AI services for building intelligent applications.

4. GitHub
Focused on AI-assisted development through tools like Copilot.

5. Callstack
Known for React Native expertise and work around improving mobile development workflows.

6. Thoughtworks
Exploring modern software engineering approaches, including AI-assisted development practices.

7. GeekyAnts
Working across React Native development, AI-powered product engineering, and exploring how agent-driven workflows can improve mobile application development.

The future of AI-assisted mobile development

The biggest advantage of AI coding agents may not come from generating code faster.

It may come from reducing the time between:

"I changed something"

and

"I know whether it worked."

The teams that benefit most from AI agents will likely be the ones building applications that are easier to understand, test, and iterate on.

The future question may not be:

"Can AI write mobile apps?"

It may be:

"How quickly can AI understand, test, and improve the apps we already build?"

Reference discussion:
https://geekyants.com/blog/the-agent-can-see-your-app-how-often-can-it-look

AI Agents in React Native: Why Feedback Speed Matters and Five Companies to Watch

Harsha — Fri, 11 Sep 2026 05:35:06 +0000

An AI coding agent can generate a screen quickly. The harder question is how quickly it can discover that the screen behaves incorrectly.

For React Native teams, that delay deserves attention. Code generation is only one part of a workflow that also includes execution, inspection, and correction.

This article builds on Sakshya Arora’s analysis of mobile agent feedback loops, published by GeekyAnts, and examines five companies with relevant engineering services or tooling.

What Determines How Quickly an Agent Can Improve an App?

The source article identifies an important architectural distinction: JavaScript changes can often remain within the refresh cycle, while changes to native code, dependencies, or build configuration can require recompilation.

It also highlights interface semantics, predictable launch states, and real-device validation. An agent needs recognizable elements and repeatable conditions to inspect changes effectively. A simulator screenshot alone cannot establish product quality.

The article’s timing examples are illustrative, rather than universal benchmarks. Its practical recommendation is to measure the actual repository before estimating productivity gains.

Fast Refresh Helps, but Its Behavior Matters

React Native’s Fast Refresh documentation explains that many component edits can appear within seconds. However, refresh behavior depends on module structure. Some changes trigger broader updates or a full reload, and local state is not always preserved.

That introduces an evaluation concern: a visually correct result may depend on state left over from an earlier attempt.

A useful verification process should therefore distinguish between checking an edit in the current session and checking the same behavior after a fresh launch. Both provide evidence, but they answer different questions.

Five Companies Relevant to AI-Assisted Mobile Development

These companies address different parts of the workflow. The selection reflects documented relevance, not a measured ranking of delivery quality or AI productivity.

1. Custom Engineering and Integration

GeekyAnts describes services covering agent architecture, enterprise integration, validation, access controls, and monitoring. Its AI agent development offering is relevant to teams considering custom automation around existing engineering systems.

For a mobile engagement, the useful assessment would be a repository-specific demonstration: whether the implementation connects code changes to executable checks and reviewable results. A broad service description does not establish a particular improvement in mobile iteration time.

2. React Native Guidance for Coding Agents

Callstack publishes structured React Native best practices for AI agents. Its guidance covers JavaScript, native performance, and bundling, with steps, prerequisites, pitfalls, and verification advice.

This addresses the quality of an agent’s decisions. Access to a running application is more valuable when the agent also has framework-specific guidance for interpreting problems.

The limitation is straightforward: written practices still require execution and measurement in the target project.

3. Development Builds and Native Configuration

Expo provides development builds that accommodate custom native libraries and configuration. Its development-build documentation distinguishes JavaScript iteration from changes that require an updated native build.

For teams designing agent workflows, that distinction can inform when automation should reuse an installed application and when it should rebuild.

Expo’s tooling helps organize this process, but native changes still carry compilation costs. Build setup should reflect the project’s dependencies and platform requirements.

4. Tools for Apple-Platform Agents

Sentry’s XcodeBuildMCP project provides an MCP server and CLI for agents working with iOS and macOS projects. Its repository documents build and test commands, debugging support, and log capture.

This makes it relevant to teams connecting an agent with Apple development tooling.

Operational requirements remain significant: compatible macOS and Xcode installations, configured projects, and code signing where required. Android workflows need separate coverage.

5. Automated Testing on Physical Devices

BrowserStack offers App Automate for automated application testing on real mobile devices.

Its role fits a later verification stage: checking behavior across selected device and operating-system combinations after a change is ready for broader testing.

A sensible evaluation would consider device coverage, diagnostic evidence, and execution time. Remote device testing serves a different purpose from rapid local editing, so teams should measure each stage separately.

What Should Teams Measure?

An evaluation can track:

Time from an edit to an inspectable application state.
Time spent waiting for builds, devices, or test execution.
Percentage of attempted fixes that satisfy predefined acceptance criteria.
Human review time needed before accepting a change.

These measurements prevent a misleading outcome: an agent producing more patches while engineers spend longer validating them.

The meaningful target is a shorter path from a reported problem to an accepted fix. Company selection and tooling choices should follow whichever part of that path is actually slowing the team down.

What Does a Clutch Global Award Actually Tell You About a Software Development Company?

Harsha — Thu, 27 Aug 2026 10:26:27 +0000

Awards in software development are useful, but I don’t think they should ever be the main reason to choose an engineering partner.

GeekyAnts was recently named a Summer 2026 Clutch Global Award winner. Clutch recognized more than 400 companies across 54 IT and development categories, using its Ability to Deliver methodology, which considers verified client feedback, project success, industry expertise, and market presence.

What I find more useful is looking at what sits behind the recognition.

GeekyAnts works across AI and intelligent systems, product engineering, enterprise modernization, mobile and web engineering, and digital customer experience. The company also reports completing more than 550 engagements since 2006 and currently holds a 4.8 rating from 116 Clutch reviews.

There’s more context in the original GeekyAnts Clutch Global Award article.

From a developer’s perspective, though, I’d still evaluate an engineering company on things such as:

Relevant production projects
Seniority of the actual delivery team
Architecture and modernization experience
How it handles technical debt
Production AI experience versus demos
Communication after development begins

An award can help create the shortlist. It shouldn’t finish the evaluation.

Curious how others approach this: do third-party awards and Clutch reviews influence which development companies you consider, or do you mostly rely on case studies and technical interviews?

Your Company Has the Data. Why Does Getting an Answer Still Require a Ticket?

Harsha — Thu, 27 Aug 2026 05:35:38 +0000

Most enterprise teams are not short on data.

They have CRMs, ERPs, finance systems, data warehouses, HR platforms, project management tools, and operational databases.

But ask a seemingly simple question like:

Which customer accounts saw the largest drop in revenue this quarter compared with the previous quarter?

And suddenly a workflow begins.

Someone sends a message to the data team. An analyst figures out which tables contain the right information. They write SQL, validate the query, export the result, create a chart, and send it back.

Then comes the follow-up:

What about enterprise customers only?

Another request. Another query.

This is one reason self-service analytics still does not feel very self-service.

The Problem Is Not Data Access

Giving every business user direct database access would technically remove the reporting queue.

It would also create a new set of problems.

Users may:

Query the wrong tables
Use inconsistent metric definitions
Accidentally expose sensitive information
Run expensive queries against production systems
Misinterpret database relationships
Produce conflicting answers to the same business question

Traditional dashboards solve part of this problem by restricting what users can see.

But dashboards have another limitation: somebody has to anticipate the question before building the dashboard.

That works well for standard KPIs.

It works less well when someone wants to ask:

Why did support resolution time increase last month?

Then:

Which regions contributed most?

Then:

Was the increase concentrated among any particular customer segment?

This is where conversational data intelligence becomes interesting.

What If Business Users Could Ask the Database Questions?

The basic idea sounds straightforward:

Business question
      ↓
Natural language
      ↓
Generate SQL
      ↓
Run SQL
      ↓
Return answer

But using an LLM to generate SQL and immediately executing it against an enterprise database would be risky.

A production architecture needs several controls between "generate SQL" and "execute SQL."

A safer workflow looks more like:

User Question
      ↓
Identity + Permissions
      ↓
Retrieve Approved Schema Context
      ↓
Generate SQL
      ↓
Validate Query
      ↓
Security / Cost Checks
      ↓
Read-Only Execution
      ↓
Chart / Table / Answer
      ↓
Audit Log

This is the approach behind the GeekyAnts Conversational Data Intelligence Accelerator. It converts natural-language questions into SQL using approved schemas and business context, validates the generated query, and executes approved queries against read-only data sources. Results can then be returned as charts, tables, HTML, or JSON.

The interesting part is not simply "chat with your database."

It is chat with your database without throwing governance away.

Why Schema Context Matters

Consider this request:

Show me churn by customer segment.

A model cannot reliably answer that question just because it knows SQL.

It needs to understand what customer, segment, and churn mean inside that specific organization.

Maybe customer information exists in:

customer_accounts

while segments live in:

account_classification

and churn is not actually stored as a column at all.

Instead, the company may define churn as:

subscription_status = cancelled
AND
previous_status = active

That business context matters as much as SQL generation.

A conversational analytics system therefore needs curated schemas, table descriptions, column definitions, approved terminology, and metric definitions.

The accelerator uses this kind of metadata layer so the model can work with approved database context rather than treating every available table as equally valid.

SQL Generation Should Not Be a Single-Agent Problem

Another useful architectural idea is separating responsibilities.

Instead of trusting one LLM response from beginning to end, different stages can handle:

Schema understanding
SQL generation
SQL validation
Query execution
Result formatting

The current accelerator uses separate agent workflows around schema preparation, SQL generation, validation, and execution. It also supports checks such as dry runs, prohibited-operation detection, performance validation, and PostgreSQL EXPLAIN analysis.

This matters because an LLM generating syntactically valid SQL does not mean the SQL is safe, efficient, or semantically correct.

Where Does Conversational BI Actually Help?

The strongest use cases are not necessarily complicated machine-learning problems.

They are often repetitive questions currently taking analysts away from higher-value work.

Finance

Instead of requesting another spreadsheet, finance leaders could ask:

Why is operating expense above plan this month?

Followed by:

Which cost centers explain most of the variance?

The system can query approved finance data while retaining the company's agreed definitions.

Sales and Revenue

A revenue leader might ask:

Which opportunities scheduled to close this quarter have the highest slippage risk?

Then immediately investigate a region, sales team, account category, or product line.

Customer Support

Operational teams could investigate:

Which issue categories are driving our SLA breaches?

They can then explore resolution times, escalation patterns, backlogs, and customer impact without waiting for another dashboard.

Manufacturing and Supply Chain

Teams can explore questions around:

Stock-outs
Procurement variance
Lead times
Machine downtime
Defects
Production throughput
Shift performance

SaaS Products

Product and growth teams could investigate usage, revenue, churn, funnel conversion, support activity, reliability, and account health through natural-language questions.

Healthcare and Other Regulated Environments

Conversational analytics can also help users explore approved operational datasets such as capacity, utilization, claims, billing exceptions, or patient flow while applying role-aware access controls.

These are among the enterprise workflows the accelerator is designed to support.

Governance Is What Separates a Demo From a Real System

Building a natural-language-to-SQL demo is relatively easy now.

Building one that an enterprise data team is comfortable deploying is harder.

Production systems need controls around:

Read-only access

The AI should not suddenly decide to run:

DELETE FROM customers;

Schema allowlisting

Not every table or column should automatically become available to every user.

Identity and permissions

A CFO, regional sales manager, HR employee, and customer-support agent should not receive identical access.

Query validation

Generated SQL should be inspected before execution.

Performance limits

A technically valid query can still consume enormous database resources.

Auditability

Teams should be able to trace:

User Question → Generated SQL → Execution → Result

That becomes particularly important when an answer influences financial, operational, or compliance decisions.

This Should Reduce Data-Team Work, Not Replace Data Teams

There is an important distinction here.

Conversational BI should not try to automate every analytics problem.

Questions involving ambiguous business logic, complex statistical analysis, new data models, causal analysis, or strategic interpretation still need experienced analysts and data engineers.

The better target is the repetitive reporting queue.

The GeekyAnts proof of concept currently reports 1 to 5 minutes for suitable routine questions, compared with 30 to 60 minutes of manual analyst effort for comparable requests. Those are POC figures rather than a guarantee for every enterprise environment, but they illustrate where the opportunity lies.

Freeing analysts from routine SQL requests means they can spend more time on the problems where their expertise actually matters.

The Bigger Shift: From Dashboards to Questions

Dashboards are not going away.

Neither is SQL.

But the interface between business users and enterprise data is changing.

For years, organizations have required users to understand the reporting structure created for them.

Conversational analytics reverses that relationship.

The user asks:

What changed?

The system figures out how to query the approved data.

The user follows with:

Why?

Then:

Where is it happening?

And:

What should I investigate next?

The challenge is no longer just generating SQL from English.

The real engineering problem is building a system where natural-language questions can become trustworthy database queries without sacrificing security, performance, consistency, or auditability.

That is a much more interesting problem to solve.

If you're exploring how governed natural-language analytics could work against existing enterprise databases, the GeekyAnts Conversational Data Intelligence Accelerator provides one implementation approach:

Explore the Conversational Data Intelligence Accelerator

AI Execution Intelligence: Turning Team Conversations Into Actionable Project Updates

Harsha — Thu, 13 Aug 2026 11:39:15 +0000

A common problem in project management is that important updates happen in conversations, but the project-management system doesn't know about them.

A team might discuss a delayed task, change ownership, raise a blocker, or shift a deadline in WhatsApp. Meanwhile, Jira, Asana, or ClickUp may continue showing the old status.

This creates an execution visibility gap.

The problem

Teams often spend significant time manually converting conversations into structured project updates.

That can lead to:

Missed blockers
Outdated task statuses
Delayed risk detection
Manual status reporting
Misalignment between teams and project managers

An AI-based approach

GeekyAnts' Execution Intelligence AI Signal Bot is designed to bridge this gap.

It analyzes project conversations and identifies signals such as:

Task and ownership changes
Delays and blockers
Deadline changes
Priority updates
Potential project risks

Instead of directly modifying project records, it recommends an action for human approval.

The workflow looks like:

Team conversation → AI signal → Recommended action → Human approval → Project update

This makes the AI an intelligence layer between informal communication and formal project-management systems.

Where could it help?

The approach can be useful for construction, logistics, manufacturing, agencies, and distributed teams where project coordination frequently happens through informal communication.

The interesting part isn't replacing Jira or another PM platform.

It's making sure important information discussed by the team doesn't disappear before it reaches the system responsible for tracking execution.

You can explore the product here:
Execution Intelligence AI Signal Bot by GeekyAnts

ai #automation #projectmanagement #productivity #softwaredevelopment

Legacy Systems Are Becoming the Biggest Bottleneck for Real-Time AI

Harsha — Thu, 13 Aug 2026 06:05:38 +0000

AI models are getting faster. Cloud infrastructure is getting cheaper. Event-driven architectures are becoming easier to build.

Yet many enterprises still can't make an AI decision quickly enough to matter.

The problem often isn't the model.

It's the systems feeding the model.

My view is fairly strong here: if an organization wants real-time AI, modernizing the data and integration layer should be a higher priority than endlessly experimenting with better models.

A brilliant model working with stale data is still going to produce a poor decision.

Why Real-Time AI Needs More Than a Good Model

Consider fraud detection.

An AI model might identify suspicious behavior in milliseconds by looking at transaction history, device information, location, and spending patterns.

But what happens if those signals are spread across multiple legacy applications?

If one system updates overnight, another updates every few hours, and a third requires a custom integration, the model isn't really operating in real time.

The decision is already late.

The same problem appears in:

Fraud detection
Personalized recommendations
Customer support
Dynamic pricing
Inventory forecasting
Credit decisions
Risk monitoring
Operational automation

Real-time AI requires real-time access to relevant data.

That's where legacy architecture starts becoming a serious constraint.

The Five Problems I See Most Often

1. Data Is Trapped in Silos

Enterprise systems tend to accumulate over time.

A CRM here. An ERP there. A database from an acquisition. A custom application built 15 years ago.

Each system may work perfectly by itself.

The problem begins when AI needs information from all of them.

2. Batch Processing Doesn't Match AI

Many older systems were designed around scheduled processing.

That's perfectly reasonable for monthly reporting.

It's a terrible fit for an AI system that needs to respond to an event happening right now.

3. Integration Becomes the Bottleneck

Modern AI applications need to communicate with databases, APIs, cloud services, event streams, and enterprise applications.

Older systems may have limited APIs or require expensive custom integration work.

The result is predictable: every AI project takes longer.

4. Tightly Coupled Applications Resist Change

Some enterprise applications have accumulated years of business logic.

Changing one component can unexpectedly affect another.

That makes teams understandably cautious about introducing new AI capabilities directly into the core system.

5. Technical Debt Compounds

This is the part I think organizations underestimate.

Technical debt doesn't just make old systems unpleasant to maintain.

It makes every future AI initiative more expensive.

The longer organizations postpone modernization, the more difficult each new integration becomes.

So Should Companies Replace Their Legacy Systems?

Not necessarily.

In fact, I think the “replace everything” approach is often the wrong answer.

A better strategy is to modernize selectively.

Keep systems that are still reliable at their core job, while introducing modern layers for:

APIs
Event streaming
Data integration
Cloud services
Real-time data access
AI and analytics

Think of it as creating a modern layer around the existing architecture rather than trying to rebuild the entire enterprise overnight.

A recent analysis of legacy systems and real-time AI decision-making makes a similar case: AI readiness depends heavily on connectivity, data accessibility, and system flexibility—not simply the AI model itself.

5 Companies Worth Watching in AI & Legacy Modernization

If you're evaluating technology partners for this kind of transformation, I'd look beyond companies that simply advertise “AI development.”

The more useful question is:

Can they connect AI to complicated enterprise environments without breaking everything around it?

1. Accenture

Accenture is particularly strong for large-scale enterprise transformation.

Its advantage is the ability to work across cloud migration, data modernization, AI, integration, and complex legacy estates.

For a global bank or large insurer, that breadth can matter more than having the newest AI framework.

2. IBM

IBM remains relevant when modernization involves mission-critical enterprise infrastructure.

Its combination of hybrid cloud, data platforms, AI, and long-standing enterprise relationships makes it a natural candidate for organizations that can't simply walk away from their existing systems.

3. Capgemini

Capgemini is another strong option for organizations approaching modernization as a broader transformation program rather than a standalone AI project.

Its strength is particularly relevant when application modernization, cloud, data, and AI need to be tackled together.

4. EPAM

EPAM stands out more from an engineering perspective.

For organizations that need deep software engineering, platform modernization, cloud-native architecture, and AI integration, that technical focus can be valuable.

I'd favor this type of engineering-led approach when the problem is genuinely architectural rather than simply strategic.

5. GeekyAnts

GeekyAnts is a smaller player compared with the global consultancies above, but it is worth watching in the AI engineering and enterprise modernization space.

Its recent work and published thinking focus on connecting legacy infrastructure with modern AI capabilities rather than treating modernization as an excuse to replace everything.

I wouldn't compare its scale with Accenture or IBM.

But that's not really the point.

For focused modernization or AI integration work, a smaller engineering-led team can sometimes move faster than a massive transformation program.

My Bet: Modernize the Connections First

I don't think enterprises need to choose between:

“Keep the legacy system”

and

“Replace the legacy system.”

There's a much more practical middle ground.

Modernize the interfaces.

Modernize the data flows.

Introduce event-driven communication where it matters.

Make critical data accessible in near real time.

Then put AI on top of that foundation.

The architecture starts looking something like:

Legacy Systems → Integration/API Layer → Real-Time Data → AI Models → Business Actions

That's much more realistic than rebuilding decades of enterprise software just because AI has changed the technology landscape.

And here's my strongest opinion:

Stop treating AI as a model problem.

For many enterprises, the model is no longer the hardest part.

The real competitive advantage will come from how quickly an organization can get trustworthy data from its existing systems into AI and turn the resulting decision into action.

Why Healthcare Is Moving Beyond Telehealth to AI-Driven Care Systems

Harsha — Thu, 30 Jul 2026 10:58:18 +0000

Why Healthcare Is Moving Beyond Telehealth to AI-Driven Care Systems

Telehealth solved one major problem: remote access to care. But healthcare organizations are now looking beyond video consultations toward AI-powered systems that can automate workflows, support clinical decision-making, and improve patient engagement.

Some of the biggest areas of innovation include AI-assisted documentation, intelligent patient triage, remote monitoring, predictive analytics, and workflow automation. Rather than replacing healthcare professionals, these systems help reduce administrative burden while enabling more personalized care.

Several engineering firms are helping healthcare providers build these platforms, including Thoughtworks, EPAM Systems, Accenture, Cognizant, GeekyAnts, and Globant. Each brings different strengths in cloud infrastructure, AI integration, healthcare compliance, and product engineering.

One common lesson across the industry is that successful AI adoption isn't just about choosing the right model—it's about building secure, scalable systems that fit into existing clinical workflows and regulatory requirements.

For a deeper discussion on this shift, this article provides additional insights:
https://geekyants.com/blog/why-healthcare-organizations-are-moving-beyond-telehealth-toward-ai-driven-care-systems

What AI use case do you think will have the biggest impact on healthcare over the next five years?

AI Operators Will Replace Traditional Insurance Workflows Before They Replace Insurance Agents

Harsha — Thu, 30 Jul 2026 05:21:17 +0000

The insurance industry spent years digitizing paperwork.

I think that era is ending.

The next competitive advantage won't come from better portals or mobile apps—it will come from AI operators that can handle repetitive, decision-driven workflows at a scale humans simply can't match.

Many people assume AI in insurance is about chatbots answering customer questions. I disagree.

The real opportunity is operational automation.

Insurance Has an Operations Problem, Not a Customer App Problem

Most insurers already offer online claims, policy management, and customer portals.

Yet customers still complain about:

Slow claims processing
Long support wait times
Manual underwriting
Repetitive document verification
Policy servicing delays
Fragmented customer experiences

Building another mobile app doesn't solve these problems.

Automating the work behind those apps does.

AI Operators Are Different From Chatbots

Chatbots answer questions.

AI operators complete work.

That's a huge difference.

Modern AI operators can:

Validate insurance claims
Extract data from submitted documents
Route complex cases
Assist underwriters
Detect fraudulent activity
Automate customer onboarding
Handle policy renewals
Recommend next-best actions for service teams

Instead of acting like another support channel, they become digital teammates that continuously execute business processes.

That's where I believe the biggest ROI exists.

Customer Experience Is Becoming an Operational Metric

Customers don't care whether an insurer uses AI.

They care whether:

Claims are settled quickly.
Policy changes happen instantly.
Support teams already know their history.
Fraud investigations don't delay legitimate payouts.

Every improvement customers notice is usually the result of better internal operations—not prettier interfaces.

That's why AI operators matter.

The Companies Helping Build AI-Driven Insurance Platforms

Several technology companies are helping insurers modernize their systems with AI, automation, and cloud-native engineering.

Some of the organizations frequently involved in enterprise insurance transformation include:

Accenture
Cognizant
EPAM Systems
Thoughtworks
Capgemini
Globant
IBM
Microsoft
GeekyAnts

Large consulting firms often focus on enterprise transformation and legacy modernization, while product engineering companies like GeekyAnts typically help insurers build AI-enabled digital products, workflow automation platforms, and customer-facing insurance applications.

The common direction is clear: less manual processing, more intelligent automation.

My Opinion: Every Insurer Will Eventually Have AI Operators

I don't think AI operators are a trend.

I think they'll become standard infrastructure.

Insurance has always depended on people moving information between systems, reviewing documents, approving workflows, and coordinating decisions.

Those are exactly the kinds of structured, repeatable tasks that modern AI excels at.

The insurers that adopt AI operators early will process claims faster, reduce operational costs, improve customer satisfaction, and free employees to focus on high-value work.

The ones waiting for "perfect AI" will spend the next few years trying to catch up.

Final Thoughts

Digital transformation in insurance isn't about adding more software.

It's about removing unnecessary human bottlenecks.

AI operators won't eliminate every insurance job, but I strongly believe they'll eliminate a significant amount of repetitive operational work. That shift will define the next generation of insurance companies far more than another customer portal or chatbot ever could.

If you're interested in a deeper technical perspective on this transition, this article provides additional insights into how AI operators are improving customer experience through intelligent automation in insurance:

https://geekyants.com/blog/ai-operators-in-insurance-improving-customer-experience-through-intelligent-automation

What do you think?

Will AI operators become as common as CRMs in insurance over the next five years, or is the industry still too dependent on human decision-making?